Hello Kurnikov,
All this info was really helpful!
The thing is that I've got stuck in my research again.
As far as I know now, when you send a file with dtnsend, this file is processed by the Daemon who, with the BinaryStreamClient.c processes this file (processIncomingBundle() ).
This processIncomingBundle() in ApiServer.cpp raise a dtn::net::BundleReceivedEvent.
After this, BaseRouter.cpp receives this event and stores the bundle with "_storage.store(received.bundle)", the problem is that I don't really understand how this store function works because in BundleStorage.h it's only defined as "virtual void store(const dtn::data::Bundle &bundle) = 0", a pure virtual method.
After this, all what I have are suppositions:
- I've found different store methods in MemoryStorageBundle.cpp, SimpleStorageBundle.cpp and DataStorage.cpp. How the Daemon knows which one has to use?
- Why if I put some printf in all of these functions, when I send a file through dtnsend, nothing happens? I should read some outputs in my console but nothing appears and the bundle gets stored. It's like the daemon isn't using any of these functions to store the bundles.
I said all of this because I'm interested in how the parameter Priority affects the bundle storage and transfer, and the only storing functions that seems to work with this parameter are MemoryStorageBundle.cpp and SimpleStorageBundle.cpp which both have the CMP_BUNDLE_PRIORITY method to create a set storage based in the priority assigned to the bundle.
Is this already implemented or priority is in a TO-DO list and the current version of dtnsend doesn't care about it?
Thanks in advance.
Alex López.
Hi Alex,
I'll try to answer this, though I'm not the "official IBR-DTN developer":)
The things got a bit confused here.
1. We copy the options we passed to argv to the bundle b. (dtnsend.cpp)
2. We send the bundle b to the client through "client << b" (dtnsend.cpp)
Up till here it's fine.
3. The client, who has done client.connect() before, has the _receiver.start() working. (client.cpp)
Now this receiver is for receiving bundles, not for sending. So this part is involved in dtnrecv, not in dtnsend. The bundles got to the daemon through the BinaryStreamClient (ibrdtnd/src/api). In the connection function you'll notice this:
_stream << "protocol tcpcl";
And in ClientHandler (ibrdtnd/src/api) you'll see the creation of the BinaryStreamClient when it receives "protocol tcpcl". This is the part of the daemon that notifies the daemon when the bundle is received from the client. Have a look at ApiServer::processIncomingBundle().
Now if we go back to receiving bundles:
3. The client, who has done client.connect() before, has the _receiver.start() working. (client.cpp)
4. I suppose, step 3 calls for the Client::AsyncReceiver::run(). (client.cpp)
5. Now, the client sends the information to a variable and the client receive it with "_client >> b" and "_client.received(b)". (client.cpp)
6. Finally, when the client receives the bundle it makes an "_inqueue.push(b)" to put it in the queue (client.cpp)
This is valid for dtnrecv. Again the daemon part that actually gets the bundle from the storage would be BinaryStreamClient and AsyncReceiver is responsible of getting the bundle from BinaryStreamClient and putting it to _inqueue.This queue is a temporal queue before the bundles get delivered to the application. The storing happens in BinaryStreamClient.
My questions are:
- What kind of storage is that queue? The client should not store the bundles in the router using the MemoryStorageBundle.cpp or SimpleStorageBundle.cpp?
So it goes through the stream connection and on the other end is BinaryStreamClient. The interaction with storage is on behalf of the daemon then (when it reacts to BundleReceivedEvent, for example, have a look at BaseRouter (ibrdtnd/src/routing)).
- I've found that the dtnsend only sends the bundle to the client, but the client seems to work only with the queues. How the client interacts with the storage you have defined in the
conf file and where the priority sort should be done?
You're welcome. I think this is correct. If not, guys, please fix.
Thanks in advance.
Alex López.
Regards,
Arseny Kurnikov.