Question

This question is regarding a roadblock I am currently facing in DDS. I am able to read the Subscriber/Reader Cache using the QueryFilter provided by the respective implementations. But I now want to read the Publisher/Writer Cache and I am not able to do that .

The use case is I am publishing a list of objects and do not want to maintain a list myself locally, since DDS is already doing it. At the Subscriber I am able to get object instances, like I said earlier, using the QueryFilter. But is there any way to do so with the Publisher? I wanted to avoid creating a subscriber at the publisher end or maintain the list locally as well as in GDS.

I am programming in C++ and using OpenSplice, but please do answer even if it is for some other implementation.

Was it helpful?

Solution

There is no DDS standard API available for reading the cache on the DataWriter side. As far as I know, none of the DDS implementations offers anything like that.

The use case is I am publishing a list of objects and do not want to maintain a list myself locally, since DDS is already doing it [in the Publisher/Writer cache].

Well, as a user, you can not be sure what is in the cache on the DataWriter side. The DDS specification does not exactly specify what is in that cache and it does not exist as such in the API.

The purpose of the cache on the DataWriter side is to store data in order to support the quality of service as requested. For a best-effort DataWriter, the cache might not even exist, or contain minimal information about the key-values published. For a reliable DataWriter, the cache might contain samples that are in the process of being delivered reliably, but they might be removed after they have been delivered. For a reliable, non-volatile DataWriter, the cache might contain all samples that need to be available for lat-joining readers.

I say might because it all depends on how the product is implemented.

The only cache-related method on the DataWriter side is lookup_instance().

I wanted to avoid creating a subscriber at the publisher end or maintain the list locally as well as in GDS.

Creating a DataReader at the publisher end seems to do exactly what you need. Why do you want to avoid that?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top