Configures the availability of data. More...

Public Attributes
DDS_Boolean	enable_required_subscriptions
	Enables support for required subscriptions in a DDSDataWriter.

struct DDS_Duration_t	max_data_availability_waiting_time
	Defines how much time to wait before delivering a sample to the application without having received some of the previous samples.

struct DDS_Duration_t	max_endpoint_availability_waiting_time
	Defines how much time to wait to discover DataWriters providing samples for the same data source (virtual GUID).

struct DDS_EndpointGroupSeq	required_matched_endpoint_groups
	A sequence of endpoint groups.

Detailed Description

Configures the availability of data.

Entity:: DDSDataReader, DDSDataWriter

Properties:: RxO = NO
Changeable = YES (only on a DDSDataWriter except for the member DDS_AvailabilityQosPolicy::enable_required_subscriptions)

Usage

This QoS policy is used in the context of two features:

Collaborative DataWriters
Required Subscriptions

Collaborative DataWriters

The Collaborative DataWriters feature allows having multiple DataWriters publishing samples from a common logical data source. The DataReaders will combine the samples coming from the DataWriters in order to reconstruct the correct order at the source.

This QoS policy allows you to configure the ordering and combination process in the DataReader and can be used to support two different use cases:

Ordered delivery of samples in high-availability scenarios One example of this is RTI Persistence Service. When a late-joining DataReader configured with DDS_DurabilityQosPolicy set to DDS_PERSISTENT_DURABILITY_QOS or DDS_TRANSIENT_DURABILITY_QOS joins a DDS domain, it will start receiving historical samples from multiple DataWriters. For example, if the original DataWriter is still alive, the newly created DataReader will receive samples from the original DataWriter and one or more RTI Persistence Service DataWriters (PRSTDataWriters). This policy can be used to configure the sample ordering process on the DataReader.

Ordered delivery of samples in load-balanced scenarios Multiple instances of the same application can work together to process and deliver samples. When the samples arrive through different data-paths out of order, the DataReader will be able to reconstruct the order at the destination. An example of this is when multiple instances of RTI Persistence Service are used to persist the data. Persisting data to a database on disk can be a bottleneck for throughput. You can improve scalability and performance by dividing the workload across different instances of RTI Persistence Service that use different databases. For example, samples larger than 10 are persisted by Persistence Service 1, samples less than or equal to 10 are persisted by Persistence Service 2.

Ordered delivery of samples with Group Ordered Access This policy can also be used to configure the sample ordering process when the Subscriber is configured with DDS_PresentationQosPolicy access_scope set to DDS_GROUP_PRESENTATION_QOS. In this case, the Subscriber must deliver in order the samples published by a group of DataWriters that belong to the same Publisher and have access_scope set to DDS_GROUP_PRESENTATION_QOS.

Each sample published in a DDS domain for a given logical data source is uniquely identified by a pair (virtual GUID, virtual sequence number). Samples from the same data source (same virtual GUID) can be published by different DataWriters. A DataReader will deliver a sample (VGUIDn, VSNm) to the application if one of the following conditions is satisfied:

(VGUIDn, VSNm-1) has already been delivered to the application.
All the known DataWriters publishing VGUIDn have announced that they do not have (VGUIDn, VSNm-1).
None of the known DataWriters publishing GUIDn have announced potential availability of (VGUIDn, VSNm-1) and both timeouts in this QoS policy have expired.

A DataWriter announces potential availability of samples by using virtual heartbeats (HBs).

When DDS_PresentationQosPolicy::access_scope is set to DDS_TOPIC_PRESENTATION_QOS or DDS_INSTANCE_PRESENTATION_QOS, the virtual HB contains information about the samples contained in the DDSDataWriter history.

When DDS_PresentationQosPolicy::access_scope is set to DDS_GROUP_PRESENTATION_QOS, the virtual HB contains information about all DataWriters in the DDSPublisher.

The frequency at which virtual HBs are sent is controlled by the protocol parameters DDS_RtpsReliableWriterProtocol_t::virtual_heartbeat_period and DDS_RtpsReliableWriterProtocol_t::samples_per_virtual_heartbeat.

