Kindly explain me the difference between read over content filtered topic and reading a topic with read_w_condition. Also how they can impact performace in real time system
The Global Leader in DDS. Your Systems working as one.
Hey,
Since they are different things, I'll explain what each of them is, when you would use them, and how they impact performance
1. Content Filtered Topics allow readers to pass along only samples which contain data that the application is interested in.
A use case could be: A topic holds all the metadata about all the trucks belonging to a company and an application only wants to receive metadata about one type of trucks belonging to that company. In this case you could either subscribe to the topic and use application logic to filter out data about trucks you don't care about or you could utilize content filtered topics to achieve this.
Using content filtered topics could be good for you for 3 reasons:
1.1. it reduces the amount of logic that you need to write
1.2. filtering can be done much earlier reducing total cpu consumption
1.3. in some cases filtering can be done by the writer so that you can reduce network usage
some risks of content filtered topics:
if a writer does a lot of filtering it can slow the writer down (tradeoffs, tradeoffs, tradeoffs). you can avoid this by making sure (via qos) that only reader side filtering is done (but then you pay with network traffic, that's life).
2. using read conditions allows application to limit the data that is being returned using sample states, view states, and instance states.
What does that mean?
Simply put (I'm going to neglect view states as I have less experience with those):
A reader receives data and stores it in a "cache".
This cache has one or more instances (unkeyed topics have one instance, keyed topics have more).
Each instance holds a collection of samples (basically these are updates for the instance).
How many instances and how many instances are kept by the reader is configured using qos.
Each instance and each sample also have metadata attached to them.
The easiest example would be utilizing sample state.
Sample state can be "any", "read" or "not read". you could use the "not read" sample state to verify that you only read samples that have not been read already by the application. (by default, reading a sample doesn't remove it from the reader cache). alternatively, you may want to utilize instance state to make sure you only read "alive" instances (instances can "die" if they have no more living writers / if they've been disposed of).
to sum up, using read condition helps you "filter" out data from the reader cache using the state of the data, and not using its content.
I am uncertain how different combinations of status and read conditions impact performance, maybe someone from RTI could be of more help in this regard.
Hopefully this helped,
Roy.