Some questions about ddsi about cyclonedds HOT 2 CLOSED

Hello,

I feel I should thank you for running into this problem 😊. As always, things with a long history can have their idiosyncracies, and this code is no exception. I suppose in the case of Cyclone, the biggest one is that it approaches RTPS (beware though, I tend to call it DDSI but it refers to the same spec) from a slightly different direction than the spec itself does! That said, the concepts do exist, even if sometimes they came out a little bit differently. (Or sometimes, just named a bit differently.)

So ... the answer to your question is: do as you did and ask!

In the case of the history caches, in Cyclone they are implemented as part of the "ddsc" code, not so much as part of the "ddsi" code. Most of the implementation of these history caches really is protocol independent, and in a multi-protocol implementation it arguably makes sense to have the implementation of the history caches as part of the "core DDS" code. Cyclone currently only supports one, but there is no reason to limit it to that one protocol. For example, OpenSplice has another protocol as well, one that is even older than the DCPS specification, and for some use cases DDSI is best, and for others the old one is best. Hence this decision.

The interface the DDSI code requires is defined in DDSI and exported via some type definitions and function pointers, and you basically plug-in the history cache implementations. Now, the plugging-in is a little rough still, but it doesn't take that much effort to clean it up to the point where each data writer and each data reader can have its own history cache implementation. Being able to do this has some big advantages: experience shows that DDS is often used as a simple messaging system (ROS2 is an excellent example, treating it as a simple queue), but in that case many of the complications in the history cache implementation are not needed and a much smaller and faster implementation can easily be written.

(The CacheChange of DDSI is roughly equivalent to the "serdata" of Cyclone, though it doesn't contain, e.g., the sequence number. Reason? Complicated! 😁 But because of that, on the writing side it ends up as a "whc_node" in the writer history cache implementation and a "whc_borrowed_sample" in its interface to DDSI code; and on the reader side it is done a little differently because the reader history cache doesn't require the sequence number.)

from cyclonedds.

No further comments for a long time, so closing.

from cyclonedds.