Hi again ;-)

I still do not get the point of the issue.

The daemon has a dub-check which should eliminate the processing of double-received bundles. Thus, I assume the daemon sends the bundle twice instead of re-queuing the received bundle?

How do you manage the exchange of bundles between the router? Do you use the AbstractWorker for this? Is the destination of the bundle a singleton endpoint or not?

Can you provide a tcpdump trace of the handshake?

Additionally, some code to look at would be very helpful. Is there any public repository with the code available?

Regarding the change in the NeighborRoutingExtension: The only change here is for non-singleton bundles. These are routed always to the other node, if the node does not have them (epidemic). Maybe this behavior will be changed in future, if there is a better group/multicast routing strategy available.

Kind regards, Johannes

-------- Weitergeleitete Nachricht -------- Von: Carson Dunbar cdunbar@bucknell.edu An: Johannes Morgenroth morgenro@ibr.cs.tu-bs.de Kopie: ibr-dtn ibr-dtn@ibr.cs.tu-bs.de Betreff: Re: [ibr-dtn] NeighborRoutingExtension issues Datum: Wed, 5 Dec 2012 11:35:15 -0500

A nullspace bundle is a bundle for the Network Coding router, that lets other nodes know what data they have. Usually they're one-hop bundles, but they are addressed as stated above. All nodes in the NC router should be receiving them intermittently so they know when they can stop passing data back and forth. When I say they are bouncing back essentially want is happening is that Node A wants to update Node B with a nullspace bundle. Node B receives it, and for some reason it then gets queued up to get sent back to Node A. The real problem then is that Node A receives the bundle again and thinks that it's from Node B and thinks that Node B is equivalent to itself.

From what I've seen in the NeighborRoutingExtension, in the ShouldAdd

function, the line:

if (_entry.eid.getNode() != meta.destination.getNode())

in the older version was not part of a if (meta.get(dtn::data::PrimaryBlock::DESTINATION_IS_SINGLETON)) block. If none of the destinations are marked as singletons, won't this change the router's behavior significantly?

Thanks, Carson

On Wed, Dec 5, 2012 at 11:17 AM, Johannes Morgenroth morgenro@ibr.cs.tu-bs.de wrote: Hi Carson,

to answer this question is need more details about what exactly goes wrong. What is a nullspace bundle? Who wants to receive that? What do you mean with "bouncing back"?

Johannes Morgenroth

-------- Weitergeleitete Nachricht -------- Von: Carson Dunbar cdunbar@bucknell.edu An: Johannes Morgenroth morgenro@ibr.cs.tu-bs.de Kopie: ibr-dtn ibr-dtn@ibr.cs.tu-bs.de Betreff: NeighborRoutingExtension issues Datum: Wed, 5 Dec 2012 10:21:08 -0500

Hello, I am currently trying to implement my network coding router in IBR-DTN and I'm having some issues with the 0.8.0 version that didn't occur in the 0.6.4 version. Whenever I try to send out my nullspace bundles to nil://ausgezeichnet, the NeighborRoutingExtension is bouncing them back at the source of the bundle. I don't remember this happening with my nearly identical code in the 0.6.4 version of ibr-dtnd. I see the bundle filter in that extension has changed to include the Singleton identifier, which wasn't in the old version. Is this why my bundles are being reflected? Thanks

Carson Dunbar

-- !! 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.