I have been trying to create the following scenario, I am using 3 Docker containers to run the following:
- A track gui #1 is used to receive tracks.
- A radar generator #1, set with exclusive ownership value 50.
- A radar generator #2, set with exclusive ownership value 100.
All of them run in Domain 0 and in the same network.
I expect the following, in order:
- I run the track gui #1.
- I run the radar generator #2, sending only 1 track to the track gui #1, it appears in the GUI as expected.
- I run the radar generator #1, sending the default amount of tracks. Here comes the proble, I would expect the GUI not to be updated at all, since the exclusive ownership should belong to the radar generator #2, which has a value of 100, instead I do see that the GUI gets updated with the tracks sent by the radar generator #1.
A quick note on how I am modifying the XML files to obtain the desired QoS:
In the radar_profiles_no_multicast.xml of both radar generator #1 and #2 I set the following:
In the <datawriter_qos> of both the low-latency and high-throughput profiles:
<ownership>
<kind>EXCLUSIVE_OWNERSHIP_QOS</kind>
</ownership>
<ownership_strength>
<value>50</value> <!-- Set to 100 for radar generator #2 -->
</ownership_strength>
In the <datareader_qos> of both the low-latency and high-throughput profiles:
<ownership>
<kind>EXCLUSIVE_OWNERSHIP_QOS</kind>
</ownership>
I also modified base_profile_no_multicast.xml in the container running track gui #1 to include the following within a <datareader_qos> I created in the MulticastNotAvailable profile:
<ownership>
<kind>EXCLUSIVE_OWNERSHIP_QOS</kind>
</ownership>
To run the programs I used the flag --no-multicast to ensure that the right QoS files are selected. I also tried replicating the <datawriter_qos> and <datareader_qos> content of the radar_profiles_no_multicast.xml into the base_profile_no_multicast.xml of the containers running the radars, but it was of no use. The only thing worthwile I noticed was that removing the previous content from the base_profile_no_multicast.xml of the container running the track gui prevented it from seeing any tracks at all. If I open rtiadminconsole I see for each entity the warning: "Topic contains only data reader(s)" (which is peculiar, since the radars should act as writers). I also questioned whether this is a synchronization issue, but even waiting some times (approx. 1 minute) or increasing the heartbeats of the radars before launching radar generator #1 does not resolve the issue. Is there any clear example I can reference on how to implement this kind of QoS for this example? Note that I am using RTI Connext 7.3.0 with an evaluation license.
For anyone interested I also attached the files mentioned in this post. Any help or suggestion would be much appreciated, since I have tried different methods without success.
I assume that your track topic is keyed and that each "track" that you send has a specific value for the key, and you send values for a set of keys (instances)?
If so, that's your problem. OWNERSHIP is evaluated on a per instance (specific key value) basis. So, a DataReader can receive data from different DataWriters with EXCLUSIVE Ownership if the DataWriters are producing data for different tracks (instances of the Topic).
But you'll see that for instances (tracks) that are being sent by multiple DataWriters, the DataReader will only receive the sample from the highest STRENGTH DataWriter.
BTW, you should check out https://chatbot.rti.com, where you can ask these questions and get immediate answers...:
For example, I asked:
"Why is my DataReader receiving data from 2 different DataWriters using EXCLUSIVE Ownership QoS?"
The issue of a DataReader receiving data from two different DataWriters while using the EXCLUSIVE Ownership QoS can occur due to the following reasons:
Ownership Strength: In EXCLUSIVE ownership, the DataWriter with the highest
ownership_strengthis considered the owner of the instance. If two DataWriters have the sameownership_strength, the system resolves the tie by selecting the DataWriter with the smallest Globally Unique Identifier (GUID). This means that if two DataWriters are writing to the same instance and have the same strength, the DataReader may receive data from both, but only one will be considered the owner at any given time.Keyed Topics: If the Topic is keyed, EXCLUSIVE ownership is determined on a per-instance basis. This means that different instances of the same Topic can have different owners. If the DataWriters are writing to different instances, the DataReader will receive data from both DataWriters, but for different instances.
Liveliness and Deadline: If the owning DataWriter (with the highest strength) fails to assert its liveliness or violates the deadline, the ownership can transfer to another DataWriter. During this transition, the DataReader might temporarily receive data from both DataWriters.
Configuration Mismatch: Ensure that the
ownershipQoS is set toEXCLUSIVEon both the DataWriter and DataReader sides. A mismatch in the QoS settings can lead to unexpected behavior.To resolve this issue, you can:
ownership_strengthvalues are set correctly and uniquely for each DataWriter.For more details, refer to the OWNERSHIP QosPolicy documentation.
Sources: