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.