Hello
Am 10.09.2013 um 20:22 schrieb Shyam B shyambs85@gmail.com:
Hi Users/ Developers,
This is my first post on ibrdtn community and I must appreciate for the great work already done. I am in the midst of research project where I use ibrdtn and I am facing issues for a while now since I moved to the latest version (ibrdtn v0.10.0) on my ARM based Raspberry Pi, which came to my notice when I updated my distro on RPi. I quote my simple setup first and then 4 questions. (Please answer in as detail as possible, so that it may help others too :)
Simple setup
Testing Raspberry PI nodes in a network: Communication over eth0. Raspbian Wheezy distro on ARM. Ibrdtn v.0.10.0 (avaiable via direct sudo apt-get install)
PROBLEM 1:: Naming convention and knowing the source!
- I have multiple nodes in a mesh say A,B,C,D. 'A' is mobile, others are static nodes.
- 'A', the mobile node will send information to node 'D'. So, 'A' 'DTNSend's to 'D'. The bundle will be deployed when it sees 'D'.
- D receives the bundle from A (eventually). This is stored in /bundles (as per configuration setting) automatically with some file name 5bhhsadjh5343dsfds234wfdsdsvgfsfssdf....
This is not intended for the application. This is part of the internal bundle storage. Its format is not guaranteed in any way, it might contain additonal protocol fields, or other stuff the dameon might need. If you choose in memory storage it will not be there at all. Think of it as a "buffer" in an IP stack. Nothing for applications to see here.
My question is:
- How will 'D' ever know 'who' sent him the bundle. Currently, it just shows some weird name of the file that was received. If I don't run DTNRecv --file 'name', it is stored with weird filename. Was it A, B or C who sent this message? Is there a way for 'D' to find this out?
Certainly, as the bundle contains the source, and when it is received you can see from which neighbor in the IBR-DTN logfile. dtnrecv does not show you this, but if you use the IBR-DTN API directly you can get those information. Or you might check the dtntrigger tool shipped with ibrdtn, which is a bit more advanced than dtnrecv: It can call an external script with the payload and the source EID as parameter when a bundle is received.
- Can I store the bundle that I receive from node A in some created folder (automatically without waiting for bundle via DTNRecv), with the same filename as sent by the source 'A'?
Yes and not. The builtin tools do not support it, because you would need a small protocol on top of DTN which also transmits filenames. The IBR-DTN Sharebox App on Android oes this, but I think there is no ready-to go counterpart for a PC. However, you can quickly emulate that behavior: Basically ShareBox sends compressed tar archives, which are unpacked on the other side. This could be easily emulted with dtnsend/dtntrigger and a few simple scripts.
PROBLEM 2:: Static routing
From what my understanding of DTN is that, if two nodes are running dtnd deamon, they will discover each other. My nodes are configured with static IP address. Without assigning the static routes in the ibrdtn.config file 'the nodes cannot discover and communicate with each other.
I have used it without specifying IPs of any kind. Why should I do this? Can't they discover without it? I want to use static IPs for all nodes in the mesh.
Are they actually discovering each other? This could be seen in the logfile. Discovery and a convergence layer for the correct interface must be configured correctly in the config file. For a quick test you can star the daemeon specifying the interface directly as in
dtnd -i eth0
PROBLEM 3:: DTNTrigger
It specifies that a script will be triggered on receipt of a bundle. Again, (similar to problem 1), can I know who sent this to me. I need to process this in my own program in python.
The script gets two parameters, on is a file with the payload, the other on is the source EID such as dtn://A/testApp . This you can use for example to reply.
PROBLEM 4: Statistical logging missing (in the latest version)?
Where is ibrdtn.stats file. It is missing from configuration. In the version update: http://trac.ibr.cs.tu-bs.de/project-cm-2012-ibrdtn/wiki/changelog: it says that:
- Statistic Logger replaced by API management calls
How do I use them, is there any example showing this? f there is an API, which one is it?
Looking forward to your kind response.
I think the python script Johannes sent earlier can do this. The API is a ASCII based protocol over TCP. The python script connects that and retrieves the nieghborlist.There are other kinds of statistics that can be obtained form the API, but I am not sure they are documented. The source contains the answer... Maybe Johannes can point you to the correct sourcefile (or wiki page) where you can find what you need.
Thank you, Shyam
Sebastian
On Tue, Sep 10, 2013 at 2:57 PM, Shyam B shyambs85@gmail.com wrote: Hi DTN folks/masters,
I am using Raspberry PI. I just updated the Raspbian Wheezy and upgraded to the latest version 0.10.0 of ibrdtn. I just did (sudo apt-get ibrdtnd ibrdtn-tools).
Unfortunately, I cannot see the /tmp/ibrdtn.stats in the folder. The stats commands are also missing in the ibrdtn.conf file. I have all the required permissions for this folder. In my own program, I read this file to get the neighbor node's status (i.e. if they are available) and not I am unable to. This feature was available in the previous version of ibrdtn (which I am unable to retrieve now - I cannot see the earlier version in the Raspbian repository!
In the version update: http://trac.ibr.cs.tu-bs.de/project-cm-2012-ibrdtn/wiki/changelog: It says: • Statistic Logger replaced by API management calls What does this mean? If there is an API, where is it and what is the easy way of calling this API? I am programming in python..
Also, I would like to know the difference between DTN2 and IBRDTN, which one is better to use and why/ why not?
Thank you and I hope I can get some help!
-- Best Regards, Shyam
-- Best Regards, Shyam