Required Subscriptions

31.13 Required Subscriptions

The 47.9 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 47.21 RELIABILITY QosPolicy kind set to RELIABLE.

31.13.1 Named, Required and Durable Subscriptions

Before describing the Required Subscriptions, it is important to understand a few concepts:

Named Subscription: Through the 47.11 ENTITY_NAME QosPolicy (DDS Extension), each DataReader can be given a specific name. This name can be used by tools to identify a specific DataReader. Additionally, the DataReader can be given a role_name. For example: LOG_APP_1 DataReader belongs to the logger applications (role_name = “LOGGER”).
Required Subscription is a named subscription to which a DataWriter is configured to deliver data to. This is true even if the DataReaders serving those subscriptions are not available yet. The DataWriter must store the DDS sample until it has been acknowledged by all active reliable DataReaders and acknowledged by all required subscriptions. The DataWriter is not waiting for a specific DataReader, rather it is waiting for DataReaders belonging to the required subscription by setting their role_name to the subscription name.
Durable Subscription is a required subscription where DDS samples are stored and forwarded by an external service. In this case, the required subscription is served by RTI Persistence Service. See 74.9 Configuring Durable Subscriptions in Persistence Service.

31.13.2 Durability QoS and Required Subscriptions

The 47.9 DURABILITY QosPolicy and the Required Subscriptions feature complement each other.

The DurabilityQosPolicy determines whether or not Connext 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 31.12 Application Acknowledgment).

31.13.3 Required Subscriptions Configuration

Each DataReader can be configured to be part of a named subscription, by giving it a role_name using the 47.11 ENTITY_NAME QosPolicy (DDS Extension). A DataWriter can then be configured using the 47.1 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 48.1 DATA_READER_PROTOCOL QosPolicy (DDS Extension)).