Is there a way to determine if a datawriter is the owner (highest strength datawriter) of a topic?
Is there a callback or some state change I can monitor to determine when a datawriter gains/loses ownership of the topic?
Thanks,
pj
The Global Leader in DDS. Your Systems working as one.
Hi pj,
To be precise a DataWriter does not own a Topic. It owns data-instances within the Topic (i.e. data-objects identified by a key). Take for example the RTI Shapes demo 'Squares' are a Topic and the color field is marked as a key field so each color square represents a different Data object. In this situation a DataWriter can be the exclusive owner of the 'green' square while another owns the 'blue' square. Only when two (exclusive ownership) Data writers attempt to write the same data-object (e.g. both try to write the 'blue' square) does the ownership-strength come into play to decide which of the two is received by the DataReaders. There is one exection to this. If a Topic does not designate a key it is logically equivalent to having a single data-object and in this situation there would be a single DataWriter that 'owns' the whole Topic.
To answer your question there is no direct callback to tell a DataWriter whether is has ownership of a specific Data object. However there are some things that you could do to detect it.
You can always know which other DataWriters are in the system publishing the same Topic and what their OWNERSHIP_STRENGTH is. You can detect this by reading the "DCPSPublications" builting DataReader. If your Topic has no keys then you an use that to detect whether your DataWriter is the one with the highest strength.
If your Topic is keyed then the question is more complex because you need to find out the strength of any other DataWriters that are writing the same instances that your own DataWriter writes. Depending on the situation this may or not be simple. One common technique is to create a DataReader that subscribes to the Topic and use the DataReader to see what data it gets for the data-objects you are writing. The SampleInfo that you get along with each data sample contains a unique identifyer of the DataWriter that wrote it. This could be used to detect if it came from the local DataWriter.
In general this type of information is not directly available. The idea is that each application should operate decoupled from the others and not depend on this kind of detail topological knowledge thus making the failover operation more transparent. However I can see there may be cases, specially if you are trying to debug the system or provide tools where it could certainly be useful to have this level of visibility...
Gerardo
Hi Gerardo,
Thanks for the reply. In my particular case, my topics are not keyed so topic and topic instance is the same but I should have probably specified topic instance just to be more clear. I was aware of the difference between keyed and unkeyed topics as it relates to ownership and durability (which I'm also using) but thanks for the clarification non the less.
Although it's convenient to talk about the datawriter "owning" the topic, in reality, isn't the datareader the one that actually determines which datawriter's instance update to accept and which to ignore based on the ownership strength? In other words, doesn't a datareader for a topic see updates from all datawriters of that topic and decides which to accept based on the datawriter's strength?
The reason I'm asking is because in addition to filtering based on topic ownership, I would like to minimize network traffic so if I have a way of determining which datawriter is the "owner" of the topic, then I can also have all other datawriters of that topic stop updating until something happens to cause a change in "ownership" of the topic (ie. lost liveliness, missed deadline, change in ownership strength, owner unregisters instance, etc.) I haven't seen this operating mode as an option anywhere in the users manual (unless I missed it) which is surprising since it would be a very useful option for cases where there are multiple datawriters for a topic with exclusive ownership and high frequency/bandwidth updates. Although I can see how it could be very messy to keep track when keyed instances come into play.
pj