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.