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
deserialized.
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)
Nico.
Hello Nico,
On the reader side you can use the
InstanceHandle_tto 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 theDataReader. 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 theDataReadercache. 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_tonly depends on the key values. But unfortunately, as far as I know, we do not expose a public API to create anInstanceHandle_tfrom the key values. Thelookup_instance()operation does not work for this either: I believe callinglookup_instance()on aDataReaderthat 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_tis 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_tusingread_instance()can be useful for aDataReaderto access just the instances it needs when it needs them. For example if aDataReaderis 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 differentTopicshave objects that are related to each other and when the application receives data on oneDataReaderit needs to access the last values received for the associated object on the otherDataReaderto perhaps aggregate them.Regards,
Gerardo
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
serialization/de-serialization.
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.Regards
Nico
Hello, I am also very interested on how to
calculate InstanceHandle_tfrom the key fieldsThanks for your help.
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?
Thanks,
Juanlu