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.de> wrote:
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.
>