Hi Romeu,
for closed, local systems you do not need the DHT. It is basically intended to "cross the internet"[1] without the need of setting up static routes. We will check whether we can improve the behavior with the DHT enabled in setups like yours, so that it does not interfere with expected operation. But in your case it is definitely not needed, so no harm in turning it off.
Once you have a real world deployment with hundreds or thousands of nodes we can talk about such problems again :D
Sebastian
[1] http://www.ibr.cs.tu-bs.de/bib/acmdl/?http://dl.acm.org/authorize?6729884
Am 16.04.2014 um 12:29 schrieb Romeu Monteiro romeumonteiro7@gmail.com:
Forgot to send the e-mail bellow to the mailing list as well.
---------- Forwarded message ---------- From: Romeu Monteiro romeumonteiro7@gmail.com Date: Wed, Apr 16, 2014 at 11:28 AM Subject: Re: [ibr-dtn] Bundles not delivered with delay To: Johannes Morgenroth morgenroth@ibr.cs.tu-bs.de
Hi Joahannes,
Thank you for the clarification.
Actually our idea of the problem was very similar to what you said: from the logs we could see that the TCP connection would fail and there would be no new attempt at sending the bundle again later (there was no new checking of the routing tasks to be done for the done even thought beacons were being received). We would not have thought that this was related with DHT, we simply thought the code was not ready to deal with this kind of situations (i.e., TCP fails but the node is kept as neighbor), but we were suspicious since another colleague had succeeded with IBR-DTN in similar situations (using a previous version).
One question, as we are not familiar with DHT: what should be the consequences of disabling DHT? For now in a small lab environment it all seems to work well without DHT, but should we expect problems once we move into a real-world environment with hundreds of nodes?
Thank you,
Romeu
On Wed, Apr 16, 2014 at 7:59 AM, Johannes Morgenroth morgenroth@ibr.cs.tu-bs.de wrote: Hello Romeu,
yes, it does. Your logs did not help to see the issue because you left out the "-v" parameter to log the event messages. In these events you would see that the final destination is always recognized as available peer. In that case, nobody triggers the routing again if you reduce the distance between the nodes and bundles would stuck in the queue for the peer.
Kind regards, Johannes Morgenroth
Am 15.04.2014 20:01, schrieb Romeu Monteiro:
Hi,
We tried disabling DHT in the configuration file and it seems this has solved our problem. Does it make sense to you?
Thank you,
Romeu
-- !! 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@ibr.cs.tu-bs.de !! or look at https://mail.ibr.cs.tu-bs.de/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@ibr.cs.tu-bs.de !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.