|
RTI Connext Modern C++ API Version 7.7.0
|
<<spec>> Indicates the level of reliability offered/requested by RTI Connext. More...
Classes | |
| struct | dds::core::policy::ReliabilityKind_def |
| The definition of the dds::core::safe_enum ReliabilityKind. More... | |
| class | dds::core::policy::Reliability |
| Indicates the level of reliability in sample delivered that a dds::pub::DataWriter offers or a dds::sub::DataReader requests. More... | |
| struct | rti::core::policy::AcknowledgmentKind_def |
| <<extension>> The enumeration for Reliability acknowledgment kinds More... | |
Enumerations | |
| enum class | rti::core::policy::InstanceStateConsistencyKind { InstanceStateConsistencyKind::none , InstanceStateConsistencyKind::recover_state } |
| <<extension>> The enumeration for instance state consistency kinds More... | |
| enum class | rti::core::policy::OutOfOrderDeliveryKind { OutOfOrderDeliveryKind::disallow , OutOfOrderDeliveryKind::disallow_per_instance , OutOfOrderDeliveryKind::allow } |
| <<extension>> Controls how a best-effort DataReader handles duplicate and out-of-order samples, although there are some impacts to reliable DataReaders, too. More... | |
<<spec>> Indicates the level of reliability offered/requested by RTI Connext.
|
strong |
<<extension>> The enumeration for instance state consistency kinds
| Enumerator | |
|---|---|
| none | Instance states on the DataReader are not guaranteed to be correct after liveliness is regained after a disconnect. 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. |
| recover_state | Instance states on the DataReader are guaranteed to be correct after liveliness is regained after a disconnect. 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 |
|
strong |
<<extension>> Controls how a best-effort DataReader handles duplicate and out-of-order samples, although there are some impacts to reliable DataReaders, too.
| Enumerator | |
|---|---|
| disallow | The DataReader (best-effort or reliable) won't deliver any samples out of order to the user. (Default) 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. |
| disallow_per_instance | Best-effort DataReaders won't deliver samples out of order per-instance. Out-of-order delivery across instances is acceptable (if the lower sequence-number sample is for another instance, it will not be discarded). Reliable DataReaders won't deliver any samples 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 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 rti::core::policy::OutOfOrderDeliveryKind::disallow: no samples will be presented out-of-order. |
| allow | Best-effort DataReaders won't filter samples based on sequence number; all samples reach the application. Reliable DataReaders can deliver samples out-of-order by virtual sequence number (but not by physical sequence number). 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, rti::core::policy::OutOfOrderDeliveryKind::allow goes further: it also allows out-of-order physical sequence numbers, unlike dds.data_reader.state.filter_redundant_samples. |