Hello all,

Thank you all for your answers.

My scenario only includes two nodes.
The goal of this task is to select a forwarder from two nodes. That means, at an instant 't' only one node (node1 or node2) will send its bundles to its neighboring nodes.

To do that, I use timers 'T1' and 'T2' for node1 and node2, respectively.
At the same time 't', both nodes initiate their timers. Suppose that  T1 > T2, that means node1 should be the forwarder and node2 will be a receiver.

When T1 expires, node1 check if it is receiving bundles from neighbors ==> No, Then node1 sends its bundles for its neighbors.
When T2 expires, node2 check if it is receiving bundles from neighbors ==> Yes, Then node2 does not send its bundles and act as receiver.

Best Regards,
Farouk

On Mon, Apr 20, 2015 at 1:22 PM, Farouk Mezghani <mezghani.f@gmail.com> wrote:
Hello all,

Thank you all for your answers.

My scenario only includes two nodes.
The goal of this task is to select a forwarder from two nodes. That means, at an instant 't' only one node (node1 or node2) will send its bundles to its neighboring nodes.

To do that, I use timers 'T1' and 'T2' for node1 and node2, respectively.
At the same time 't', both nodes initiate their timers. Suppose that  T1 > T2, that means node1 should be the forwarder and node2 will be a receiver.

When T1 expires, node1 check if it is receiving bundles from neighbors ==> No, Then node1 sends its bundles for its neighbors.
When T2 expires, node2 check if it is receiving bundles from neighbors ==> Yes, Then node2 does not send its bundles and act as receiver.

Best Regards,
Farouk

On Sun, Apr 19, 2015 at 9:22 AM, Johannes Morgenroth <morgenroth@ibr.cs.tu-bs.de> wrote:
Hello Farouk,

the best way to achieve what you explained depends on your intention.

One way would be to start the daemon in debug mode with a level of at
least 70 and watch out for "MSG_DATA_SEGMENT received". This indicates
an ongoing transfer. It does not tell you if the bundle will be accepted
by the daemon or if the data is being received by a TCP-CL or the API.
If you plan to measure performance this way, you'll have to consider
that debug output will slow down the overall performance of the daemon.

If you plan to implement some feature within the daemon, you could
integrate some indicator within the function:

void BundleCore::validate(const dtn::data::PrimaryBlock &p)

This function is called on every bundle processed by the daemon as soon
as the primary bundle header is available. Be aware that this is not
only the case if a bundle is received by the API or a convergence-layer.
This function is also called if a bundle is restored from a file within
the storage.

I hope this information is useful for you.

Kind regards,
Johannes


Am 18.04.2015 um 15:11 schrieb Mathias Brulatout:
> @Sebastian : When a bundle is received, a BundleReceivedEvent is raised
> by the TCPConnection (if the two nodes communicate with TCP). Farouk
> wants to know when a bundle is being received.
> @Farouk : what do you want to do with this information ?

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