|
RTI Connext C API Version 7.7.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... | |
| enum | DDS_OutOfOrderDeliveryKind { DDS_DISALLOW_OUT_OF_ORDER_DELIVERY , DDS_DISALLOW_OUT_OF_ORDER_DELIVERY_PER_INSTANCE , DDS_ALLOW_OUT_OF_ORDER_DELIVERY } |
| <<extension>> Type of out-of-order delivery that is allowed on a DataReader. More... | |
Variables | |
| const char *const | DDS_RELIABILITY_QOS_POLICY_NAME |
| Stringified human-readable name for DDS_ReliabilityQosPolicy. More... | |
<<spec>> Indicates the level of reliability offered/requested by RTI Connext.
Kinds of reliability.
| 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 |
<<extension>> Kinds of acknowledgment.
| 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. |
<<extension>> Whether instance state consistency is enabled.
| 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 a builtin channel. DataWriters still provide instance state data alongside each sample update regardless of this setting. The following limitation applies to using |
<<extension>> Type of out-of-order delivery that is allowed on a DataReader.
Controls the filtering of out-of-order samples on DataReaders, allowing best-effort DataReaders to accept out-of-order samples instead of dropping them. This feature is particularly useful on modern Linux systems where kernel-level parallelism causes frequent UDP packet reordering, or when Topics carry a mix of large fragmented and small non-fragmented samples. These scenarios can cause unexpectedly high sample loss for best-effort communication. Allowing out-of-order sample delivery enables best-effort DataReaders to deliver all received samples, without the additional overhead of the reliability protocol. This setting has no effect on DataWriters.
| Enumerator | |
|---|---|
| DDS_DISALLOW_OUT_OF_ORDER_DELIVERY | Out-of-order delivery is not allowed on a DataReader. The DataReader won't deliver any samples out of order to the user. (Default) Any out-of-order samples (a sample with a lower sequence number than the highest previously received sequence number) that a best-effort DataReader receives will be discarded. The difference between best-effort and reliable DataReaders with this setting can be illustrated as follows:
You should use this setting if you want to receive only the most recent samples on your best-effort DataReader and do not want to handle out-of-order samples in your application. |
| DDS_DISALLOW_OUT_OF_ORDER_DELIVERY_PER_INSTANCE | Out-of-order delivery is not allowed on a per-instance basis for a best-effort DataReader, or at all for a reliable DataReader. Any out-of-order samples (a sample with a lower sequence number than the highest previously received sequence number) that a best-effort DataReader receives will be discarded on a per-instance basis. Out-of-order delivery across instances, however, is acceptable (if the lower sequence-number sample is for another instance, it will not be discarded). You should use this setting if you want to receive ordered samples per instance on a best-effort DataReader, but may expect some out-of-order samples across different instances. For reliable DataReaders, the behavior with this setting is identical to DDS_DISALLOW_OUT_OF_ORDER_DELIVERY: no samples will be presented out-of-order. |
| DDS_ALLOW_OUT_OF_ORDER_DELIVERY | For best-effort DataReaders, this setting allows both physical and virtual sequence numbers to be out of order. For reliable DataReaders, this setting allows only virtual sequence numbers to be out of order. Any out-of-order samples (a sample with a lower sequence number than the highest previously received sequence number) that a best-effort DataReader receives will be delivered to your application. You should enable this setting if you want to receive all samples on a best-effort DataReader and are prepared to handle out-of-order samples in your application. Reliable DataReaders are allowed to present samples out-of-order to your application when receiving out-of-order virtual sequence numbers. Duplicate samples with identical physical sequence numbers are still filtered out. Using this setting on a reliable DataReader is equivalent to setting the dds.data_reader.state.filter_redundant_samples property to FALSE, because this property only controls filtering based on virtual sequence number ordering and does not affect physical sequence number duplicate filtering. For best-effort DataReaders, DDS_ALLOW_OUT_OF_ORDER_DELIVERY goes further: it also allows out-of-order physical sequence numbers, unlike dds.data_reader.state.filter_redundant_samples. |
|
extern |
Stringified human-readable name for DDS_ReliabilityQosPolicy.