Hello Shyam,
Am 18.04.2014 00:00, schrieb Shyam B:
- 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.
- 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.
- 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.
- 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.
- 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?
- 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
Thanks Johannes,
This answers most of my questions.
1. So, as I understand the 'Time synchronization feature I see in ibrdtnd.conf, is an alias for '--badclock' option. Am I correct? 2. My scenario includes two zones (A and B) and a mobile node. (1 router each in a zone). The two zones cannot see each other.
The mobile node directly travels to Zone 'B' and comes back to Zone 'A' to deliver the bundle meant for Zone A from B. The bundles were 2 simple text file (few Kb) and 'a' single video of 15 Mb. I observed that for almost 20 minutes, the mobile node was active exchanging bundles. The Zone B router and mobile node were next to each other. I used the 'netstat --tcp -n | grep ' command for DTN port 4556 to notice this activity. I see this happening only when using epidemic routing in all nodes. It is way too slow sometimes. Does it use some synchronization feature to give all bundles to everybody all the time? Can I prevent it in some way or another?
Is there a way that I use epidemic on the mobile node and some other routing scheme in other nodes? The mobile node is essentially a multi-hop node.
3. I use the 'filetransfer' to send a bundle, and dtnreceive to receive this bundle, at the destination. I hope group that you referred to is something different. However,
4. When you said the client can specify the expiry of a bundle, I believe I can use the 'dtnsend --lifetime ' option to make the bundle expire, in order to avoid accumulation of bundles at all nodes with epidemic and --badclock. Am I correct in my understanding??
4. Finally, I see the process names 'lt-dtnsend', 'lt-dtnreceive', 'lt-dtnping'. Do you know how this 'lt-' came into picture in this list of running processes?
Thanks again.
Regards, Shyam
On Sat, Apr 19, 2014 at 4:58 PM, Johannes Morgenroth < morgenroth@ibr.cs.tu-bs.de> wrote:
Hello Shyam,
Am 18.04.2014 00:00, schrieb Shyam B:
- 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.
- 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.
- 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.
- 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.
- 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?
- 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
Am 19.04.2014 17:21, schrieb Shyam B:
This answers most of my questions.
- So, as I understand the 'Time synchronization feature I see in
ibrdtnd.conf, is an alias for '--badclock' option. Am I correct?
Not exactly. The behavior has been modified and replaced with the option to set "time_reference = no".
- My scenario includes two zones (A and B) and a mobile node. (1 router
each in a zone). The two zones cannot see each other.
The mobile node directly travels to Zone 'B' and comes back to Zone 'A' to deliver the bundle meant for Zone A from B. The bundles were 2 simple text file (few Kb) and 'a' single video of 15 Mb. I observed that for almost 20 minutes, the mobile node was active exchanging bundles. The Zone B router and mobile node were next to each other. I used the 'netstat --tcp -n | grep ' command for DTN port 4556 to notice this activity. I see this happening only when using epidemic routing in all nodes. It is way too slow sometimes. Does it use some synchronization feature to give all bundles to everybody all the time? Can I prevent it in some way or another?
It should give only bundles to all other peers once. Not all the time. This work at least with 0.10.x. In version 0.12.0 there is a known bug, which leads to the case that this happens more often as necessary.
Is there a way that I use epidemic on the mobile node and some other routing scheme in other nodes? The mobile node is essentially a multi-hop node.
Yes.
- I use the 'filetransfer' to send a bundle, and dtnreceive to receive
this bundle, at the destination. I hope group that you referred to is something different. However,
- When you said the client can specify the expiry of a bundle, I
believe I can use the 'dtnsend --lifetime ' option to make the bundle expire, in order to avoid accumulation of bundles at all nodes with epidemic and --badclock. Am I correct in my understanding??
Yes.
- Finally, I see the process names 'lt-dtnsend', 'lt-dtnreceive',
'lt-dtnping'. Do you know how this 'lt-' came into picture in this list of running processes?
It seems that you have compiled your own binaries and use it directly out of the directory where they has been compiled. As long you do not install them correctly, the binaries are prefixed with "lt-".
Kind regards, Johannes Morgenroth
participants (2)
-
Johannes Morgenroth -
Shyam B