Required Subscriptions

In the context of Required Subscriptions, this QoS policy can be used to configure a set of Required Subscriptions on a DDSDataWriter.

Required subscriptions are preconfigured, named subscriptions that may leave and subsequently rejoin the network from time to time, at the same or different physical locations. Any time a required subscription is disconnected, any samples that would have been delivered to it are stored for delivery if and when the subscription rejoins the network.

Consistency

For a DataWriter, the setting of AVAILABILITY must be set consistenly with that of the RELIABILITY and DURABILITY.

If DDS_AvailabilityQosPolicy::enable_required_subscriptions is set to DDS_BOOLEAN_TRUE, DDS_ReliabilityQosPolicy::kind must be set to DDS_RELIABLE_RELIABILITY_QOS and DDS_DurabilityQosPolicy must be set to a value different than DDS_VOLATILE_DURABILITY_QOS.

Member Data Documentation

DDS_Boolean DDS_AvailabilityQosPolicy::enable_required_subscriptions

Enables support for required subscriptions in a DDSDataWriter.

[default] DDS_BOOLEAN_FALSE

struct DDS_Duration_t DDS_AvailabilityQosPolicy::max_data_availability_waiting_time

Defines how much time to wait before delivering a sample to the application without having received some of the previous samples.

Collaborative DataWriters

A sample identified by (VGUIDn, VSNm) will be delivered to the application if this timeout expires for the sample and the following two conditions are satisfied:

None of the known DataWriters publishing VGUIDn have announced potential availability of (VGUIDn, VSNm-1).
The DataWriters for all the endpoint groups specified in required_matched_endpoint_groups have been discovered or max_endpoint_availability_waiting_time has expired.

Required Subscriptions

This field is not applicable to Required Subscriptions.

[default] DDS_DURATION_AUTO (DDS_DURATION_INFINITE for DDS_GROUP_PRESENTATION_QOS. Otherwise, 0 seconds)

[range] [0, DDS_DURATION_INFINITE], DDS_DURATION_AUTO

struct DDS_Duration_t DDS_AvailabilityQosPolicy::max_endpoint_availability_waiting_time

Defines how much time to wait to discover DataWriters providing samples for the same data source (virtual GUID).

Collaborative DataWriters

The set of endpoint groups that are required to provide samples for a data source can be configured using required_matched_endpoint_groups.

A non-consecutive sample identified by (VGUIDn, VSNm) cannot be delivered to the application unless DataWriters for all the endpoint groups in required_matched_endpoint_groups are discovered or this timeout expires.

Required Subscriptions

This field is not applicable to Required Subscriptions.

[default] DDS_DURATION_AUTO (DDS_DURATION_INFINITE for DDS_GROUP_PRESENTATION_QOS. Otherwise, 0 seconds)

[range] [0, DDS_DURATION_INFINITE], DDS_DURATION_AUTO

struct DDS_EndpointGroupSeq DDS_AvailabilityQosPolicy::required_matched_endpoint_groups

A sequence of endpoint groups.

Collaborative DataWriters

In the context of Collaborative DataWriters, it specifies the set of endpoint groups that are expected to provide samples for the same data source.

The quorum count in a group represents the number of DataWriters that must be discovered for that group before the DataReader is allowed to provide non consecutive samples to the application.

A DataWriter becomes a member of an endpoint group by configuring the role_name in DDS_DataWriterQos::publication_name.

Required Subscriptions

In the context of Required Subscriptions, it specifies the set of Required Subscriptions on a DDSDataWriter.

Each Required Subscription is specified by a name and a quorum count.

The quorum count represents the number of DataReaders that have to acknowledge the sample before it can be considered fully acknowledged for that Required Subscription.

A DataReader is associated with a Required Subscription by configuring the role_name in DDS_DataReaderQos::subscription_name.

[default] Empty sequence

Public Attributes

Detailed Description

Usage

Consistency

Member Data Documentation