Dear Sir or Madam,
I still playing around with the IBR-DTN and found out some things that I would like to contribute. I hope this is helping.
I got some code from GitHub under ibrdtn/ibrdtn/tools/src/*.
First I will refer to ibrdtn/ibrdtn/tools/src/dtninbox.cpp.
In the function read_configuration is a switch-case which controls the passed arguments. But there is no test for the argument --quiet. If you start dtninbox with -q or --quiet the script just instantly stops.
I guess the missing part just looks like: ... case 'q': _conf_quiet = true; break; ...
I guess this should fix the problem. Hope this is right.
Further I gone cite Mr.Morgenroth and myself from my last post:
Last but not least there are some linking mistakes in the pdf-file for the api. For example on page 5 "...The available data formats are described in section ??....".
Oh, yes. You are right. Patches are welcome if you want to contribute a fix for that issue.
I looked at it. Just compile it once again with LaTex and it will be all okay. There are no changes in the code needed.
I think there is also a bug in the dtnrecv-function. If you say, that you want to receive more then one bundle with --count x, x>1, every bundle will just get printed once. If you start dtnrecv without --count x, x>1, or with --count x, x=1, it often happens that the same bundle gets presented at the console more then once.
But if you start it with for example --count 3 the first two bundles are only received once, the third bundle gets presented during this dtnrecv setup but if you start a new dtnrecv just after you closed the last one you will receive the third bundle again. It seems as if the last received bundle didn't get deleted or something like that.
If I start dtnrecv without count I can receive the same bundle up to four times. With --count x only the last bundle twice.
But if you set the lifetime of a bundle in dtnsend to 1 second the problem disappears. So there must be more then one bundle.
I tested this with every routing algorithm and it was always the same. But I haven't found a solution in the code yet. Maybe you have an idea.
I further have a question to the registration list command in the API.
I am registered as dtn://piOne. If I use neighbour list on an other device the shown name is dtn://piOne but if I look at the registration list there is some thing like dtn://piOne/[[:alpha::]+. Is this right? Why does it look like it does?
A little bug I found is in dtnconvert.
If you type in dtnconvert -h the help text is printed twice.
I guess is has to do with the switch case and following code. There is a case 'h' for the -h argument which prints the help. But there is the variable working_mode isn't changed, so it stays at 0, as it was since the beginning (in case 'r' or 'c' its changed) and so the following
if (working_mode == 0) { print_help(); return -1; }
prints the help again. Also checked it with echo $? and the exit code isn't as expected for a good running program / command zero, it is in my case always 255.
An other thing I saw isn't just a feature to make the program more user-friendly. In the help for dtnping (dtnping -h) there is the option --size, but no further description how to use it. It would be create if there would be something like --size <bytes>. Just to make it more intuitive.
My .conf-file will be added in the appendix. The used IBR-DTN version is: IBR-DTN version: 1.0.1 (build 294b543)
Thanking you in advance. Yours sincerely,
Kevin Baron
------------------------
.conf-file:
##################################### # IBR-DTN daemon # #####################################
# # the local eid of the dtn node # default is the hostname # local_uri = dtn://piOne
# # routing strategy # # values: default | epidemic | flooding | prophet | none # # In the "default" the daemon only delivers bundles to neighbours and static # available nodes. The alternative module "epidemic" spread all bundles to # all available neighbours. Flooding works like epidemic, but do not send the # own summary vector to neighbours. Prophet forwards based on the probability # to encounter other nodes (see RFC 6693). # routing = flooding
# # forward bundles to other nodes (yes/no) # routing_forwarding = yes
# # set to yes if this node is connected to a high precision time reference # like GPS, DCF77, NTP, etc. #
# Time-slave #time_reference = no #time_synchronize = yes
# Time-master #time_reference = yes #time_discovery_announcements = yes
##################################### # DHTNameService settings # #####################################
# # Enable the DHT, if it was compiled # Default is no # dht_enabled = yes
# # Set the udp port, the DHT should working on # Default is 9999 # If Port is 0, a random Port will be chosen for each run # dht_port = 9999
# # Here you can choose a static DHT ID, which is very common # Default is none -> a random ID per run will be generated # dht_id = DHTpiOne
# # Enables DHT on IPv6 socket # Default is yes # dht_enable_ipv6 = no
# # Enable DNS Bootstrapping for the DHT # dht_bootstrapping = no