Hi Johannes,
Thank you for your reply. Yes, it is as you've said. If count is higher than the number of expected bundle, then they get purged properly. The command dtntrigger works as expected.
Best regards, Pawit Pornkitprasan
---------- Forwarded message ---------- From: Johannes Morgenroth morgenroth@ibr.cs.tu-bs.de To: ibr-dtn@ibr.cs.tu-bs.de Cc: Date: Tue, 08 Jul 2014 11:50:13 +0200 Subject: Re: [ibr-dtn] Strange behavior using dtnrecv 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