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