Hello,
the daemon forces the endpoint because it would introduce ambiguity if an arbitrary source is set. Nobody could guarantee that the bundle id stays unique if the source is not controlled by the daemon. Moreover, keep in mind that, in contrast to destination endpoint ids, source endpoint ids are always singleton and belong to a specific node.
Kind regards Johannes
Am 7. November 2016 09:38:03 MEZ schrieb Stephan Rottmann rottmann@ibr.cs.tu-bs.de:
Hi Thomas,
yes, that is true. You may set the field of the Bundle source, but it is ignored/overwritten by the daemon. Maybe some day I will change that, since I had the same problem/question, too. But you may set your own endpoint using the API:
protocol extended set endpoint foo
Now, all bundles sent from this API connection have dtn://myhost/foo as the source, and you will get a notificaiton of new bundles sent to dtn://myhost/foo, too.
HTH, Stephan
On So, 2016-11-06 at 23:30 +0100, Thomas Halwax wrote:
Hi,
I use the extended API to send bundles. Let’s say I set the bundle
source to "dtn://myhost/myapp/somevalue“. On the receiver side the source of the bundle is shown as „dtn://myhost/default-endpoint-id“. It’s looks like the daemon does not respect the source value of the bundle but uses the default endpoint id. Is my assumption correct? If so, why is this and is there a way to use my bundle source?
My goal is to create a request-response communication but without
knowing the correct sender the receiver cannot reply. Should I use the „report_to“ field for this purpose?
Thanks in advance and best regards, Thomas
-- !! 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://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.