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!!