DDS_DurabilityQosPolicy Struct Reference

This QoS policy specifies whether or not RTI Connext will store and deliver previously published data samples to new DDSDataReader entities that join the network later. More...

Public Attributes
DDS_DurabilityQosPolicyKind	kind
	The kind of durability.
DDS_Boolean	direct_communication
	<<extension>> Indicates whether or not a TRANSIENT or PERSISTENT DDSDataReader should receive samples directly from a TRANSIENT or PERSISTENT DDSDataWriter

Detailed Description

This QoS policy specifies whether or not RTI Connext will store and deliver previously published data samples to new DDSDataReader entities that join the network later.

Entity:

DDSTopic, DDSDataReader, DDSDataWriter

Status:

DDS_OFFERED_INCOMPATIBLE_QOS_STATUS, DDS_REQUESTED_INCOMPATIBLE_QOS_STATUS

Properties:

RxO = YES
Changeable = UNTIL ENABLE

See Also

DURABILITY_SERVICE

Usage

It is possible for a DDSDataWriter to start publishing data before all (or any) DDSDataReader entities have joined the network.

Moreover, a DDSDataReader that joins the network after some data has been written could potentially be interested in accessing the most current values of the data, as well as potentially some history.

This policy makes it possible for a late-joining DDSDataReader to obtain previously published samples.

By helping to ensure that DataReaders get all data that was sent by DataWriters, regardless of when it was sent, using this QoS policy can increase system tolerance to failure conditions.

Note that although related, this does not strictly control what data RTI Connext will maintain internally. That is, RTI Connext may choose to maintain some data for its own purposes (e.g., flow control) and yet not make it available to late-joining readers if the DURABILITY policy is set to DDS_VOLATILE_DURABILITY_QOS.

Transient and Persistent Durability

For the purpose of implementing the DURABILITY QoS kind TRANSIENT or PERSISTENT, RTI Connext behaves as if for each Topic that has DDS_DurabilityQosPolicy::kind of DDS_TRANSIENT_DURABILITY_QOS or DDS_PERSISTENT_DURABILITY_QOS there is a corresponding "built-in" DDSDataReader and DDSDataWriter configured with the same DURABILITY kind. In other words, it is as if somewhere in the system, independent of the original DDSDataWriter, there is a built-in durable DDSDataReader subscribing to that Topic and a built-in durable DataWriter re-publishing it as needed for the new subscribers that join the system. This functionality is provided by the RTI Persistence Service.

The Persistence Service can configure itself based on the QoS of your application's DDSDataWriter and DDSDataReader entities. For each transient or persistent DDSTopic, the built-in fictitious Persistence Service DDSDataReader and DDSDataWriter have their QoS configured from the QoS of your application's DDSDataWriter and DDSDataReader entities that communicate on that DDSTopic.

For a given DDSTopic, the usual request/offered semantics apply to the matching between any DDSDataWriter in the domain that writes the DDSTopic and the built-in transient/persistent DDSDataReader for that DDSTopic; similarly for the built-in transient/persistent DDSDataWriter for a DDSTopic and any DDSDataReader for the DDSTopic. As a consequence, a DDSDataWriter that has an incompatible QoS will not send its data to the RTI Persistence Service, and a DDSDataReader that has an incompatible QoS will not get data from it.

Incompatibilities between local DDSDataReader and DDSDataWriter entities and the corresponding fictitious built-in transient/persistent entities cause the DDS_REQUESTED_INCOMPATIBLE_QOS_STATUS and DDS_OFFERED_INCOMPATIBLE_QOS_STATUS to change and the corresponding Listener invocations and/or signaling of DDSCondition objects as they would with your application's own entities.

The value of DDS_DurabilityServiceQosPolicy::service_cleanup_delay controls when RTI Persistence Service is able to remove all information regarding a data instances.

Information on a data instance is maintained until the following conditions are met:

1. The instance has been explicitly disposed (instance_state = NOT_ALIVE_DISPOSED),

and

2. All samples for the disposed instance have been acknowledged, including the dispose sample itself,

and

3. A time interval longer that DDS_DurabilityServiceQosPolicy::service_cleanup_delay has elapsed since the moment RTI Connext detected that the previous two conditions were met. (Note: Only values of zero or DDS_DURATION_INFINITE are currently supported for the service_cleanup_delay)

The utility of DDS_DurabilityServiceQosPolicy::service_cleanup_delay is apparent in the situation where an application disposes an instance and it crashes before it has a chance to complete additional tasks related to the disposition. Upon restart, the application may ask for initial data to regain its state and the delay introduced by the service_cleanup_delay will allow the restarted application to receive the information on the disposed instance and complete the interrupted tasks.

Compatibility

The value offered is considered compatible with the value requested if and only if the inequality offered kind >= requested kind evaluates to 'TRUE'. For the purposes of this inequality, the values of DURABILITY kind are considered ordered such that DDS_VOLATILE_DURABILITY_QOS < DDS_TRANSIENT_LOCAL_DURABILITY_QOS < DDS_TRANSIENT_DURABILITY_QOS < DDS_PERSISTENT_DURABILITY_QOS.

Member Data Documentation

DDS_DurabilityQosPolicyKind DDS_DurabilityQosPolicy::kind

The kind of durability.

[default] DDS_VOLATILE_DURABILITY_QOS

DDS_Boolean DDS_DurabilityQosPolicy::direct_communication

<<extension>> Indicates whether or not a TRANSIENT or PERSISTENT DDSDataReader should receive samples directly from a TRANSIENT or PERSISTENT DDSDataWriter

When direct_communication is set to DDS_BOOLEAN_TRUE, a TRANSIENT or PERSISTENT DDSDataReader will receive samples from both the original DDSDataWriter configured with TRANSIENT or PERSISTENT durability and the DDSDataWriter created by the persistence service. This peer-to-peer communication pattern provides low latency between end-points.

If the same sample is received from the original DDSDataWriter and the persistence service, the middleware will discard the duplicate.

When direct_communication is set to DDS_BOOLEAN_FALSE, a TRANSIENT or PERSISTENT DDSDataReader will only receive samples from the DDSDataWriter created by the persistence service. This brokered communication pattern provides a way to guarantee eventual consistency.

[default] DDS_BOOLEAN_TRUE