Finding a case where the publisher is sending messages to existing participants, but not sending messages to late joiners. The QoS settings are below. Seems to work for late joiners when reliability.kind is changed to reliable for both DW and DR. Is it expected? Would like to use best effort in this case.
DataWriter QoS:
-reliability.kind = best effort
-durability.kind = transient local
-history.kind = keep last
-history.depth = 1
DataReader QoS:
same as above, plus:
-durability.direct_communication = true
Nope, that's not supported. Non-volatile Durability settings require RELIABLE Reliability to work.
https://community.rti.com/static/documentation/connext-dds/6.0.1/doc/api/connext_dds/api_cpp/group__DDSDurabilityQosModule.html#ga4bc6b72c72928cb9ed6432e3e6a83e2e
When you say not supported, is this solely RTI? I am not sure why it works but we have a QoS policy that is run using ADLINK OpenSplice Community Edition that has Durability set to transient_local and reliability is set to best_effort. There are no QoS incompatibility errors and the Policy works. I have seen that reliability must also be set to reliable when using fast_dds and OpenDDS. Can you tell me if this is a vendor specific situation or can best_effort be used and that all messages may not be supplied to late joining endpoints as reliable isn't used?
Unfortunately, the DDS specification doesn't state how DDS should be implemented to get durability to work.
As you've seen, some vendors chose an implementation such that the Reliability protocol is used to "repair" packets that were previously sent to "late joiners", DataReaders created after the data was sent". And then, there may be some that chose to do it differently.
This sentence "Can you tell me if this is a vendor specific situation or can best_effort be used and that all messages may not be supplied to late joining endpoints as reliable isn't used?" is difficult to parse.
But fundamentally, whether or not the Reliability QoS is required to support Durability is vendor specific. And for a few of the vendors, it is required (and interoperable between those vendors). And for at least OpenSplice, it seems that it is not.
Howard is right. The precise mechanism is not explained. Howrever during vendr interoperability tests we have seen that everyone is using the "reliability" protocol to send the "previopusly samples" to the late joiners.
However, it may be that some vendors automatically set RELIABILITY to TRUE as a side-effect of configuring DURABILITY > VOLATILE, whereas others don't. So I think to be portable you could set both explicitly as this should work for all vendords that support RTPS and DURABILITY TRANSIENT_LOCAL and above.