Hi Pawit,

First of all you should try to use dtnrecv to receive bundles of the EID you are seeking :

$*dtnrecv --name* filetransfer *--count* $nb instead of just $*dtnrecv --count* $nb

The issue you are experiencing could be from that.

​ Best regards, --- ​​ Auzias Maël - auzias.net http://www.auzias.net/ ​PhD candidate http://auzias.net/?p=phd ​- ​ IRISA ​ Member of the Scientific Council http://auzias.net/Generation14/index-en.html GSM : *0033 695 118 774*

On Tue, Jul 8, 2014 at 4:01 AM, Pawit Pornkitprasan pawit-p@is.naist.jp wrote:

Hi,

I am using "IBR-DTN version: 0.12.1 (build 7c220eb)" (Debian package) and I'm experiencing what I think is a strange behavior using dtnrecv.

The configuration for the 2 testing machines (machine-a and machine-b) are as follows (they are the same except for the machine name).

local_uri = dtn://machine-a.dtn logfile = ../ibrdtn/ibrdtn.log timezone = +9 limit_blocksize = 0 limit_lifetime = 604800 blob_path = ../ibrdtn/blobs storage_path = ../ibrdtn/bundles limit_storage = 10G discovery_address = ff02::142 routing = prophet routing_forwarding = yes scheduling = yes

The test is to use dtnsend on mahcine-a and dtnrecv on machine-b.

machine-a$ echo "test" | dtnsend dtn://machine-b.dtn/filetransfer machine-a$ echo "test2" | dtnsend dtn://machine-b.dtn/filetransfer

The issue is that on machine-b, no matter how many times I run dtnrecv, I get the same "test", which doesn't seem to get purged (I expect that I should get "test2" on the second try and dtnrecv should be waiting for future bundles in the third try).

machine-b$ dtnrecv test

machine-b$ dtnrecv test

machine-b$ dtnrecv test

In addition, the daemon throws the following error message everytime I run dtnrecv.

Tue Jul 8 10:57:21 2014 WARNING BLOB::copy: output stream failed [Success]; 0 of 6 bytes copied Tue Jul 8 10:57:21 2014 WARNING BLOB::copy: output stream failed [Success]; 0 of 6 bytes copied

However, on machine-b, if I run "dtnrecv --count 2", then the first bundle (and only the first bundle) gets purged.

machine-b$ dtnrecv --count 2 test Tue Jul 8 10:59:09 2014 NOTICE BundleEvent: bundle [458099790.1] dtn://machine-a.dtn/CNiYgszrzAzmOhSy delivered Tue Jul 8 10:59:09 2014 NOTICE BundlePurgeEvent: purging bundle [458099790.1] dtn://machine-a.dtn/CNiYgszrzAzmOhSy test2

If I continue to run dtnrecv, then I get "test2" all the time. And if I run "dtnrecv --count 2" one more time, then the second "test2" bundle finally gets purged.

Is this a bug, a misconfiguration, or an expected behavior?

Best regards, Pawit Pornkitprasan -- !! 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.

Hello Pawit.

Am 08.07.2014 04:01, schrieb Pawit Pornkitprasan:

Is this a bug, a misconfiguration, or an expected behavior?

Thank you for that report. I think it is a bug in the API implementation used by dtnrecv. To verify this you can run dtnrecv with a count parameter higher than the number of bundles you expect. In that case, all bundles should get purged but dtnrecv will not return.

The issue is buried deep in the old-style API protocol of IBR-DTN. If a client connects to the daemon, bundles are pushed through the TCP channel to the client. The client releases an ACK for each bundle which instruct the daemon to purge the corresponding bundle. Sometimes, depending on the machines timing, dtnrecv closes the channel before the daemon receives the ACK for the bundle and this leads to a second delivery the next time the client connects.

IBR-DTN already offers an plain-text API which avoids this issue by design, but dtnrecv does not uses the new API.

My advice is to avoid the usage of dtnrecv if possible. Depending on your application, you can use dtntrigger [1] or write an real application using the API [2].

Kind regards, Johannes Morgenroth

[1] http://trac.ibr.cs.tu-bs.de/project-cm-2012-ibrdtn/wiki/docs/dtntrigger [2] http://trac.ibr.cs.tu-bs.de/project-cm-2012-ibrdtn/wiki/docs/api