Hello
Am 24.09.2012 um 12:16 schrieb Yoshimi Fujii:
While we are testing the behavior ob dtnd on Android, we found that it doesn't act as a DTN router as default. You must have disabled the function because Android has less memory. My question is follows.
Is it possible to enable it with modifying configuration file or changing command line parameter for dtnd on Android?
I am not sure what exactly you mean, but basically the Android version of IBR-DTN is similar to the other versions, e.g. it also includes all the default routing modules. See the "Routing" setting in the Android GUI of IBR-DTN. I think the default is to use Prophet. (you can change this setting if you deactivate the Daemon first, by removing the appropriate checkbox, then change routing, and reenable).
If you can't get any data transfer working, there are 2 main reasons for this: Your mobile phone does not see any other DTN node. At least one of the communication partners should have discovery enabled (Announce setting in Android gui, discovery... options in IBR-DTN config file on PC). We usually set our infrastructure to emit Beacons, as doing so on mobile phones will cost a lot of energy, as they Wifi can not go to sleep in this case. If your nodes see each other (see neighbor view in Android GUI) and exchange routing bundles but still do not seem to forward data, make sure your clocks are synchronized, as the Prophet metadata bundles are only short lived, and thus might already be expired upon reception if your cocks are out of sync.
MfG
Sebastian
Thanks, Yoshimi Fujii
(2012/09/21 16:47), Sebastian Schildt wrote:
Hello,
Am 21.09.2012 um 00:52 schrieb Yoshimi Fujii:
Hello,
I have one more question.
Do you think is it possible to let dtnd notice it's status change to application? More specifically, is the result of bundle transmission to a neighbor node available? If the transmission failed, application may ask daemon to re-send it to another neighbor. That sort of things we are thinking about.
If a transmission to a neighbor fails, the daemon will try a retransmission anyway, as long as the Bundle still has some lifetime left. Also keep in mind, that a transmission to a neighbor does say nothing about whether the bundle reaches the destination. There is some support for BP reports in IBR-DTN (i.e. information whether a bundle has been forwarded or received will be send back to an EID you choose), however as far as I know this functionality is not yet wrapped into the Java API. Johannes would have more precise information about this. To see what kind of information is theoretically available see the dtntracepath tool, e.g.
dtntracepath -f -r dtn://destination
But here still the problem is, that the reports are also send using Bundle Protocol/DTN i.e. even if your original packet arrived somewhere, you might not get the report (in time).
If you are really only interested in transmissions to a direct neighbor, see the "forwarded" and "transferred" messages in the IBR-DTN log.
Of course if you manage to wrap more of IBR-DTN functionalities to the Java bindings, we are always happy to receive patches :)
MfG
Sebastian
Can you tell me more details of your work. What kind of discovery do you implement? Do you plan to contribute your work back to the community?
I need to talk to this with a university who is actually managing the research and may holding IP about the idea.
Thanks, Yoshimi Fujii
2012/9/20 Yoshimi Fujii yfujii@kke.co.jp:
Hello,
Thank you for your information. The idea is that dtnd may use IP routing information obtained from outside. For example, when some IP routing protocol gathers routing information, it could be reflected to the DTN neighbor list. Do you catch my idea?
Thanks, Yoshimi Fujii
2012/9/20 Johannes Morgenroth morgenro@ibr.cs.tu-bs.de:
Hello,
there are already methods to add discovered connection to the daemon via the API. There methods are part of the ManageClient:
addLink - Add an additionally IP address to listen on. removeLink - Remove an previously added IP address to listen on.
addConnection - Add connection data for a specific node. removeConnection - Remove previously added connection data for a specific node.
The two latter methods allow to add/remove new discovered nodes to the neighbor list of the daemon.
Can you tell me more details of your work. What kind of discovery do you implement? Do you plan to contribute your work back to the community?
Kind regards, Johannes
Am 20.09.2012 07:53, schrieb Yoshimi Fujii:
Hello,
I didn't expect that we can't use Android NDK for building dtnd. However, we may need to build it from source code.
What we want to do is to modify dtnd to add some experimental feature for our research. That is, to manipulate its neighbor list from outside the daemon. I don't think this can be done with it's API from application.
I greatly appreciate your help.
Yoshimi Fujii
-- Johannes Morgenroth Institut fuer Betriebssysteme und Rechnerverbund Tel.: +49-531-391-3249 Muehlenpfordtstrasse 23 Fax.: +49-531-391-5936 TU Braunschweig D-38106 Braunschweig
-- Yoshimi Fujii Kozo Keikaku Engineering, Inc. TEL +81 3 5342 1129
-- Yoshimi Fujii Kozo Keikaku Engineering, Inc. TEL +81 3 5342 1129 -- !! This message is brought to you via the `ibr-dtn' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to ibr-dtn-request@ibr.cs.tu-bs.de !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn.
-- Yoshimi Fujii Kozo Keikaku Engineering, Inc. Email: yfujii@kke.co.jp Tel: +81 3 5342 1129