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