Dear Johannes, As you know we are developing a version of DTNperf_3 compatible also with IBR-DTN. As DTNperf_3 is based on the Abstraction Layer (AL), a collection of APIs that abstract BP implementation APIs (until now ION and DTN2), we had to extend to IBR-DTN the AL APIs. In doing that we did not manage to obtain from the IBR-APIs 2 items of information that are used by the DTNperf application: 1) the local EID 2) the timestamp (in s) and the sequence number as they appear in the bundle sent.
I have checked on RFCs 4838, 5050 and even on the draft of 5050bis, and they do not specify that local EID, timestamp and sequence number must be available to the application. I was a bit surprised, but I suppose that this is correct, as this, strictly speaking, is not part of the BP protocol, but of the interface between BP and the upper layer. However, after reading the RFCs it seems to me that some status reports, such as delivered, can be exploited by the source application (as a return receipt), although other uses are possible (especially in tests). To interpret a SR (e.g. a delivered, or deleted), an application must identifies with absolute certainty the bundle to which the SR refers among those it has sent. I.e. it should know both timestamp i(in s) and sequence number as inserted in the bundle sent (as for registered mail).
If it is already possible to know 1 & 2, and we just did not manage to find how, I would ask you to provide us with the instructions. Otherwise, I would kindly ask you to consider the possibility to pass these information items to the application, by enhancing some APIs or by introducing new ones. At present we should have bypassed both the problems, so it is not urgent.
Last (please be patient with me...) I have found a bit annoying the fact that the IBR-DTN daemon (dtnd) and a few tools (dtnping, dtnsend, dtnrecive) have the same name of their DTN2 equivalent. This is a very trivial problem, but it may create some confusion when you have both DTN2 and IBR-DTN installed on the same nodes. IBR-DTN and DTN2 equivalent are luckily installed in different directories, but both in the default path as obvious. If you launch the "dtnd" as a daemon, you can get confused about what version is actually on (you have to check the log). What about adding as a default a prefix "ibr", in such a way to have ibrdtnd etc. thus avoiding any ambiguity by root?
Let me congratulate you on the excellent work done with IBR-DTN.
Yours, Carlo
If you like to know why we need 1&2, the rationale is below. 1) DTNperf_3 client at the end of a session sends a "Bundle Stop" to the DTNperf external monitor running on the reply to: node. The EID of this node is passed as a parameter of the "esxternal monitor" option (e.g. -m dtn://vm3.dtn) . If the external monitor option is not set, an instance of the DTNperf monitor is launched on the source node as a thread of the client. Although a direct comunication between the client and its monitor thread is possible, for the sake of commonality we still exploits the "bundle stop" mechanism. In this case the reply to: address is not passed as is the same as the source EID. The problem is that we did not manage to obtain the EID of the local node in IBR-DTN. Note that it could be either dtn or ipn as in IBR-DTN configuration files both the options are available in an alternative way. We have by-passed the problem with a trick, but it would be preferable to have the EID passed by an API. Maybe this is already possible, but we did not manage to find it. 2) The client, when used in the window mode sends a given number of bundles (e.g. 3 if -W3) to the server and than wait for DTNperf ACKs, sent back by the server. Each ACK must confirm the reception of a bundle, and at his reception a new bundle is sent as usual with sliding windows (by contrast to TCP, the DTNperf window has however a fixed lenght). To identifies with certainty a bundle, we use the identification mechanism of BP, i.e. we rely on the triple (source EID, timestamp in s, sequence number). These values are read by the server on the arriving bundle and reported on the ACK. Here the problem is that on the client, for cross-checkink ACKs with identifiers of bundle in fly, we need at the application layer to know the identifiers (timestamp and sequence number are enough) put in the bundle sent. At present these two values are given when a bundle is created, but the values are then correctly changed when passed to the BP. The problem is that we did not manage to know the updated values. We have bypassed introducing a tolerance in the cross-check test, for IBR-DTN, but is a solution that is far from being elegant, although effective.
5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI BOLOGNA Codice Fiscale: 80007010376