- Ibr-dtn - lists.ibr.cs.tu-bs.de

transfer of bundles
by Bruno Tavares 15 Aug '13

15 Aug '13

Hello In order to analyze the results of some experiences I made, I need to know if two bundles are sent at the same time in one node. Let's say that the scenario has three nodes. The middle node receives a fragment from the first and starts to send it for the last node. In the meanwhile the first node sends a second fragment to the middle one while he is still sending the first one to the last node. What happen? Are the two fragments sent at the same time or the last fragment is only sent to the last node when the transfer of first fragment to the last node is finished ? Thank you Best regards Bruno Tavares

2 1

Fwd: DTN Issue (attachment)
by Francisco Cuesta 13 Aug '13

13 Aug '13

Hello, I'm facing some issue with ibrdtn, the main scenario is described in the picture attached. The point is that both computers have ibrdtn installed, and with the same configuration. On certain time, ibrdtn node A cannot see node B, just mention that node A is a raspberry pi wroking with ibrdtn packages. Thanks in advance, regards!

2 1

Re: [ibr-dtn] compiling ibr-dtn on windows via cygwin
by Tom Sparks 13 Aug '13

13 Aug '13

>Date: Mon, 12 Aug 2013 17:31:41 +0200 >From: Johannes Morgenroth <morgenroth(a)ibr.cs.tu-bs.de> >Subject: Re: [ibr-dtn] compiling ibr-dtn on windows via >cygwin >To: ibr-dtn(a)ibr.cs.tu-bs.de >Message-ID: <5208FFDD.4040000(a)ibr.cs.tu-bs.de> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed >Hello Tom, >Windows is not our target platform and since Windows is not >POSIX compatible you can not compile it directly for it. > However, >the challenges to master should not be very complicated, but >since we are >doing research we do not have the man power to investigate >the compilation process for win32. that's understandable >The issue with "basename()" you have found might be only a >specific missing include. >Did you already asked google for that issue? i am asking on cygwin mailing list to see if there is configuration issue >Kind regards, >Johannes

1 0

compiling ibr-dtn on windows via cygwin
by Tom Sparks 12 Aug '13

12 Aug '13

