Hi all,
I would like to ask how QoS policies work across DDS entities in general (I understood the request-offer semantics between DataReader and DataWriter). For example, the durability QoS can be specified on the Topic itself as well as the DataWriter that updates the Topic instance. Does one overwrite the policy value of another?
Here is what I have tried. In the hello_world example (shipped with the release of Connext Professional), I specified the durability QoS on the topic in HelloPublisher.cpp and HelloSubscriber.cpp, respectively, with the value set to DDS_TRANSIENT_DURABILITY_QOS. The code compiled, but it did not exhibit the behavior of transient durability. For example, I launched the DataWriter first, and then updated the topic several times, and then I launched the DataReader but it did not get the updates that were available before it came alive.
What is the fundamental principle in consolidating QoS policies? and I appreciate pointers to examples.
Thanks!
Chao
First, for an overview of all(?) of the possible QoS settings:
https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/connext_dds/RTI_ConnextDDS_CoreLibraries_QoS_Reference_Guide.pdf
for an in depth view of the different entities and how each qos policy affects them take a look at:
https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/index.htm
To address your example:
Topic vs DataWriter durability: although I haven't verified it, I believe setting Topic durability should set durability for writers and readers created using that topic (unless you create them with a profile that overwrites durability of said topic or of the writers/readers).
Generally speaking there's a hierarchy used for some qos policies (some don't have hierarchies because they are meaningless in certain contexts).
That being said, a reader that uses transient durability may need to wait for historical data to actually receive it (it's some different api, if i remember correctly).
Regarding your last question: how to consolidate qos policies:
1. Take a look at the qos cheat sheet
2. model your distributed system (consider bottle necks, beware of overly pairing services, and think what your SLA is: do you need to guarantee delivery for some type of messages? do you need to guarantee updates are sent at a certain rate? do you need to support late joiners?)
2.1. the above modelling should yield: topics, types, and basic profiles for each topic
3. next you can try to use "inheritance" for your qos file (for example, having a base profile with minimal settings that are required for all of your entities, then a reliable profile inheriting from the base profile, etc)
At any rate I would recommend talking with the engineering team as they are likely to have some insight and a better understanding of how to utilize rti dds to solve your problems.
Good luck,
Roy.
Hi Roy,
Thanks for the explanation and the pointers :)
I guess a take-home message is the following: outside the scope of the request-offer semantics between DataReader and DataWriter, it depends on the app developers to make sane QoS configurations end-to-end.
Chao
Addressing the test cast given in the original post -- One thing to check is that any of the non-volatile persistence durability options also require reliable being set. Out of the box QoS I believe has reliable set for the default Writer QoS, but best-effort for the Reader.