How to build native dtnd binary for Android from source?
Hi,
Now I almost understood how to write Android application with IBR-DTN. I have another question. How can I build dtnd binary from the source? Because it seems to be a native Android module and your Android daemon application source tree just contain it's pre-compiled binary.
Could you help me again?
Hello,
the code of IBR-DTN is also available in the SVN repository. https://www.ibr.cs.tu-bs.de/svn/ibr-dtn/trunk/ibrdtn/
Since the binary is not compiled with the Android Native Development Kit, there is no easy way to do this and no manual available. I am compiled the binary statically with the buildroot project [1]. But it needs some time and practice to understand the framework and get the binary compiled statically.
Why do you need to compile the daemon binary on your own? Why does the pre-compiled one does not fit for your cases?
Kind regards, Johannes
[1] http://buildroot.uclibc.org/
Am 18.09.2012 11:10, schrieb Yoshimi Fujii:
Hi,
Now I almost understood how to write Android application with IBR-DTN. I have another question. How can I build dtnd binary from the source? Because it seems to be a native Android module and your Android daemon application source tree just contain it's pre-compiled binary.
Could you help me again?
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
2012/9/19 Johannes Morgenroth morgenro@ibr.cs.tu-bs.de:
Hello,
the code of IBR-DTN is also available in the SVN repository. https://www.ibr.cs.tu-bs.de/svn/ibr-dtn/trunk/ibrdtn/
Since the binary is not compiled with the Android Native Development Kit, there is no easy way to do this and no manual available. I am compiled the binary statically with the buildroot project [1]. But it needs some time and practice to understand the framework and get the binary compiled statically.
Why do you need to compile the daemon binary on your own? Why does the pre-compiled one does not fit for your cases?
Kind regards, Johannes
[1] http://buildroot.uclibc.org/
Am 18.09.2012 11:10, schrieb Yoshimi Fujii:
Hi,
Now I almost understood how to write Android application with IBR-DTN. I have another question. How can I build dtnd binary from the source? Because it seems to be a native Android module and your Android daemon application source tree just contain it's pre-compiled binary.
Could you help me again?
-- Johannes Morgenroth Institut fuer Betriebssysteme und Rechnerverbund Tel.: +49-531-391-3249 Muehlenpfordtstrasse 23 Fax.: +49-531-391-5936 TU Braunschweig D-38106 Braunschweig
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
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
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.
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
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.
Hello,
Thank you for the additional information. I'll try it. I found addLink/deleteLink API source. Thanks, I wanna try them, too.
One more question.
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?
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.
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
Hello,
Thank you for your quick response.
(2012/09/24 20:55), Sebastian Schildt wrote:
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).
OK, now I understand there is no difference between Android version and Linux version. I suspected that you may disabled DTN "router" function as default for Android, because we observed once a bundle has been "rejected" by an Android terminal.
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.
I'll check this.
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.
I'd like to make sure this point, too.
MfG
Sebastian
I really appreciate your help.
Yoshimi Fujii
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
Hello,
We added routing_forwarding = yes to the configration files data/data/de.tubs.ibr.dtn/files/config. And our ibr-dtnd on Android terminal finally became forwarding bundles for other terminals. Thank you for your information.
Yoshimi Fujii
(2012/09/24 20:55), Sebastian Schildt wrote:
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
Hello,
We are still trying to build dtnd for Android using buildroot. Build seemed to be successful and 'file dtnd' shows:
"ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped".
However, when we run the binary, cause "Segmentation fault". What's wrong with us?
We built very simple application like "hello world" using buildroot and it runs on Android successfully.
Attached is the config file which we used for building dtnd.
Thanks, Yoshimi Fujii
participants (3)
-
Johannes Morgenroth -
Sebastian Schildt -
Yoshimi Fujii