I am attempting to compile ibr-dtn 0.10.0 on windows via cyqwin and it stops with " File.cpp: In member function 'std::string ibrcommon::File::getBasename() const': File.cpp:174:44: error: 'basename' was not declared in this scope return std::string(basename(_path.c_str())); ^ Makefile:420: recipe for target `File.lo' failed " ./config and make output bellow -----cut-here------- configure: WARNING: unrecognized options: --with-curl, --with-sqlite, --with-dtnsec, --with-compression, --with-tls configure: WARNING: Libtool does not cope well with whitespace in `pwd` checking build system type... x86_64-unknown-cygwin checking host system type... x86_64-unknown-cygwin checking how to print strings... printf checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/x86_64-pc-cygwin/bin/ld.exe checking if the linker (/usr/x86_64-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-cygwin file names to x86_64-unknown-cygwin format... func_convert_file_noop checking how to convert x86_64-unknown-cygwin file names to toolchain format... func_convert_file_noop checking for /usr/x86_64-pc-cygwin/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL checking for dlltool... dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_implib checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking for gawk... gawk checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/x86_64-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for cppunit-config... /usr/bin/cppunit-config checking for Cppunit - version >= 1.9.6... 1.12.1 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether to enable maintainer-specific portions of Makefiles... no checking whether make supports nested variables... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for ld used by g++... /usr/x86_64-pc-cygwin/bin/ld.exe checking if the linker (/usr/x86_64-pc-cygwin/bin/ld.exe) is GNU ld... yes checking whether the g++ linker (/usr/x86_64-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/x86_64-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking dependency style of g++... gcc3 checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether build environment is sane... yes checking whether time.h and sys/time.h may both be included... yes checking for sys/time.h... yes checking for unistd.h... (cached) yes checking for alarm... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for clock_gettime in -lrt... yes checking for bzero... yes checking for clock_gettime... yes checking for gethostname... yes checking for gettimeofday... yes checking for inet_ntoa... yes checking for memset... yes checking for mkdir... yes checking for pow... yes checking for rmdir... yes checking for socket... yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for sys/time.h... (cached) yes checking syslog.h usability... yes checking syslog.h presence... yes checking for syslog.h... yes checking features.h usability... yes checking features.h presence... yes checking for features.h... yes checking mach/mach_time.h usability... no checking mach/mach_time.h presence... no checking for mach/mach_time.h... no checking sys/semaphore.h usability... no checking sys/semaphore.h presence... no checking for sys/semaphore.h... no checking semaphore.h usability... yes checking semaphore.h presence... yes checking for semaphore.h... yes checking for sys/semaphore.h... (cached) no checking for inline... inline checking for error_at_line... yes checking for working mktime... yes checking for stdbool.h that conforms to C99... yes checking for _Bool... no checking for int64_t... yes checking for size_t... yes checking for uint16_t... yes checking for uint32_t... yes checking for uint8_t... yes checking for NL... no checking for NL... no checking for pthread_attr_init in -lpthread... yes checking for pthread_create in -lpthread... yes checking for pthread_mutex_init in -lpthread... yes checking for pthread_cond_init in -lpthread... yes checking for pthread_condattr_setclock in -lpthread... yes checking for pthread_setconcurrency in -lpthread... yes checking for pthread_yield in -lpthread... yes checking for pthread_delay in -lpthread... no checking for pthread_delay_np in -lpthread... no checking for pthread_setschedprio in -lpthread... yes checking for OPENSSL... yes configure: WARNING: lowpan extension requested, but no libnl library is found. lowpan support is disabled. configure: creating ./config.status config.status: creating Makefile config.status: creating ibrcommon.pc config.status: creating ibrcommon/Makefile config.status: creating ibrcommon/data/Makefile config.status: creating ibrcommon/link/Makefile config.status: creating ibrcommon/net/Makefile config.status: creating ibrcommon/thread/Makefile config.status: creating ibrcommon/ssl/Makefile config.status: creating ibrcommon/ssl/gcm/Makefile config.status: creating ibrcommon/xml/Makefile config.status: creating tests/Makefile config.status: creating tests/unittests/Makefile config.status: creating tests/stress/Makefile config.status: creating ibrcommon/config.h config.status: executing libtool commands config.status: executing depfiles commands ---cut-here--------- configure: WARNING: unrecognized options: --with-curl, --with-sqlite, --with-dtnsec, --with-compression, --with-tls Making all in ibrcommon make[1]: Entering directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon' make all-recursive make[2]: Entering directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon' Making all in data make[3]: Entering directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon/data' CXX BLOB.lo CXX ConfigFile.lo CXX File.lo File.cpp: In member function 'std::string ibrcommon::File::getBasename() const': File.cpp:174:44: error: 'basename' was not declared in this scope return std::string(basename(_path.c_str())); ^ Makefile:420: recipe for target `File.lo' failed make[3]: *** [File.lo] Error 1 make[3]: Leaving directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon/data' Makefile:545: recipe for target `all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon' Makefile:395: recipe for target `all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/Tom Sparks/ibrcommon-0.10.0/ibrcommon' Makefile:422: recipe for target `all-recursive' failed make: *** [all-recursive] Error 1 error while compiling ibrcommon -----cut-here------------ --- tom_a_sparks "It's a nerdy thing I like to do" Child of the Internet born 1983 PGP ID: A7EF6006 Please use ISO approved file formats excluding Office Open XML - http://www.gnu.org/philosophy/no-word-attachments.html Ubuntu wiki page https://wiki.ubuntu.com/tomsparks

2 1

Install problem on OpenWrt
by Christian Raffelsberger 25 Jul '13

25 Jul '13

Hello, I tried to install IBR-DTN on OpenWrt with the usual procedure: "opkg update" and "opkg install ibrcommon ibrdtn ibrdtnd ibrdtn-tools". However, I get an error message that the package "ibrdtnd" is unknown and there is indeed no package file for ibrdtnd at the build server. Has the install procedure changed recently or is there a problem with the OpenWrt build? The opkg sources entry looks like this: src/gz ibrdtn http://jenkins.ibr.cs.tu-bs.de/download/openwrt/repository/attitude_adjustm… Best regards, Christian

2 1

size of bundle
by Bruno Tavares 23 Jul '13

23 Jul '13

Good morning. Is it possible to know the size of a bundle when it is received by the peer? I would like to have this information on the log but in the BundleReceivedEvent.cpp I cannot have access to this information. Thank you Best regards, Bruno Tavares

2 1

IBR-DTN release 0.10.0
by Johannes Morgenroth 22 Jul '13

22 Jul '13

New Release 0.10.0 available! More than one year of development and testing have born a new release of IBR-DTN. With more stability, more features, complete fragmentation and IPv6 support this release has been natively ported to the Android platform. For a full list of features and changes watch the official changelog: http://www.ibr.cs.tu-bs.de/trac/ibr-dtn/wiki/changelog The packages for Debian, Raspbian and OpenWrt are currently in our build queue and should be available very soon. Kind regards, Johannes Morgenroth

1 0

Re: [ibr-dtn] smallest openwrt router that can run ibr-dtn?
by Johannes Morgenroth 19 Jul '13

19 Jul '13

How do you define "small"? Physically small or small with resources? One earlier platform was the imote2 sensor node which is physically very small. Depending on the configuration the daemon should run on all devices with more than 16 MB ram. Currently we still targeting the ubiquiti router station for openwrt and do not have continuously tested any other device out there. Tom Sparks <tom_a_sparks(a)yahoo.com.au> schrieb: >I am wondering what is the smallest openwrt router that can run ibr-dtn? > > >--- >tom_a_sparks "It's a nerdy thing I like to do" >Child of the Internet born 1983 >PGP ID: A7EF6006 >Please use ISO approved file formats excluding Office Open XML - http://www.gnu.org/philosophy/no-word-attachments.html >Ubuntu wiki page https://wiki.ubuntu.com/tomsparks > >-- >!! This message is brought to you via the `ibr-dtn' mailing list. >!! Please do not reply to this message to unsubscribe. To unsubscribe or adjust >!! your settings, send a mail message to <ibr-dtn-request(a)ibr.cs.tu-bs.de> >!! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn.

3 6

Android implementation doubts
by Guilherme Rolim 17 Jul '13

17 Jul '13

Hello, I'm coding a application for android based on the DTN Ping example, however, I don't quite understand the use of some classes. For instance, I am trying to get the neighbour list from the DTN app and send a bundle to each neighbour but I don't know how to get their addresses (something like dtn://example). I've managed to get the neighbour list using the getDtnService() getNeighbors() methods from the client, but there was no method to get their addresses. Could someone explain me the best way to do it? Also, is there any document that may help me understand the dtn api classes? Thanks in advance, Guilherme rolim

2 5

Re: [ibr-dtn] Ibr-dtn Digest, Vol 36, Issue 2
by Bruno Tavares 16 Jul '13

16 Jul '13

Thank you for your answers realting this and the other subjects. I did change the timeout on the several lines of code having the instance of new TCPConnection(...,5). In most of cases the time when the transmission is stopped is right but sometimes it appears more 10 seconds than what it should. For example if the connection is stoped (5 seconds of connectivity) sometimes the line of code "Sender terminated by exception : output stream went bad ...." appears 10 seconds after than what it should. I already have in mind the 10 seconds of 2*5 seconds but sometimes it has more 10 seconds on the timestamp in this line of code and sometimes it dont (when it is right). Where can I see in the code the exact moment that the interface goes down to know exactly when the two nodes stopped the transmission of data? Best regards, BRuno Tavares ________________________________________ De: ibr-dtn-bounces(a)ibr.cs.tu-bs.de [ibr-dtn-bounces(a)ibr.cs.tu-bs.de] em nome de ibr-dtn-request(a)ibr.cs.tu-bs.de [ibr-dtn-request(a)ibr.cs.tu-bs.de] Enviado: terça-feira, 2 de Julho de 2013 11:00 Para: ibr-dtn(a)ibr.cs.tu-bs.de Assunto: Ibr-dtn Digest, Vol 36, Issue 2 Send Ibr-dtn mailing list submissions to ibr-dtn(a)ibr.cs.tu-bs.de To subscribe or unsubscribe via the World Wide Web, visit https://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn or, via email, send a message with subject or body 'help' to ibr-dtn-request(a)ibr.cs.tu-bs.de You can reach the person managing the list at ibr-dtn-owner(a)ibr.cs.tu-bs.de When replying, please edit your Subject line so it is more specific than "Re: Contents of Ibr-dtn digest..." Today's Topics: 1. Re: interruption of transmission (Sebastian Schildt) 2. Re: interruption of transmission (Johannes Morgenroth) 3. Re: interruption of transmission (Sebastian Schildt) ---------------------------------------------------------------------- Message: 1 Date: Mon, 1 Jul 2013 13:28:32 +0200 From: Sebastian Schildt <schildt(a)ibr.cs.tu-bs.de> Subject: Re: [ibr-dtn] interruption of transmission To: "ibr-dtn(a)ibr.cs.tu-bs.de" <ibr-dtn(a)ibr.cs.tu-bs.de> Message-ID: <6194C931-4D9B-4DC0-9AB1-C5FAFE02A931(a)ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii According to my understanding this value is only related to the TCP stack on the system. It can not be influenced by IBR-DTN (well maybe it could if you try setting some special option on the sockets that the TCP Convergence Layer uses, but AFAIK ibr-dtn doesn not do it). Basically TCP is a black box as far as the daemon is concerned: It stuffs bytes in, and sometimes get some bytes out. But TCP is fault-tolerant. When IBR-DTN puts bytes in and it has problems it will silently buffer them, trying to deliver them without telling the daemon about it. Only if after some time (on your system 15-20) seconds TCP still can not manage to deliver the bundle it will tell the daemon "Oops, something broke. The connection is gone". Only then IBR-DTN learns about the state of the connection and fragments the payload. So the timeout you are seeing is related to the TCP stack on your system. It might be possible to modify it, but I do not know how to achieve this. The time will be a combination of a defined number of TCP retries and the measured RTT used for the specific connection you are using. Sebastian Am 01.07.2013 um 12:32 schrieb Bruno Tavares <bmpt(a)ua.pt>: > Thank you for your quick answer Mr Schildt > > The thing is that if the interface is down for less than 15/20 seconds the bundle is not fragmented and it does not assume that the connection was lost for that period of time. after those 15/20 seconds in continues to send the bundle. If the interface is down for more than 20 seconds the bundle is fragmented and it is assumed that the connection was down. I just wanted to understand why this value and where can I change it. > > Best regards, > > Bruno Tavares > ________________________________________ > De: ibr-dtn-bounces(a)ibr.cs.tu-bs.de [ibr-dtn-bounces(a)ibr.cs.tu-bs.de] em nome de ibr-dtn-request(a)ibr.cs.tu-bs.de [ibr-dtn-request(a)ibr.cs.tu-bs.de] > Enviado: segunda-feira, 1 de Julho de 2013 11:00 > Para: ibr-dtn(a)ibr.cs.tu-bs.de > Assunto: Ibr-dtn Digest, Vol 36, Issue 1 > > Send Ibr-dtn mailing list submissions to > ibr-dtn(a)ibr.cs.tu-bs.de > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn > or, via email, send a message with subject or body 'help' to > ibr-dtn-request(a)ibr.cs.tu-bs.de > > You can reach the person managing the list at > ibr-dtn-owner(a)ibr.cs.tu-bs.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ibr-dtn digest..." > > > Today's Topics: > > 1. interruption of transmission (Bruno Tavares) > 2. Re: interruption of transmission (Sebastian Schildt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 1 Jul 2013 08:26:02 +0000 > From: Bruno Tavares <bmpt(a)ua.pt> > Subject: [ibr-dtn] interruption of transmission > To: "ibr-dtn(a)ibr.cs.tu-bs.de" <ibr-dtn(a)ibr.cs.tu-bs.de> > Message-ID: > <90494CFA1222DC45A1855F79747890D8207D50C1(a)DBXPRD0210MB358.eurprd02.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Hello all > > After running some tests I noticed that if I break the connection between two nodes for small amount of time (let's say 4 or 5 seconds) and then connect again the bundle is not fragmented and the tcp connection does not go down. It assumes that no connection break happen and continues to deliver the bundle. > > I would like to know where I can find in the code where this small break of connection can be traced to make some debug. > > Can anyone help me? > > Best regards > > Bruno Tavares > > > > ------------------------------ > > Message: 2 > Date: Mon, 1 Jul 2013 10:45:21 +0200 > From: Sebastian Schildt <schildt(a)ibr.cs.tu-bs.de> > Subject: Re: [ibr-dtn] interruption of transmission > To: "ibr-dtn(a)ibr.cs.tu-bs.de" <ibr-dtn(a)ibr.cs.tu-bs.de> > Message-ID: <8739DF1D-FCE3-4E59-AAAE-676088E49766(a)ibr.cs.tu-bs.de> > Content-Type: text/plain; charset=us-ascii > > > > There should be a "Connection Down" even logged, when the TCP connection to another node breaks (I think even if you start the daemon with -v you should see that, even if you do not set a higher debug level). Before that IBR-DTN has no way of knowing that TCP hangs, because TCP is designed to play over small outages. Depending on the TCP configuration of your operating system, and the performance of the TCP connection until then, the TCP timeout could be up to a few minutes. > > > > > Sebastian > > > Am 01.07.2013 um 10:26 schrieb Bruno Tavares <bmpt(a)ua.pt>: > >> Hello all >> >> After running some tests I noticed that if I break the connection between two nodes for small amount of time (let's say 4 or 5 seconds) and then connect again the bundle is not fragmented and the tcp connection does not go down. It assumes that no connection break happen and continues to deliver the bundle. >> >> I would like to know where I can find in the code where this small break of connection can be traced to make some debug. >> >> Can anyone help me? >> >> Best regards >> >> Bruno Tavares >> >> -- >> !! This message is brought to you via the `ibr-dtn' mailing list. >> !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust >> !! your settings, send a mail message to <ibr-dtn-request(a)ibr.cs.tu-bs.de> >> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn. > > > > ------------------------------ > > -- > !! This message is brought to you via the `ibr-dtn' mailing list. > !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust > !! your settings, send a mail message to <ibr-dtn-request(a)ibr.cs.tu-bs.de> > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn. > > End of Ibr-dtn Digest, Vol 36, Issue 1 > ************************************** > > ------------------------------ Message: 2 Date: Mon, 01 Jul 2013 13:41:46 +0200 From: Johannes Morgenroth <morgenroth(a)ibr.cs.tu-bs.de> Subject: Re: [ibr-dtn] interruption of transmission To: ibr-dtn(a)ibr.cs.tu-bs.de Message-ID: <51D16AFA.8030401(a)ibr.cs.tu-bs.de> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Hello. That is not quite correct. The timeout noticed here depends on convergence layer specific keep-alive messages. http://tools.ietf.org/html/draft-irtf-dtnrg-tcp-clayer-02#section-5.5 By default this keepalive interval is set to 10 seconds and IBR-DTN closes a connection if there is no data for twice the interval. The "10" is set on every instantiation of the TCPConnection class. So search for this (and similar) lines of code and change it according to your needs. TCPConnection *obj = new TCPConnection(*this, node, client, 10); Kind regards, Johannes Morgenroth Am 01.07.2013 13:28, schrieb Sebastian Schildt: > According to my understanding this value is only related to the TCP stack on the system. It can not be influenced by IBR-DTN (well maybe it could if you try setting some special option on the sockets that the TCP Convergence Layer uses, but AFAIK ibr-dtn doesn not do it). > > Basically TCP is a black box as far as the daemon is concerned: It stuffs bytes in, and sometimes get some bytes out. But TCP is fault-tolerant. When IBR-DTN puts bytes in and it has problems it will silently buffer them, trying to deliver them without telling the daemon about it. Only if after some time (on your system 15-20) seconds TCP still can not manage to deliver the bundle it will tell the daemon "Oops, something broke. The connection is gone". Only then IBR-DTN learns about the state of the connection and fragments the payload. > > So the timeout you are seeing is related to the TCP stack on your system. It might be possible to modify it, but I do not know how to achieve this. The time will be a combination of a defined number of TCP retries and the measured RTT used for the specific connection you are using. > > Sebastian

1 0