RTI Connext C API Version 7.4.0

<<spec>> Indicates the level of reliability offered/requested by RTI Connext. More...

Data Structures

struct  DDS_ReliabilityQosPolicy
 <<extension>> <<spec>> Indicates the level of reliability offered/requested by RTI Connext. More...
 

Enumerations

enum  DDS_ReliabilityQosPolicyKind {
  DDS_BEST_EFFORT_RELIABILITY_QOS ,
  DDS_RELIABLE_RELIABILITY_QOS
}
 Kinds of reliability. More...
 
enum  DDS_ReliabilityQosPolicyAcknowledgmentModeKind {
  DDS_PROTOCOL_ACKNOWLEDGMENT_MODE ,
  DDS_APPLICATION_AUTO_ACKNOWLEDGMENT_MODE ,
  DDS_APPLICATION_ORDERED_ACKNOWLEDGMENT_MODE ,
  DDS_APPLICATION_EXPLICIT_ACKNOWLEDGMENT_MODE
}
 <<extension>> Kinds of acknowledgment. More...
 
enum  DDS_InstanceStateConsistencyKind {
  DDS_NO_RECOVER_INSTANCE_STATE_CONSISTENCY ,
  DDS_RECOVER_INSTANCE_STATE_CONSISTENCY
}
 <<extension>> Whether instance state consistency is enabled. More...
 

Variables

const char *const DDS_RELIABILITY_QOS_POLICY_NAME
 Stringified human-readable name for DDS_ReliabilityQosPolicy. More...
 

Detailed Description

<<spec>> Indicates the level of reliability offered/requested by RTI Connext.

Enumeration Type Documentation

◆ DDS_ReliabilityQosPolicyKind

Kinds of reliability.

QoS:
DDS_ReliabilityQosPolicy
Enumerator
DDS_BEST_EFFORT_RELIABILITY_QOS 

Indicates that it is acceptable to not retry propagation of any samples.

Presumably new values for the samples are generated often enough that it is not necessary to re-send or acknowledge any samples.

[default] for DDS_DataReader and DDS_Topic

DDS_RELIABLE_RELIABILITY_QOS 

Specifies RTI Connext will attempt to deliver all samples in its history. Missed samples may be retried.

In steady-state (no modifications communicated via the DDS_DataWriter), RTI Connext guarantees that all samples in the DDS_DataWriter history will eventually be delivered to all the DDS_DataReader objects (subject to timeouts that indicate loss of communication with a particular DDS_Subscriber).

Outside steady state, the HISTORY and RESOURCE_LIMITS policies will determine how samples become part of the history and whether samples can be discarded from it.

[default] for DDS_DataWriter

◆ DDS_ReliabilityQosPolicyAcknowledgmentModeKind

<<extension>> Kinds of acknowledgment.

QoS:
DDS_ReliabilityQosPolicy
Enumerator
DDS_PROTOCOL_ACKNOWLEDGMENT_MODE 

Samples are acknowledged by RTPS protocol.

Samples are acknowledged according to the Real-Time Publish-Subscribe (RTPS) interoperability protocol.

DDS_APPLICATION_AUTO_ACKNOWLEDGMENT_MODE 

Samples are acknowledged automatically after a subscribing application has accessed them.

A sample received by a FooDataReader is acknowledged after the subscribing application accesses it, either through calling FooDataReader_take or FooDataReader_read on the DDS sample. If the read or take operation loans the samples, the acknowledgment is done after FooDataReader_return_loan is called. Otherwise, for read or take operations that make a copy, acknowledgment is done after the read or take operations are executed.

DDS_APPLICATION_EXPLICIT_ACKNOWLEDGMENT_MODE 

Samples are acknowledged after the subscribing application explicitly calls acknowledge on the samples.

Samples received by a DDS_DataReader are explicitly acknowledged by the subscribing application, after it calls either DDS_DataReader_acknowledge_all or DDS_DataReader_acknowledge_sample.

◆ DDS_InstanceStateConsistencyKind

<<extension>> Whether instance state consistency is enabled.

QoS:
DDS_ReliabilityQosPolicy
Enumerator
DDS_NO_RECOVER_INSTANCE_STATE_CONSISTENCY 

Instance state is not restored on a DataReader after reconnecting with a DataWriter until the DataWriter sends a new sample.

When DataReaders rediscover DataWriters, they will not request updated instance state data. DataWriters always provide instance state data alongside each sample update regardless of this setting.

DDS_RECOVER_INSTANCE_STATE_CONSISTENCY 

Instance state is restored on the DataReader after it reconnects with a DataWriter that has regained liveliness, even before the DataWriter sends a new sample.

When DataReaders rediscover DataWriters, they will request updated instance state data. DataWriters will respond to requests for updated instance state data and publish updates on the ServiceRequest channel. DataWriters still provide instance state data alongside each sample update regardless of this setting.

The following limitation applies to using RECOVER_INSTANCE_STATE_CONSISTENCY: If the DDS_DestinationOrderQosPolicyKind is set to DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS, RECOVER_INSTANCE_STATE_CONSISTENCY can only be used if scope is set to idref_DestinationOrderQosPolicyScopeKind_INSTANCE_SCOPE_DESTINATIONORDER_QOS (the default).

Variable Documentation

◆ DDS_RELIABILITY_QOS_POLICY_NAME

const char* const DDS_RELIABILITY_QOS_POLICY_NAME
extern

Stringified human-readable name for DDS_ReliabilityQosPolicy.