Re: [ibr-dtn] Bundles not delivered with delay
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
On Fri, Apr 11, 2014 at 9:17 PM, Romeu Monteiro romeumonteiro7@gmail.comwrote:
Hi,
dtntracepath seems to be working OK. It shows the path immediately if the devices are within range of each other, and if they are not it will show the path immediately after they get within range of each other.
I am attaching the logs of the source device in 2 situations:
Log file 556_w_delay.txt: I activate dtninbox in device VeniamWorks513 and use dtnsend to send a 100KB file from VeniamWorks556 with the devices far apart and no wireless connection. I reduce the distance between the devices until they are in communication range of each other and check this with pings. The file is NOT delivered. [It seems from the log file that the device knows it is in contact with a new neighbor and fetches the bundles it should be sending, but for some reason it does not send them]
Log file 556_reset_daemon.txt: I start from the previous situation by reseting the daemon at device VeniamWorks556 (the source) with the 2 devices (source and destination) in contact with each other. The file I had tried to send previously is immediately transfered to VeniamWorks513 (the destination). [It seems from the log file that the device checks if it has bundles in memory, restores them and checks if it should be sending them and then it DOES send whatever bundles it has to send]
Please let me know if you get some useful insight from this information.
Thank you,
Romeu
On Fri, Apr 11, 2014 at 7:45 PM, Romeu Monteiro romeumonteiro7@gmail.comwrote:
Also, all the nodes have different EIDs.
On Fri, Apr 11, 2014 at 7:43 PM, Romeu Monteiro <romeumonteiro7@gmail.com
wrote:
We just noticed one thing: if we reboot the daemon once the source and destination can communicate with each other, the files that were not delivered before are finally delivered...
I can provide the log files for the daemons but I would need to know the level of debug that you want.
I will try with dtntracepath now.
On Fri, Apr 11, 2014 at 4:42 PM, Sebastian Schildt < schildt@ibr.cs.tu-bs.de> wrote:
Seems like a pretty standard scenario and "should" work. Maybe you can provide log files from all daemons in your setup during on of your experiments. Also try the dtntracepath to the destination.
Are you sure all your nodes have a different EID?
Sebastian
Am 11.04.2014 um 12:02 schrieb Romeu Monteiro <romeumonteiro7@gmail.com
:
Hi Sebastian,
Thank you for your reply!
Here are the answers to your questions:
- we did not change the lifetime in dtnsend (which is set to 3600
seconds as you said), but we will check that again;
- we are sending single files with dtnsend combined with dtninbox
from 1 device to 1 device;
- we had used prophet but it did not deliver the files either. Since
we did not know whether the problem was from the routing decisions in prophet, we tried with flooding, which did not deliver either;
- in order to disconnect the nodes we are simply breaking the
wireless connection between the nodes (which is the same interface dtnd is running on), by increasing the distance between them (or using some kind of signal barrier) until they can no longer ping each other wirelessly;
Romeu
On Friday, April 11, 2014, Sebastian Schildt schildt@ibr.cs.tu-bs.de
wrote:
Hi,
are you sure the lifetime you set in dtnsend is correct (I think if
you do not set it it is 3600 seconds). Also under some routings once the message arrives at the destination it is purged from all storages, even if its lifetime is still good. Are you using group messages or singleton messages?
Flooding routing is not recommended (but should work), better use
Prophet,which does the same, only better. And for the "unavailable" nodes is the daemon stopped, or is the network connection cut, with the daemeon still running? Does it make a difference?
You can try using
dtntracepath -d -f -r -t 3600 dtn://destination.dtn/app
to see what is going on.
Sebastian
Am 11.04.2014 um 00:59 schrieb Romeu Monteiro <
romeumonteiro7@gmail.com>:
Hi,
We are having the following problem: when we use dtnsend+dtninbox
to send a file from a device to another, the file is successfully transfered if the 2 devices are in contact with each other (i.e., pinging) when the "dtnsend" command is issued (and so the transfer is immediate); if the devices are not connected when the dtnsend is issued and only later come into contact, the bundle/file is not transfered.
A similar thing seems to happen if we try to use additional devices
as relay nodes. For instance, when we use flooding for routing, the bundles are shared with connected devices immediately after we use dtnsend, but those devices do not deliver the bundles to the destination if they have to wait for some time before getting in contact with the destination.
We are thinking this might be a problem of the bundle storage
system: perhaps bundles can only be directly transmitted and not stored. In previous tests, we had used the default configurations (so with no persistant storage, and we saw files delivered together once there was contact with the destination) and later we tried with our own configurations including persistent storage (and we had many bundles we could not get delivered to their destination). During the latest tests we again used dtnd with default configurations, but we still cannot get bundles delivered when there is delay in contact.
We thought perhaps due to our unsuccessful experiment the bundle
storage system could be full and thus not allowing for new bundles to be stored. In order to flush the bundle storage we rebooted the devices and we also erased the files that were in the directory indicated by the configuration file for persistant storage. After that we tried again and we still cannot transfer files between devices who are only connected a few seconds after the dtnsend command being issued (we can still transfer the file if the devices are pinging when the file is sent).
We don't know what to do. Any suggestions?
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.
-- !! 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.
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
So, generally speaking, does it mean we caught a bug here, or a feature? :)
Sebastian
-----Original Message----- From: "Johannes Morgenroth" morgenroth@ibr.cs.tu-bs.de Sent: 16.04.2014 08:59 To: "ibr-dtn@ibr.cs.tu-bs.de" ibr-dtn@ibr.cs.tu-bs.de Subject: Re: [ibr-dtn] Bundles not delivered with delay
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
Am 16.04.2014 09:22, schrieb Sebastian Schildt:
So, generally speaking, does it mean we caught a bug here, or a feature? :)
Neither. That means that the DHT mechanism is kind of unintuitive when dealing with disconnection. Even with a DHT the disconnection would be recognized, but it would take much longer. Half an hour maybe? The DHT-thing is not my construction site.
Johannes
participants (3)
-
Johannes Morgenroth -
Romeu Monteiro -
Sebastian Schildt