Hi,

I downloaded the ibrdtn code and debugged dtnrecv and dtntrigger step by step to understand what's going on. Finally, I know what was the cause. I was at fault, though I won't call it my mistake ;) dtnrecv always worked when the other did not, then I found that the <name> parameter was different at both ends.

dtn::data::Bundle b = client.getBundle(); gets hung because client initialization gets an incorrect group <name> for the bundle. It must be the same as that of the bundle sent. Don't know why so much security, we already have time-sync, encryption options? Curious, why it is designed this way <name>?

One Request:

-------------

dtnsend -h [brings about the following:]

--src <name> set the source application name (e.g. filetransfer)

dtnrecv -h [brings about the following:]

--src <name>  set the source application name (e.g. filetransfer)

dtntrigger -h brings about the following:]

<name>        the application name

May I request to add to the print_help() in .cpp items more information in the next release about having the 'same' <name> on both sender and receiver, else it will not work as desired! It may look intuitive to developers but possibly counter-intuitive to users. An example of how to use the commands (under --help) will certainly go a long way (I know some is there in wiki, but still)..

To add it to the print_help()

cout << "- - - - - \nExample usage at receiving end:\n"<<"\tdtntrigger filetransfer python /full-path-to-file\n"<<"Example usage for this at sending end:\n"<<"\tdtnsend dtn://target_node/filetransfer somefile.mp3";

Thanks all, but I certainly did learn more for this day :) Now, this makes me to invent some features in a new tool I would call 'dtnfire' :) Whew!!

PS: Been a s/w developer for 7 years now, I must say, very well written and commented code!!