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

Connexion
by Ghada Jaber 28 Apr '14

28 Apr '14

Hello I've installed the application of ibr-dtn (ubuntu version) on two laptop and i want to test the connexion between the two . How can i interconnect them ? Using wifi or ethernet port ? ad-hoc mode ? Thank you for your help . Ghada Jaber Etudiante en 5eme année Réseau informatique et Telecommunication a l'INSAT Stagiaire a l'IRIT/ENSEEIHT Tel : 003385681703 email : jaberghada(a)yahoo.fr Skype : ghada.jaber90

2 1

Questions: Size of bundles and multiple files in single bundle
by Romeu Monteiro 24 Apr '14

24 Apr '14

Hi, I have a question which might be too simple, but we have searched and cannot find the answer (and I don't want to spam the mailing list). We want to register in a special log file the size of the bundles (in bits or bytes), but we cannot find the variable that contains that information. Do you have any idea which variable that is or how we can find it? By the way, another question: suppose we send multiple files from one device to the same destination and these files are stored until a neighboring node or the destination becomes available. In that situation does IBR-DTN encapsulate multiple files in a single bundle? I suppose not, but I would like to clarify that. Thank you, Romeu

2 1

Using PRoPHET from version 12 on version 10
by Romeu Monteiro 24 Apr '14

24 Apr '14

Hi, We have been modifying code from version 0.10.2 (daemon and tools) and we need to use PRoPHET (which we did not modify), but we saw that version 0.10.2 has bugs which were corrected in version 0.12.0. Is it possible to simply use PRoPHET from version 0.12.0 on version 0.10.2? We tried replacing the source code (the PRoPHET folder on dtnd) and compiling, but there was an error since there was no Makefile in the new version. We got the Makefile from the old version and pasted it there, but now we there problems: make[7]: Entering directory `/home/builder/openwrt/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/ibrdtnd-0.10.2/src/routing/prophet' Makefile:407: .deps/AcknowledgementSet.Plo: No such file or directory Makefile:408: .deps/DeliveryPredictabilityMap.Plo: No such file or directory Makefile:409: .deps/ForwardingStrategy.Plo: No such file or directory Makefile:410: .deps/ProphetRoutingExtension.Plo: No such file or directory make[7]: *** No rule to make target `.deps/ProphetRoutingExtension.Plo'. Stop. Is there any easy way to integrate PRoPHET from version 12 with the remaning code from version 10.2? Thank you, Romeu

2 1

Finalizing blocks?
by Brenton Walker 24 Apr '14

24 Apr '14

Hi, I am trying to write an extension block processor. This block will log some information about where the node has been while the bundle was stored on the node. The problem I am running in to is that I want to update the contents of the block right before it is sent, but I'm not finding a good way to do that. Both getLength() and serialize() and the << operator are const. I think DTN2 runs a "finalize" pass on all the blocks before they are finally generated. I would think something like that would be needed for the BSP blocks too, but I can't figure it out. Is there a "right" way to do this in ibrdtn? Thanks, Brenton

2 2

Re: [ibr-dtn] Important technical help required!!
by Johannes Morgenroth 22 Apr '14

22 Apr '14

Hello Shyam, Am 18.04.2014 00:00, schrieb Shyam B: > 1. I am facing some difficulties as at some odd times, the daemon stops > to respond (dtnping is not possible). Is there a possible bug (or > instability issue) in v. 0.10.2? A bug is possible, but hard to confirm without any details. > 2. Further, I use "--badclock" option on all systems (TP-Link router and > Raspberry Pi) with Epidemic routing. Is there a way to avoid bundles > from being accumulated in a system since I do not use a time reference > for them to auto expire. Could you tell me if I can specify the > "--lifetime" option on the individual "dtnsend bundles dispatched" OR do > I need to specify something in the IBR-DTN configuration file? Any > specific help will be very helpful. Without a reliable clock the expiration of bundles is limited and maybe turned off. If yes, the log would told you that. The lifetime of each bundle is specified by the client only (e.g. dtnsend). There is no additional configuration necessary in the daemon. > 3. Is there a version incompatibility between 0.10.0 and 0.10.2? I hope > not. I use them on all systems and run the daemon with the script > "/etc/init.d/ibrdtnd restart". I also tested with v.0.12.0 (latest > version) where I found some incompatibility with lower versions (maybe > not enough tests). It does not seem to allow --badclock option to be set > in the script (it complains) unlike v.0.10.2. There is no incompatibility between 0.10.0 and 0.10.2. But between 0.10.x and 0.12.0, the summary vector format has been changed in a way that synchronization of bundles will not work reliable. In version 0.12 the badclock option has been removed and replaced by the time-synchronization features. > 4. What is the difference between Routing = None or Default or Epidemic. > In my demo, there are two separate zones of wireless networks and a > mobile node in between which takes the data from one zone to the other. > Which one can help and how? I would like to understand this since > epidemic is set on all nodes, and sometimes sends an avalanche of bundles. "routing = none" disables all dynamic routing modules except of static routing. "routing = default" enables direct delivery of bundles, but no multi-hop routing. "routing = epidemic | prophet | flooding" additionally enables multi-hop routing using the chosen routing approach. > 5. Can I set Routing = Epidemic on one node and something else on the > other node? Is that possible? Yes. But what do you except from that? > 6. I am using DTNTrigger to receive the bundles. In the CPP code, I see > that the python script takes over by System:: call, and the local bundle > is deleted. When using Epidemic, I am afraid, that since that bundle is > lost in the target system, it is brought in back again if the source > node is not in sight at that moment. How does the "acknowledgement" > mechanism work - does it delete bundles in all nodes when the target > receives the bundle? Bundles are purged from the network if a bundle is delivered to its destination. Bundles addressed to a group are not purged until the lifetime expires. Kind regards, Johannes Morgenroth

2 2

Some help needed..
by Shyam B 18 Apr '14

18 Apr '14

Dear Sebastian, Johannes, I am preparing for an important demo in which I use IBR-DTN for demonstrating DTN. I would appreciate your technical inputs in the places where I am stuck. I am unable to find answers to some questions, and I think only you could help answer them. I will list them one by one: 1. I am facing some difficulties as at some odd times, the daemon stops to respond (dtnping is not possible). Is there a possible bug (or instability issue) in v. 0.10.2? 2. Further, I use "--badclock" option on all systems (TP-Link router and Raspberry Pi) with Epidemic routing. Is there a way to avoid bundles from being accumulated in a system since I do not use a time reference for them to auto expire. Could you tell me if I can specify the "--lifetime" option on the individual "dtnsend bundles dispatched" OR do I need to specify something in the IBR-DTN configuration file? Any specific help will be very helpful. 3. Is there a version incompatibility between 0.10.0 and 0.10.2? I hope not. I use them on all systems and run the daemon with the script "/etc/init.d/ibrdtnd restart". I also tested with v.0.12.0 (latest version) where I found some incompatibility with lower versions (maybe not enough tests). It does not seem to allow --badclock option to be set in the script (it complains) unlike v.0.10.2. 4. What is the difference between Routing = None or Default or Epidemic. In my demo, there are two separate zones of wireless networks and a mobile node in between which takes the data from one zone to the other. Which one can help and how? I would like to understand this since epidemic is set on all nodes, and sometimes sends an avalanche of bundles. 5. Can I set Routing = Epidemic on one node and something else on the other node? Is that possible? 6. I am using DTNTrigger to receive the bundles. In the CPP code, I see that the python script takes over by System:: call, and the local bundle is deleted. When using Epidemic, I am afraid, that since that bundle is lost in the target system, it is brought in back again if the source node is not in sight at that moment. How does the "acknowledgement" mechanism work - does it delete bundles in all nodes when the target receives the bundle? Attached is the ibrdtn config file for v.0.10.2 on a Raspberry Pi. Please let me know if you find any glitches with settings deviating from the default e.g. cross_layer, routing_forwarding, clock. I have set some of these options to "Yes" without knowing yet why I do that! But it works with that! I would really appreciate your inputs as I have spent a lot of time figuring this out as the demo is nearing! Thanks again! -- Best Regards, Shyam

1 0

Fwd: Bundles not delivered with delay
by Romeu Monteiro 16 Apr '14

16 Apr '14

Forgot to send the e-mail bellow to the mailing list as well. ---------- Forwarded message ---------- From: Romeu Monteiro <romeumonteiro7(a)gmail.com> Date: Wed, Apr 16, 2014 at 11:28 AM Subject: Re: [ibr-dtn] Bundles not delivered with delay To: Johannes Morgenroth <morgenroth(a)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(a)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(a)ibr.cs.tu-bs.de> > !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn. >

2 2

Re: [ibr-dtn] Bundles not delivered with delay
by Romeu Monteiro 16 Apr '14

16 Apr '14

Thank you very much, Johannes. We will read it. Best wishes, Romeu On Wed, Apr 16, 2014 at 11:46 AM, Johannes Morgenroth < morgenroth(a)ibr.cs.tu-bs.de> wrote: > Am 16.04.2014 12:28, schrieb Romeu Monteiro: > > 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? > > I do not think that the DHT is relevant for your scenario. To understand > what it is you should read the corresponding paper: > > Schildt, Sebastian, Lorentzen, Till, Morgenroth, Johannes, Pöttner, > Wolf-Bastian and Wolf, Lars: Free-riding the BitTorrent DHT to improve > DTN connectivity, in Proceedings of the seventh ACM international > workshop on Challenged networks, CHANTS '12, New York, NY, USA, Seite > 9-16, ACM, 2012 > > The paper is available for free through the link on the project page: > https://www.ibr.cs.tu-bs.de/projects/ibr-dtn/ > > > Kind regards, > Johannes Morgenroth >

1 0

Re: [ibr-dtn] Bundles not delivered with delay
by Romeu Monteiro 16 Apr '14

16 Apr '14

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(a)gmail.com>wrote: > 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(a)gmail.com>wrote: > >> Also, all the nodes have different EIDs. >> >> >> On Fri, Apr 11, 2014 at 7:43 PM, Romeu Monteiro <romeumonteiro7(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)ibr.cs.tu-bs.de> >>>> !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn. >>>> >>> >>> >> >

3 3

Re: [ibr-dtn] Bundles not delivered with delay
by Romeu Monteiro 15 Apr '14

15 Apr '14

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(a)gmail.com>wrote: > 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(a)gmail.com>wrote: > >> Also, all the nodes have different EIDs. >> >> >> On Fri, Apr 11, 2014 at 7:43 PM, Romeu Monteiro <romeumonteiro7(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)ibr.cs.tu-bs.de> >>>> !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn. >>>> >>> >>> >> >

1 0