Subject: Re: [dtn-users] New convergence layer

From: Elwyn Davies <[email-masked]>
Date: Mon, 03 Jun 2013 00:34:28 +0100

The External Convergence Layer is not actually deprecated - it is just that it has seen very little usage.  To the best of my knowledge this paper
http://www.cl.cam.ac.uk/~fb375/extremecom/2010/PetzExtremeCom10.pdf is the most recent application  to try it.  However although there is a paper, the code doesn't seem to have been made public.  You could try emailing Agoston Petz who is still doing his PhD at U of Texas/Austin.

Another case that has used the External CL is the connection to the ONE simlator - see http://www.netlab.tkk.fi/tutkimus/dtn/theone/pub/the_one_simutools.pdf (The ONE Simulator for DTN Protocol Evaluation - TKK)  See Section 4.2 and then reference 12.  Again the source code doesn't seem to be online but I'll  bug the ONE team.

If you want to build an integrated CL in DTN2, make sure you have a look at the various base classes that exist - for example, the TCP convergence layer and Bluetooth convergence layers rely on a common base class that is convenient for any sort of stream protocol.  CLs are quite complicated due to the usual need for receive and send threads in addition to the main line code.

Regards,
Elwyn Davies
Sent from my ASUS Pad

Lana Black <[email-masked]> wrote:

>On 22:03 Sun 02 Jun     , Stella Kafetzoglou wrote:
>> Hi all,
>> I am new to DTN so this may seem a naive question. Nevertheless, I wish 
>> to implement a new Convergence layer for DTN2. Is there is a manual that 
>> I can get advice from?
>> Moreover, I saw that the external convergence layer is deprecated. Is 
>> this the case or should I use this?
>> 
>> Thank you in advance
>> Stella
>
>Hi Stella,
>
>I suppose the current implementation of external convergence layers
>interface is deprecated, yes (I wonder why never caught attention). The
>best manual at this point is the code itself which is pretty 
>straightforward.
>
>There is also a functional specification by Elwyn Davies and Avri Doria
>(www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf) which you
>may find quite useful.
>
>With best regards.
>
>_______________________________________________
>dtn-users mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/dtn-users

---

From: Lana Black <[email-masked]>
Date: Mon, 3 Jun 2013 02:04:34 +0000

> If you want to build an integrated CL in DTN2, make sure you have a look at the various base classes that exist - for example, the TCP convergence layer and Bluetooth convergence layers rely on a c…

Looks like there has been a misunderstanding. Its is not the external
convergence layer itself deprecated, but several helper classes. See
Christopher Small's commit from Nov 25 2008. I think this deserves some
attention.

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 03 Jun 2013 09:59:30 +0100

> Christopher Small's commit from Nov 25 2008. I think this deserves some
True - but this doesn't stop the External CL compiling and linking when
using GNU/g++ - I have it available in a more or less up to date
version.

I think we are supposed to use unordered_map instead of hash_map but the
lack of usage has not made updating the code a priority for anyone.

And there are several other usages of hash_map in more mainstream areas
that probably ought to be fixed some time (notably Oasys StringUtils).
OTOH this doesn't seem to have been a problem for anyone recently (e.g.,
someone not using GNU).

/Elwyn

---

From: Lana Black <[email-masked]>
Date: Mon, 3 Jun 2013 09:40:40 +0000

> OTOH this doesn't seem to have been a problem for anyone recently (e.g.,

I have found the similiar code from oasys causing compilation errors [1] 
when compiling with libc++ instead of the GNU C++ library. Many tests
performed during ./configure run also fail for unknown reasons when
using other than GNU libraries. Looks like we are facing portability
issues here. Do we still need to support gcc versions 2 or 3?

[1] Error message example:
/util/StringUtils.h:70:22: error: no member named '__stl_hash_string' in
      namespace '__gnu_cxx'
        return _std::__stl_hash_string(str.c_str());

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 03 Jun 2013 12:29:08 +0100

>         return _std::__stl_hash_string(str.c_str());

Hi, Lana.

Did you come up with a fix? Or resign yourself to living with GNU?  I
remember you mentioned something about other issues a while back.

/Elwyn

---

From: Lana Black <[email-masked]>
Date: Mon, 3 Jun 2013 12:22:28 +0000

> remember you mentioned something about other issues a while back.

The most adequate solution would be rewriting the code in question to
use unordered_{set,map} containers instead of hash_{set,map}, but by
doing so we limit ourselves to C++11-compliant toolchains. We also can
borrow hash_{set,map} implementations from libc++ (it has MIT license,
so no problem with that) and including those into oasys. Both ways move
us closer to the standard compliance, but the latter adds a little bit
more code.

What do you think, Elwyn?

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 03 Jun 2013 15:07:29 +0100

> What do you think, Elwyn?

I feel a bit of fiddling with autoconf coming on.
There are 3 cases seemingly:
1. Systems that have hash_map and hash_set as first class citizens so
std::hash_map etc work.
2. Intermediate versions of GCC from v2.95 to v4.2.x that have hash_map
and hash_set as extensions where we need to use __gnu_cxx::hash_map etc.
These may also have experimental versions of unordered_* as
std:tr1:unordered_map etc.
3. Recent versions of GCC (>v4.3.0) and other compilers that have
unordered_map and unordered_hash as first class citizens so
std::unordered_map etc work.

Autoconf can check which of these applies and provide some macros.

Case 3 conforms to C++11 standard as you mention.  For GNU I suspect
that you don't actually need to tell the compiler to conform to C++11
just to get the unordered_* library - haven't yet tried 4.3.x but 4.1.2
with std::tr1:: works without extra compile flags.  Of course this may
not be the case for other compilers that might be more pernickety.  Do
you have any evidence for other compilers?

I'll see whether I can sort this out later this week. 

Regards,
Elwyn

---

From: Lana Black <[email-masked]>
Date: Mon, 3 Jun 2013 20:16:17 +0000

> I'll see whether I can sort this out later this week. 

Clang uses either present GCC headers, or libc++ if invoked with
-stdlib=libc++ flag. Libc++ entered the linux realm quite recently,
and was confined to osx/bsd systems in the past, but it contains both
ext/hash_{set,map} and unordered_{set,map}, so its support should not be
a problem unless we try to use the library internals like in
StringUtils.h.