async_write and iceoryx

[sgf201]

first,describe my environment, host A IP “192.168.100.2” host B IP ”192.168.100.3“ I use cyclonedds+iceoryx , the process in A can get msg from B recently,I find async_write . I enabled async_write by add code below before the writer creation "dds_qset_latency_budget(qos,DDS_SECS(0.1));" all processes in A can get msg from oters in A, but can not get msg from B. did I miss some configuration should make when using async_write? @eboasson @elfenpiff

[elfenpiff]

@sgf201 I would see it as a cyclonedds issue first and when this reveals problems in iceoryx I would start investigating this problem on the iceoryx side.

[eboasson]

The "latency budget" is specified as "a hint to the middleware", so a DDS implementation is free to ignore it. Obviously it is a valuable feature, but Cyclone DDS currently does not yet make use of the latency budget, and so you would still be publishing data synchronously.

This "latency budget" setting is part of the set of QoS settings that need to match between the reader and the writer for communication to occur. The problem is probably that you are not setting a latency budget on your readers that is ≥ the one on the writer: then the readers don't match the writer and no communication will occur. If you set the one on the readers also to 100ms, all should go back to normal.

[sgf201]

thanks ,It works when I set the reader "dds_qset_latency_budget(qos,DDS_SECS(0.1));"also. and I am curious about: 1.why the reader in same host can get msg which is not set the latency_buget either.

2.as you say that "now cycloneDDS does not make use of the latency budget" ,but I find that the code is there, how it does not work? https://github.com/eclipse-cyclonedds/cyclonedds/pull/685 if (async_mode && !gv->sendq_running) { nn_xpack_sendq_init(gv); nn_xpack_sendq_start(gv); } @eboasson

[eboasson]

@sgf201

1.why the reader in same host can get msg which is not set the latency_buget either.

It looks to me like we overlooked the "latency budget" case when integrating Iceoryx ... We did discuss what we should do with mismatching QoS settings, because I have never seen anyone intentionally using mismatched QoS settings. You really want to be able to use Iceoryx independently of the "latency budget" setting, but to do the matching correctly you need to guarantee that you only forward the data via Iceoryx if the latency budgets are guaranteed to match. That is, when the (writer latency budget = 0 && reader latency budget = anything) or (writer latency budget = anything && reader latency budget = ∞).

Of course you can't get both to work ... I'd be happy to accept only the first case (which covers the default QoS settings) by default, and then have an option that tells it to use Iceoryx regardless of the latency budget. @MatthiasKillat what do you think?

2.as you say that "now cycloneDDS does not make use of the latency budget" ,but I find that the code is there, how it does not work? https://github.com/eclipse-cyclonedds/cyclonedds/pull/685

   if (async_mode && !gv->sendq_running) {
    nn_xpack_sendq_init(gv);
    nn_xpack_sendq_start(gv);
  }

The problem is in my answer, I made a mistake!

[MatthiasKillat]

@eboasson The problem is that the writer with some budget B creates an iceoryx publisher P. Now later there is a reader with some different budget B' that somehow not matches (i.e. B`<B). This reader will create an iceoryx subscriber S given the other QoS are suitable (it has to, there could be other publishers it is allowed to get data from).

Assuming all other QoS match, this reader will still get data from P and we cannot prevent this without introducing a notion that of this budget to iceoryx or somehow coming up with a "hack" to do so (I do not immediately see one, besides it would be bad design).

We cannot do this in iceoryx right now I think due to frozen 2.0 API release (we would need a configurable option in the API) And we should not without a clean solution, like a more general user-configurable matching concept which requires some discussion.

Maybe I miss something, but it is not straightforward to get correct behavior according to spec in all cases. Basically the same problem as in transient local reader vs. volatile writer that should not connect either. This was solved in iceoryx though ...

We could define that iceoryx is never used with a non-default budget though ...