Hi
If you have a topic that is subscribed and published by multiply participants.
This could be a state of a radio button on a HMI that should be synchronized between machines.
I guess that if two publishers (A and B) change the radio at the same time some participants may get A then B and others get B then A. So they get different last states.
Is it possible to ensure that every subscriber has the same value eventually? Or is there another way to do this?
/Kennet
Hey Kennet.
Firstly I should point out the option for keyed topics.
The problem you've described occurs when multiple writers are used to update the same instance (on a keyed topic, each key will map to an instance, on a non-keyed topic there will be one instance).
As for mechanisms to ensure that the problem doesn't occur:
1. You can set the reader to sort messages by the source timestamp instead of the reception timestamp (as described in https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/Content/UsersManual/DESTINATION_ORDER_QosPolicy.htm)
2. Another option is to utilize the OwnershipQos so that only one (the strongest, per instance) writer will update each instance
3. A third option would be to use application level logic to accomplish one of the above behaviors (single writer per instance at any given time / ordering of application data by a source timestamp of some sort)
Hope this helps,
Roy.
Hey thanks
I think that you option 1 is what I am looking for.
I do however not see how keyed topics would help me in this senario.
Are you suggesting I add a key with a publisher id of some sort so that a subscriber can see values from every publisher ?
/Kennet
Hey Kennet,
I'm glad to hear option 1 is what you're looking for.
The detail about keyed topics was to shine light on the fact that in some cases multiple writers sharing a single topic is "natural" and doesn't require using a special qos when each writer has its own (set of) instance(s).
Happy to help,
Roy.