Hi,
yes, I am 99% sure Prophet keeps its routing table in RAM, so it would be lost when a node is powered down/a daemon restarted. In case you extend or modify this behavior we always welcome pull request towards our Github project
https://github.com/ibrdtn/ibrdtn/
I guess the best option would be an additional configuration option in the routing section, so people can choose whether they want to have a persistent routing table or not.
MfG
Sebastian
Am 09.04.2014 um 12:38 schrieb Romeu Monteiro romeumonteiro7@gmail.com:
Hi Sebastian,
Thank you very much for your answers!
Do you know about the memory of the Prophet routing protocol? I think it also stores its variables in RAM memory. We should probably have to modify it to save the variables in persistent memory, as there should be no option for that, right?
Thank you,
Romeu
On Tue, Apr 8, 2014 at 10:25 PM, schildt schildt@ibr.cs.tu-bs.de wrote: Hi Romeu
In the standard configuration all bundles are kept in RAM, so yes: Upon shutdown everything is lost. Of course IBR-DTN has also persistent storage. See the storage options in the config file. You want to set at least a storage_path
# # define a folder for persistent storage of bundles # if this is not defined bundles will stored in memory only # storage_path = /var/spool/ibrdtn/bundles
if you use uci-style configuration in OpenWRT set "option bundles" under the "config 'daemon' 'storage'" group in the ibrdtn config
If you are working with large bundles you might also want to set a blob_path (option blobs)
I am not sure about your network situation, however, as long as IP works, IBR-DTN should work. Is the problem, that the nodes do not _discover_ each other (i.e. you do not see "nodeXX available" log messages)? IP-Multicast needs to work for discovery to work. Or is the problem, that the nodes discover each other, but IBR-DTN is unable to establish a TCP connection? If this is the case, can other apps establish a TCP connection (e.g. netcat) ?
Sebastian
On 2014-04-08 10:11, Romeu Monteiro wrote: Dear all,
I have two questions regarding IBR-DTN:
- If the daemon (or the device where the daemon is running) is turned
off, all the bundles in storage and data from the Prophet routing algorithm are lost, right? Is there anyway to prevent this? We have devices which are sometimes turned off and we would not like them to loose all their information each time that happens.
- We are having problems transfering files between devices, and
perhaps between different subgroups of IP addresses. In our case, we have 3 devices originally set on the IP addresses: 20.0.5.13/24 [1], 20.0.5.56/24 [2] and 20.0.6.66/24 [3]. We changed the network mask (to
16 bits) to allow all the devices to contact each other. With this change, we can ping and even dtnping all the devices with each other. In spite of that, while we are able to send files from 20.0.5.13 to 20.0.5.56, we cannot send them from 20.0.6.66 to 20.0.5.56. It seems we cannot exchange files with the 20.0.6.66 board at all using IBR-DTN. Is there something we should be careful about in this situation? Some kind of network mask situation IBR-DTN cannot handle yet?
Thank you,
Romeu
Links:
[1] http://20.0.5.13/24 [2] http://20.0.5.56/24 [3] http://20.0.6.66/24 -- !! 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.
Thank you, Sebastian!
If you we extend Prophet we will submit the code to the project.
Romeu
On Wed, Apr 9, 2014 at 12:08 PM, Sebastian Schildt schildt@ibr.cs.tu-bs.dewrote:
Hi,
yes, I am 99% sure Prophet keeps its routing table in RAM, so it would be lost when a node is powered down/a daemon restarted. In case you extend or modify this behavior we always welcome pull request towards our Github project
https://github.com/ibrdtn/ibrdtn/
I guess the best option would be an additional configuration option in the routing section, so people can choose whether they want to have a persistent routing table or not.
MfG
Sebastian
Am 09.04.2014 um 12:38 schrieb Romeu Monteiro romeumonteiro7@gmail.com:
Hi Sebastian,
Thank you very much for your answers!
Do you know about the memory of the Prophet routing protocol? I think it
also stores its variables in RAM memory. We should probably have to modify it to save the variables in persistent memory, as there should be no option for that, right?
Thank you,
Romeu
On Tue, Apr 8, 2014 at 10:25 PM, schildt schildt@ibr.cs.tu-bs.de
wrote:
Hi Romeu
In the standard configuration all bundles are kept in RAM, so yes: Upon
shutdown everything is lost. Of course IBR-DTN has also persistent storage. See the storage options in the config file. You want to set at least a storage_path
# # define a folder for persistent storage of bundles # if this is not defined bundles will stored in memory only # storage_path = /var/spool/ibrdtn/bundles
if you use uci-style configuration in OpenWRT set "option bundles" under the "config 'daemon' 'storage'" group in the
ibrdtn config
If you are working with large bundles you might also want to set a
blob_path (option blobs)
I am not sure about your network situation, however, as long as IP
works, IBR-DTN should work. Is the problem, that the nodes do not _discover_ each other (i.e. you do not see "nodeXX available" log messages)? IP-Multicast needs to work for discovery to work. Or is the problem, that the nodes discover each other, but IBR-DTN is unable to establish a TCP connection? If this is the case, can other apps establish a TCP connection (e.g. netcat) ?
Sebastian
On 2014-04-08 10:11, Romeu Monteiro wrote: Dear all,
I have two questions regarding IBR-DTN:
- If the daemon (or the device where the daemon is running) is turned
off, all the bundles in storage and data from the Prophet routing algorithm are lost, right? Is there anyway to prevent this? We have devices which are sometimes turned off and we would not like them to loose all their information each time that happens.
- We are having problems transfering files between devices, and
perhaps between different subgroups of IP addresses. In our case, we have 3 devices originally set on the IP addresses: 20.0.5.13/24 [1], 20.0.5.56/24 [2] and 20.0.6.66/24 [3]. We changed the network mask (to
16 bits) to allow all the devices to contact each other. With this change, we can ping and even dtnping all the devices with each other. In spite of that, while we are able to send files from 20.0.5.13 to 20.0.5.56, we cannot send them from 20.0.6.66 to 20.0.5.56. It seems we cannot exchange files with the 20.0.6.66 board at all using IBR-DTN. Is there something we should be careful about in this situation? Some kind of network mask situation IBR-DTN cannot handle yet?
Thank you,
Romeu
Links:
[1] http://20.0.5.13/24 [2] http://20.0.5.56/24 [3] http://20.0.6.66/24 -- !! 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.
participants (2)
-
Romeu Monteiro -
Sebastian Schildt