2

The KEEP_LAST_HISTORY QoS setting for a DataReader limits the amount of recently received samples kept by the DataReader on a per-instance basis. As documented, for example, by RTI:

For a DataReader: Connext DDS attempts to keep the most recent depth DDS samples received for each instance (identified by a unique key) until the application takes them via the DataReader's take() operation.

Besides valid data samples, in DDS a DataReader will also receive invalid samples, e.g. to indicate a change in liveliness or to indicate the disposal of an instance. My questions concern how the history QoS settings affect these samples:

  • Are invalid samples treated the same as valid samples when it comes to a KEEP_LAST_HISTORY setting? For example, say I use the default setting of keeping only the latest sample (history depth of 1), and a DataWriter sends a valid data sample and then immediately disposes the instance. Do I risk missing either of the samples, or will the invalid sample(s) be handled specially in any way (e.g. in a separate buffer)?
  • In either case, can anyone point me to where the standard provides a definitive answer?
  • Assuming the history depth setting affects all (valid and invalid) samples, what would be a good history depth setting on a keyed (and Reliable) topic, to make sure I miss neither the last datum nor the disposal event? Is this then even possible in general without resorting to KEEP_ALL_HISTORY?

Just in case there are any (unexpected) implementation-specific differences, note that I am using RTI Connext 5.2.0 via the modern C++ API.

mindriot
  • 5,413
  • 1
  • 25
  • 34

1 Answers1

1

I could not verify it since I don't have a licence vor Connext anymore. I also haven't found any explicit specification in the user or api manual. But to answer your first question: I think valid and invalid samples are treated equally when it comes to using the history qos. the reason why I think so is the following code in the on_data_available callback for datareaders.

retcode = fooDataReader_take(
    foo_data_reader,
    &data_seq, 
    &info_seq, 
    DDS_LENGTH_UNLIMITED,
    DDS_ANY_SAMPLE_STATE,
    DDS_ANY_VIEW_STATE, 
    DDS_ANY_INSTANCE_STATE);

you can explicitly specify which sample state you wish to receive (in this case any sample state). additionally, the sample info for each sample read with the datareader contains the information if a sample is valid or not. Again, I'm not 100% sure as I couldn't verify it, but I think there is no speciall handling/automatic handling of invalid samples, you handle them like the valid ones through the sample, view and instance state.

regarding the "good value" for history qos: this depends on your application and how frequently data is exchanged and accessed. you'll have to figure it out by trying. hope this helps at least a little bit.

Pete
  • 265
  • 6
  • 24
  • 1
    Thanks for your answer. I think you're _probably_ right, but I'm still hoping someone can find a definitive answer somewhere. My searches so far have been fruitless. – mindriot Nov 09 '16 at 07:53