|Specifies the kind of history to be kept. |
|Specifies the number of samples to be kept, when the |
|<<eXtension>> Specifies how a writer should handle previously written samples to a new reader. |
This QoS policy specifies how much data must to stored by RTI Data Distribution Service for a DDSDataWriter or DDSDataReader. It controls whether RTI Data Distribution Service should deliver only the most recent value, attempt to deliver all intermediate values, or do something in between.
On the publishing side, this QoS policy controls the samples that should be maintained by the DDSDataWriter on behalf of existing DDSDataReader entities. The behavior with regards to a DDSDataReader entities discovered after a sample is written is controlled by the DURABILITY policy.
On the subscribing side, this QoS policy controls the samples that should be maintained until the application "takes" them from RTI Data Distribution Service.
When a DDSDataWriter sends data, or a DDSDataReader receives data, the data sent or received is stored in a cache whose contents are controlled by this QoS policy. This QoS policy interacts with DDS_ReliabilityQosPolicy by controlling whether RTI Data Distribution Service guarantees that all of the sent data is received (DDS_KEEP_ALL_HISTORY_QOS) or if only the last N data values sent are guaranteed to be received (DDS_KEEP_ALL_HISTORY_QOS)--this is a reduced level of reliability.
The amount of data that is sent to new DataReaders who have configured their DDS_DurabilityQosPolicy to receive previously published data is also controlled by the History QoS policy.
Note that the History QoS policy does not control the physical sizes of the send and receive queues. The memory allocation for the queues is controlled by the DDS_ResourceLimitsQosPolicy.
kind is DDS_KEEP_LAST_HISTORY_QOS (the default), then RTI Data Distribution Service will only attempt to keep the latest values of the instance and discard the older ones. In this case, the value of
depth regulates the maximum number of values (up to and including the most current one) RTI Data Distribution Service will maintain and deliver. After N values have been sent or received, any new data will overwrite the oldest data in the queue. Thus the queue acts like a circular buffer of length N.
The default (and most common setting) for
depth is 1, indicating that only the most recent value should be delivered.
kind is DDS_KEEP_ALL_HISTORY_QOS, then RTI Data Distribution Service will attempt to maintain and deliver all the values of the instance to existing subscribers. The resources that RTI Data Distribution Service can use to keep this history are limited by the settings of the RESOURCE_LIMITS. If the limit is reached, then the behavior of RTI Data Distribution Service will depend on the RELIABILITY. If the Reliability
kind is DDS_BEST_EFFORT_RELIABILITY_QOS, then the old values will be discarded. If Reliability
kind is RELIABLE, then RTI Data Distribution Service will block the DDSDataWriter until it can deliver the necessary old values to all subscribers.
refilter is DDS_NONE_REFILTER_QOS, then samples written before a DataReader is matched to a DataWriter are not refiltered by the DataWriter.
refilter is DDS_ALL_REFILTER_QOS, then all samples written before a DataReader is matched to a DataWriter are refiltered by the DataWriter when the DataReader is matched.
refilter is DDS_ON_DEMAND_REFILTER_QOS, then a DataWriter will only refilter samples that a DataReader requests.
depthmust be consistent with the RESOURCE_LIMITS
max_samples_per_instance. For these two QoS to be consistent, they must verify that depth <= max_samples_per_instance.
Specifies the kind of history to be kept.
Specifies the number of samples to be kept, when the
kind is DDS_KEEP_LAST_HISTORY_QOS.
If a value other than 1 (the default) is specified, it should be consistent with the settings of the RESOURCE_LIMITS policy. That is:
[range] [1,100 million], <= DDS_ResourceLimitsQosPolicy::max_samples_per_instance