Because the publish-subscribe paradigm is connectionless, applications can create publications and subscriptions in any way they choose. As soon as a matching pair of DataWriters and DataReaders exist, then data published by the DataWriter will be delivered to the DataReader. However, a DataWriter may publish data before a DataReader has been created. For example, before you subscribe to a magazine, there have been past issues that were published.
The DURABILITY QosPolicy controls whether or not, and how, published DDS samples are stored by the DataWriter application for DataReaders that are found after the DDS samples were initially written. DataReaders use this QoS to request DDS samples that were published before they were created. The analogy is for a new subscriber to a magazine to ask for issues that were published in the past. These are known as ‘historical’ DDS data samples. (Reliable DataReaders may wait for these historical DDS samples, see Checking DataReader Status and StatusConditions.)
This QosPolicy can be used to help ensure that DataReaders get all data that was sent by DataWriters, regardless of when it was sent. This QosPolicy can increase system tolerance to failure conditions.
Exactly how many DDS samples are stored by the DataWriter or requested by the DataReader is controlled using the HISTORY QosPolicy.
For more information, please see Mechanisms for Achieving Information Durability and Persistence.
The possible settings for this QoS are:
Connext DDSis not required to send and will not deliver any DDS data samples to DataReaders that are discovered after the DDS samples were initially published.
Connext DDSwill store and send previously published DDS samples for delivery to newly discovered DataReaders as long as the DataWriter still exists. For this setting to be effective, you must also set the RELIABILITY QosPolicy kind to Reliable (not Best Effort). Which particular DDS samples are kept depends on other QoS settings such as HISTORY QosPolicy and RESOURCE_LIMITS QosPolicy.
Connext DDSwill store previously published DDS samples in memory using Persistence Service, which will send the stored data to newly discovered DataReaders. Which particular DDS samples are kept and sent by Persistence Service depends on the HISTORY QosPolicy and RESOURCE_LIMITS QosPolicy of the Persistence Service DataWriters. These QosPolicies can be configured in the Persistence Service configuration file or through the DURABILITY SERVICE QosPolicy of the DataWriters configured with DDS_TRANSIENT_DURABILITY_QOS.
Connext DDSwill store previously published DDS samples in permanent storage, like a disk, using Persistence Service, which will send the stored data to newly discovered DataReaders. Which particular DDS samples are kept and sent by Persistence Service depends on the HISTORY QosPolicy and RESOURCE_LIMITS QosPolicy in the Persistence Service DataWriters. These QosPolicies can be configured in the Persistence Service configuration file or through the DURABILITY SERVICE QosPolicy of the DataWriters configured with DDS_PERSISTENT_DURABILITY_QOS.
This QosPolicy includes the members in . For default settings, please refer to the API Reference HTML documentation.
Type |
Field Name |
Description |
DDS_DurabilityQosPolicyKind |
kind |
DDS_VOLATILE_DURABILITY_QOS: DDS_TRANSIENT_LOCAL_DURABILITY_QOS: DDS_TRANSIENT_DURABILITY_QOS: DDS_PERSISTENCE_DURABILITY_QOS: |
DDS_Boolean |
Whether or not a TRANSIENT or PERSISTENT DataReader should receive DDS samples directly from a TRANSIENT or PERSISTENT DataWriter. When TRUE, a TRANSIENT or PERSISTENT DataReaderwill receive DDS samples directly from the original DataWriter. The DataReadermay also receive DDS samples from Persistence Service1Persistence Service is included with the Connext DDS Professional, Evaluation, and Basic package types. It saves DDS data samples so they can be delivered to subscribing applications that join the system at a later time (see Chapter 1 Introduction to RTI Persistence Service). but the duplicates will be filtered by the middleware. When FALSE, a TRANSIENT or PERSISTENT DataReaderwill receive DDS samples only from the DataWriter created by Persistence Service. This ‘relay communication’ pattern provides a way to guarantee eventual consistency. This field only applies to DataReaders. |
With this QoS policy alone, there is no way to specify or characterize the intended consumers of the information. With TRANSIENT_LOCAL, TRANSIENT, or PERSISTENT durability a DataWriter can be configured to keep DDS samples around for late-joiners. However, there is no way to know when the information has been consumed by all the intended recipients.
Information durability can be combined with required subscriptions in order to guarantee that DDS samples are delivered to a set of required subscriptions. For additional details on required subscriptions see Required Subscriptions and AVAILABILITY QosPolicy (DDS Extension).
Suppose you have a DataWriter that sends data sporadically and its DURABILITY kind is set to VOLATILE. If a new DataReader joins the system, it won’t see any data until the next time that write() is called on the DataWriter. If you want the DataReader to receive any data that is valid, old or new, both sides should set their DURABILITY kind to TRANSIENT_LOCAL. This will ensure that the DataReader gets some of the previous DDS samples immediately after it is enabled.
This QosPolicy cannot be modified after the Entity has been created.
The DataWriter and DataReader must use compatible settings for this QosPolicy. To be compatible, the DataWriter and DataReader must use one of the valid combinations shown in .
If this QosPolicy is found to be incompatible, the ON_OFFERED_INCOMPATIBLE_QOS and ON_REQUESTED_INCOMPATIBLE_QOS statuses will be modified and the corresponding Listeners called for the DataWriter and DataReader respectively.
|
|
DataReader requests: |
|||
VOLATILE |
TRANSIENT_LOCAL |
TRANSIENT |
PERSISTENT |
||
DataWriter offers: |
VOLATILE |
4 |
incompatible |
incompatible |
incompatible |
TRANSIENT_ |
4 |
4 |
incompatible |
incompatible |
|
TRANSIENT |
4 |
4 |
4 |
incompatible |
|
PERSISTENT |
4 |
4 |
4 |
4 |
Using this policy with a setting other than VOLATILE will cause Connext DDS to use CPU and network bandwidth to send old DDS samples to matching, newly discovered DataReaders. The actual amount of resources depends on the total size of data that needs to be sent.
The maximum number of DDS samples that will be kept on the DataWriter’s queue for late-joiners and/or required subscriptions is determined by max_samples in RESOURCE_LIMITS Qos Policy.
System Resource Considerations With Required Subscriptions”
By default, when TRANSIENT_LOCAL durability is used in combination with required subscriptions, a DataWriter configured with KEEP_ALL in the HISTORY QosPolicy will keep the DDS samples in its cache until they are acknowledged by all the required subscriptions. After the DDS samples are acknowledged by the required subscriptions they will be marked as reclaimable, but they will not be purged from the DataWriter’s queue until the DataWriter needs these resources for new DDS samples. This may lead to a non efficient resource utilization, specially when max_samples is high or even UNLIMITED.
The DataWriter’s behavior can be changed to purge DDS samples after they have been acknowledged by all the active/matching DataReaders and all the required subscriptions configured on the DataWriter. To do so, set the dds.data_writer.history.purge_samples_after_acknowledgment property to 1 (see PROPERTY QosPolicy (DDS Extension) ).
© 2016 RTI