InstanceHandle_t () for reading

5 posts / 0 new
Last post
Last seen: 4 years 5 months ago
Joined: 07/12/2012
Posts: 51
InstanceHandle_t () for reading

From the documentation and best practices it seems the handle, of class InstanceHandle_t(), is used to optimize writing of instances.

Is there any advantage to use a handle to optimize reading ? A use case could be reading dynamic data.

Say, one can generate a handle based on the keys and values of a topic and then

use that to read that particular instance with read_instance(). One optimization is that only that instance have to be


Is there an API call to create a handle based on key values, or is there more to it than just key values ?

I am looking to get a handle without reading the data first, that is, without calling :

InstanceHandle_t  lookup_instance (DynamicData key_holder)




Gerardo Pardo's picture
Last seen: 4 months 2 days ago
Joined: 06/02/2010
Posts: 598

Hello Nico,

On the reader side you can use the InstanceHandle_t to access a specific instance. This does not save from deserializing other data because RTI Connext DDS deserializes the data when it gets received, not when it gets accessed by the DataReader. This is actually done for better performance under normal circumstances because it saves a copy.  If the data was not deserialized upon reception it would still have to be copied (in serialized form) from the network socket buffer into the DataReader cache. Then it would have to be de-serialized when the application reads it for the first time.  Given that most data received is eventually read and that the cost of a deserialize is normally not much bigger than a copy it is normally more efficient to deserialize directly from the socket buffer and save the copy.

The InstanceHandle_t only depends on the key values. But unfortunately, as far as I know, we do not expose a public API to create an InstanceHandle_t from the key values.  The lookup_instance() operation does not work for this either: I believe calling lookup_instance() on a DataReader that has never received the instance will fail. I am not completely sure and need to double-check but this is what I recall.  

There are some internal ways to do this because the I InstanceHandle_t is obtained using a deterministic algorithm from the Key fields. Basically it has two parts: A serialization of the key fields with an MD5 applied when the serialized key size exceeds 16Bytes followed by some extra flags.  I agree it would be a useful thing to have and if you need this we can perhaps post some code on how to do this...

Once you have an InstanceHandle_t using read_instance() can be useful for a DataReader to access just the instances it needs when  it needs them. For example if a DataReader is configured with a history depth deeper than 1 and it gets a new value, the application may also want to read previous values for the same instance. Another common use-case is when two different Topics have objects that are related to each other and when the application receives data on one DataReader it needs to access the last values received for the associated object on the other DataReader to perhaps aggregate them.



Last seen: 4 years 5 months ago
Joined: 07/12/2012
Posts: 51

Hi Gerardo,

Does your statements regarding when and how serialization take place also apply to DynamicData ? I suspect that I am confusing the use of the DynamicData API with


The use cases you mentioned are useful ones, but in my case I want to selectively use the DynamicData API only for instances that

are of interest.

If a code example is available on how to generate InstanceHandle_t(), it will be very useful.



Last seen: 4 months 3 weeks ago
Joined: 01/27/2014
Posts: 22

Hello, I am also very interested on how to calculate InstanceHandle_t from the key fields

Thanks for your help.

Last seen: 1 year 5 months ago
Joined: 01/15/2013
Posts: 94

Hi Nico,

For selective reading (or selective writing, for best efficiency) based on any fields in your types (including key fields), you could use ContentFilteredTopics.

A ContentFilteredTopic allows you to define a filter expression and parameters and associate them to an existing Topic in your system. The expression can't be modified during runtime, but the parameters can. The filtering can happen on the DataReader side or on the DataWriter side, which really improves performance on the network and the system because the samples are evaluated against the filter on the DataWriter's side and are not sent if they don't pass the filter. For specific documentation on ContentFilteredTopics, please see section 5.4 in the RTI Connext DDS Core Libraries and Utilities User's Manual.

Do you think a ContentFilteredTopic could fit your use-case?