Hi Johannes!

thanks for your answer. So, let’s say bluetooth was supported, do you know any algorithm to select which neighbour to connect, when to disconnect to that neighbour and try connect to another one? I’m thinking on just randomly connect and disconnect to different neighbours but it may exist some algorithm to decide this. Have you used this in other non-android implementation of IBR-DTN?

Thanks.

Cheers,

Abraham.

On 31 January 2014 at 17:22:57, Johannes Morgenroth (morgenroth@ibr.cs.tu-bs.de) wrote:

Hello Abraham.

Am 31.01.2014 18:18, schrieb Abraham Martín:

1. Is there no support for bluetooth on android, am I correct? I have

connected connected two phones through bluetooth and the interface does not appears and no neighbours detected.

At this moment the daemon does not support any bluetooth connection. Only IP interfaces are supported and shown in the list.

2. The p2p0 interface is the WiFi Direct interface, right?

That is correct. Support for that will be there in the next release.

3. Is there any way to discover other peers without interaction?

By interaction I mean get both of them to connect manually to the same wifi network. E.g. Bluetooth discovery and connection (I know, its battery consuming)

I'm sorry, no. Even Wi-Fi Direct requires the user to acknowledge an dialog.

Kind regards, Johannes Morgenroth -- !! 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://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn.

Good morning! Following the conversation...

Then the decision of connecting to one or another peer is decided by the routing algorithm (that decides which is the next hope of a bundle). But like the case of several routing algorithms in DTNs, the routing protocol need to update their tables to know where to send the bundles. For example let’s say we have a node A that have a bundle with destination node C. Node C only gets in contact with node B and never with node A. Then, node A should connect to node B (even if it doesn’t have any bundle for it) for getting the ProPHET table to know that the bundle with destination node C will have a higher probability to arrive to its destination if its sent through node B.

This is why I was thinking that a node A should connect to all the nodes in their neighbourhood, first to update its routing tables, and then connect to the nodes with pending bundle forwards.

The first things should be done randomly and disconnect once the routing tables have been exchanged. Once all the tables have been updated then bundle protocols can be sent.  On 31 January 2014 at 17:53:35, Johannes Morgenroth (morgenroth@ibr.cs.tu-bs.de) wrote:

Am 31.01.2014 18:30, schrieb Abraham Martín:

thanks for your answer. So, let’s say bluetooth was supported, do you know any algorithm to select which neighbour to connect, when to disconnect to that neighbour and try connect to another one? I’m thinking on just randomly connect and disconnect to different neighbours but it may exist some algorithm to decide this. Have you used this in other non-android implementation of IBR-DTN?

The algorithm is simple: If you have a bundle for another peer connect to it.

-- !! 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://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn.