Open topic with navigation
The DURABILITY QosPolicy specifies whether acknowledged DDS samples need to be kept in the DataWriter’s queue and made available to late-joining applications. When a late joining application is discovered, available DDS samples will be sent to the late joiner. With the Durability QoS alone, there is no way to specify or characterize the intended consumers of the information and you do not have control over which DDS samples will be kept for late-joining applications. If while waiting for late-joining applications, the middleware needs to free up DDS samples, it will reclaim DDS samples if they have been previously acknowledged by active/matching readers.
There are scenarios where you know a priori that a particular set of applications will join the system: e.g., a logging service or a known processing application. The Required Subscription feature is designed to keep data until these known late joining applications acknowledge the data.
Another use case is when DataReaders become temporarily inactive due to not responding to heartbeats, or when the subscriber temporarily became disconnected and purged from the discovery database. In both cases, the DataWriter will no longer keep the DDS sample for this DataReader. The Required Subscription feature will keep the data until these known DataReaders have acknowledged the data.
To use Required Subscriptions, the DataReaders and DataWriters must have their RELIABILITY QosPolicy kind set to RELIABLE.
Before describing the Required Subscriptions, it is important to understand a few concepts:
The DURABILITY QosPolicy and the Required Subscriptions feature complement each other.
The DurabilityQosPolicy determines whether or not Connext DDS will store and deliver previously acknowledged DDS samples to new DataReaders that join the network later. You can specify to either not make the DDS samples available (DDS_VOLATILE_DURABILITY_QOS kind), or to make them available and declare you are storing the DDS samples in memory (DDS_TRANSIENT_LOCAL_DURABILITY_QOS or DDS_TRANSIENT_DURABILITY_QOS kind) or in permanent storage (DDS_PERSISTENT_DURABILITY_QOS).
Required subscriptions help answer the question of when a DDS sample is considered acknowledged before the DurabilityQosPolicy determines whether to keep it. When required subscriptions are used, a DDS sample is considered acknowledged by a DataWriter when both the active DataReaders and a quorum of required subscriptions have acknowledged the DDS sample. (Acknowledging a DDS sample can be done either at the protocol or application level—see Application Acknowledgment).
Each DataReader can be configured to be part of a named subscription, by giving it a role_name using the ENTITY_NAME QosPolicy (DDS Extension). A DataWriter can then be configured using the AVAILABILITY QosPolicy (DDS Extension) (required_matched_endpoint_groups) with a list of required named subscriptions identified by the role_name. Additionally, the DataWriter can be configured with a quorum or minimum number of DataReaders from a given named subscription that must receive a DDS sample.
When configured with a list of required subscriptions, a DataWriter will store a DDS sample until the DDS sample is acknowledged by all active reliable DataReaders, as well as all required subscriptions. When a quorum is specified, a minimum number of DataReaders of the required subscription must acknowledge a DDS sample in order for the DDS sample to be considered acknowledged. Specifying a quorum provides a level of redundancy in the system as multiple applications or services acknowledge they have received the DDS sample. Each individual DataReader is identified using its own virtual GUID (see DATA_READER_PROTOCOL QosPolicy (DDS Extension)).
© 2017 RTI
Open topic with navigation