Some problem about DDS_RELIABILITY_BEST_EFFORT(QoS) about cyclonedds HOT 3 CLOSED

Hi,

You are entirely correct that with ~40kB every 20ms there should no packet loss over the loopback interface, and that, from some point onward, everything is received is also indicated by the "out of order" count remaining at 0.

So if I were to hazard a guess, it would be that typically the first batch of samples doesn't make it. Even though the publisher waits until it has discovered the reader, that in itself does not mean the reader has discovered the writer. Both need to have happened for the data to be delivered.

For best-effort data — "unreliable" it used to be called when I started working, a far more honest term — there is not much you can do about it. However, even for volatile, reliable data, this can be an issue. In that case, the writer will store the data in its WHC and advertise its existence in the Heartbeat messages, but the reader will ignore all this data as it really is historical data from its perspective. While arguably correct, it is counter-intuitive, and that always is a bad thing if the intuitive behaviour would also be correct.

If instead the reader were to simply request everything that's advertised, and for some reason the writer has a lot of data in its history (it could be a transient-local writer, but it is also possible for volatile writers if there are other readers around), the behaviour would not only be counter-intuitive, but also incorrect.

I am pretty sure I know a way that's within the allowed behaviour of the DDSI specification, and that is for a writer to send a Heartbeat specifically to a newly matched reader, indicating from what the first sequence number is that the writer has written, or will write, since discovering that reader. The information is available internally, the only problem is communicating it. But it seems to me that if that Heartbeat simply avoids advertises anything published later, it would be conforming and the reader would be able to use this information to start delivering samples from the sequence number one would expect it to. The behaviour would then perhaps have to treat Cyclone slightly differently from the other DDS implementations, but that's definitely feasible.

Long story short: can you verify that it is always the first samples that are missing?

P.S. There is no easy fix at application level. Of course one can build a protocol on top of DDS to ensure the matching has completed on both sides, but that's not a very sensible approach. In practice a short sleep will do, but in the long run, for reliable data it will have to be a fix at protocol level, perhaps the one I outlined, and for best-effort data, I don't think there's any solution.

P.P.S. Since one should only use best-effort when one can afford to lose data, it should not be an issue.

from cyclonedds.

Nice answer. "Even though the publisher waits until it has discovered the reader, that in itself does not mean the reader has discovered the writer. Both need to have happened for the data to be delivered." I agree with this opinion.

from cyclonedds.

No further comments for a long time, so closing.

from cyclonedds.