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.