RTI Connext QoS Reference Guide

This document provides a high-level view of the RTI® Connext® QoS Policies in release 7.7.0. For more details, see All QosPolicies in the RTI Connext Core Libraries User's Manual.

1 Basic QoS

Table 1.1 Basic QoS Policies

QoS Policy	Description	Chg.	RxO	Inst.	Entities	Ext.
Batch	Configures mechanism for collecting multiple data samples to be sent in a single network packet	BE			W	Y
DataRepresentation	Specifies which CDR versions and data compression algorithms are offered and requested	BE	Y		T,R,W
DataWriterProtocol	Configures DDS on-the-wire protocol (RTPS), along with WireProtocol QoS for Reliable Topics	BC			W	Y
Deadline	Maximum duration within which an instance is expected to be updated	A	Y	Y	T,R,W
DestinationOrder	Controls how RTI deals with data from multiple DataWriters for the same instance; "by reception timestamp" or "by source timestamp"	BE	Y	Y	T,R,W
Discovery	Configures which DomainParticipants to contact, how to automatically discover and connect with them	BC			D	Y
DiscoveryConfig		BC			D	Y
Durability	Specifies if Connext will store and deliver previously published data to new/late-joining Readers	BE	Y		T,R,W
EntityFactory	Controls Entity behavior as a factory for other entities (i.e., if child entities are created enabled)	A			F,D,P,S
EntityName	Assigns a name to an Entity, pairs DomainParticipant with a Durable Subscription	BE			D,P,S, R,W	Y
History	Controls how much data to store and how stored data is managed for the DataWriter/DataReader within specified ResourceLimits	BE		Y	T,R,W
LatencyBudget	Suggests to the middleware how much time is allowed to deliver data	A	Y		T,R,W
Lifespan	Specifies how long Connext considers data sent by a user application to be valid	A			T,W
Liveliness	Controls mechanism that allows DataReaders to detect when matching DataWriters become disconnected/dead	BE	Y		T,R,W
Logging	Configures the Logging feature	A			F	Y
Monitoring	Configures RTI Monitoring Library 2.0 to collect and distribute telemetry data (metrics and logs) associated with a Connext application, for use by the RTI Observability Framework	A			F	Y
Ownership	Specifies if DataReader can receive new samples for instance of data from multiple DataWriters at same time	BE	Y	Y	T,R,W
OwnershipStrength	Specifies strength used to arbitrate among multiple DataWriters of same instance	A		Y	W
Partition	Adds string IDs for finer-grained matching between entities, such as DataWriters and DataReaders of the same Topic	A			D,P,S	(Y)
Profile	Configures how the DomainParticipantFactory loads XML documents containing QoS profiles	BC			F	Y
Property	Specifies name/value pairs used to configure parameters not exposed via formal QoS policies	A			D,R,W	Y
PublishMode	Specifies whether data samples will be sent in the application thread or a middleware thread	BC			W	Y
Reliability	Indicates whether samples lost by the network should be repaired by the middleware	BE	Y		T,R,W
ResourceLimits	Limits amount of data cached by the middleware	BE			T,R,W
TimeBasedFilter	Sets minimum time period before new data for an instance is provided to a DataReader	BE		Y	R
TopicQueryDispatch	Configures the ability of a DataWriter to publish historical samples	BC			W	Y
TransportBuiltin	Specifies which builtin transports are used	BC			D	Y
TransportMulticast	Sets multicast address and port number on which DataReader will receive data	BC			R	Y
TransportUnicast	Specifies a subset of transports and a port number that can be used by an Entity to receive data	BC			D,R,W	Y
TypeConsistencyEnforcement	Sets rule to determine if a type used to publish a given topic is consistent with that used to subscribe to it	BE			R
WireProtocol	Configures properties for the DDS wire protocol (RTPS)	BC			D	Y

Legend:

Chg. = Changeable

RxO = Request/Offered Semantics

Inst. = Behavior applied per-instance

Ext. = Extension to DDS standard

Chg.

A = Always

BC =Before Creation

BE = Before Enable

Entities

F = DomainParticipantFactory

D = DomainParticipant

T = Topic

P = Publisher

S = Subscriber

W = DataWriter

R = DataReader

Ext.

Y = Yes

(Y) = Partially Yes

(see detailed descriptions

for further explanation)

Blank = No

Table 1.2 Basic QoS Policies per Entity

DomainParticipant

Topic

Publisher

Subscriber

DataWriter

DataReader

RTI Connext QoS Reference Guide

RTI Connext QoS Reference Guide

TypeConsistencyEnforcement

DomainParticipantFactory

In this table, QoS policies are shown in the same order as they appear in the related Entity's QoS structure.

1.1 Batch

Configures mechanism for collecting multiple user data samples to be sent in a single network packet.

This allows you to take advantage of the efficiency of sending larger packets and thus increase effective throughput.

Can dramatically increase the effective throughput for small data packets. Usually, throughput for small packets (data < 2048 bytes) is limited by CPU capacity, not by network bandwidth. Batching many smaller data packets so they are sent in 1 large packet increases network utilization and thus throughput in terms of user data packets per second.

For Reliable topics, batching reduces the Reliable (RTPS) traffic because the Reliable entity is the batch, not the sample.

1.2 DataRepresentation

Specifies which versions of the Extended Common Data Representation (CDR) (version 1 or version 2) and which data compression setting algorithms are offered and requested for your data.

A DataWriter offers one data representation and one data compression algorithm, which indicate the settings the DataWriter uses to serialize and to compress its data. A DataReader requests one or more such representations, which indicate the CDR versions and compression algorithms the DataReader accepts. If a DataWriter's offered representations are contained within a reader’s sequence of requested representations, then the offer satisfies the request, and the policies are compatible. Otherwise, they are incompatible.

1.3 DataWriterProtocol

Configures DDS on-the-wire protocol (RTPS).

Connext uses a standard protocol for packet (user- and meta-data) exchange between applications. This QoS policy, along with DataReaderProtocol, controls configurable portions of the protocol, including configuration of the reliable data delivery mechanism of the protocol on a per DataWriter/DataReader basis.

These parameters control timing and timeouts and give you the ability to tradeoff between speed of data-loss detection and repair, versus the network and CPU bandwidth used to maintain reliability.

It is important to tune the reliability protocol (on a per DataWriter and DataReader basis) to meet the requirements of the end-user application so that data can be sent between DataWriters and DataReaders in an efficient and optimal manner in the presence of data loss. You can also use these QoS policies to control how Connext responds to "slow" reliable DataReaders or ones that disconnect or are otherwise lost.

See the Reliability QoS policy for more on configuring per-DataReader/DataWriter reliability. The History and ResourceLimits QoS also play an important role in the reliable protocol.

1.4 Deadline

For DataReaders: specifies the maximum expected elapsed time between arriving data samples.

For DataWriters: specifies a commitment to publish samples with no greater than this elapsed time between them.

Can be used during system integration to ensure that applications have been coded to meet design specifications.

Can be used at run time to detect when systems are performing outside of design specifications. Receiving applications can take appropriate actions to prevent total system failure when data is not received in time. For topics on which data is not expected to be periodic, the deadline period should be set to an infinite value.

Loss of Deadline results in loss of ownership for topics with Exclusive OwnershipStrength.

1.5 DestinationOrder

Controls how Connext deals with data sent by multiple DataWriters for the same topic.

When multiple DataWriters send data for the same Topic, the order in which data from different DataWriters is received by the applications of different DataReaders may be different. So different DataReaders may not receive the same "last" value when DataWriters stop sending data.

If set to "by reception timestamp":

Data will be delivered by a DataReader in the order in which it was received (which may lead to inconsistent final values).

If set to "by source timestamp":

Data will be delivered by a DataReader in the order in which it was sent. If data arrives on the network with a source timestamp earlier than the source timestamp of the last data delivered, the new data will be dropped. This ordering therefore works best when system clocks are relatively synchronized among writing machines.

Not all data sent by multiple DataWriters may be delivered to a DataReader, and not all DataReaders will see the same data sent by DataWriters. However, all DataReaders will see the same "final" data when DataWriters stop sending data.

Can be used to create systems that have "eventual consistency." Thus intermediate states across multiple applications may be inconsistent, but when DataWriters stop sending changes to the same topic, all applications will end up having the same state.

1.6 Discovery

Configures mechanism used to automatically discover and connect with new remote DomainParticipants.

This QoS specifies the identifiers used by the DomainParticipant to discover other DomainParticipants with which to communicate. This is done via an initial peers list. The middleware will periodically send network packets to these locations, announcing itself to any remote applications that may be present, and will listen for announcements from those applications. This QoS policy also controls the extent of and the transports used for discovery.

Often used with: DiscoveryConfig–to tune timeliness and reliability related parameters for the discovery process.

1.7 DiscoveryConfig

Configures timeliness and reliability settings for discovery.

This QoS policy controls how often discovery data is sent as well as the reliability settings used for discovery topics. The amount of network traffic required by the discovery process can vary widely, based on how your application has configured the middleware's network addressing (e.g., unicast vs. multicast, multicast TTL, etc.), the system’s size, whether all applications are started at the same time or at staggered times, and other factors. Your application can use this policy to make tradeoffs between discovery completion time and network bandwidth utilization. You can also introduce random back-off periods into the discovery process to decrease the probability of network contention when many applications start simultaneously.

Often used with: Discovery–to define the discovery peers.

1.8 Durability

Specifies whether Connext will store and deliver previously published data to new/late-joining DataReaders.

Durability controls whether or not new DataReaders get data that was written by DataWriters previously and how many samples (via writer_depth) the late-joining DataReaders get. The Durability can vary from not at all (the default) to persistent (stored to disk). This QoS policy helps insulate systems from startup dependencies and can increase system tolerance to failure conditions.

Often used with: DurabilityService–to configure the external service parameters.

1.9 EntityFactory

Controls an Entity’s behavior as a ‘factory’ for other entities, such as whether child entities are created in the enabled state.

This QoS policy is useful to synchronize the initialization of Entities. For example, when a DataReader is created in an enabled state, its existence is immediately propagated for discovery and the DataReader's listener is called as soon as data is received. The initialization process for an application may extend beyond the creation of the DataReader, so you may not want for the DataReader to start to receive or process any data until the initialization process is complete. By creating readers in a disabled state, you can make sure that no data is received until the rest of the application initialization is complete.

1.10 EntityName

Assigns a name to an Entity and associates a DomainParticipant with a Durable Subscription.

This QoS policy assigns a name to a DomainParticipant, Publisher, Subscriber, DataWriter, or DataReader; this name will be sent as part of during discovery. The name will also be visible in RTI tools (except for Publishers and Subscribers) to help you visualize and debug your system. It also assigns a role name, which specifies the Durable Subscription to which the DataReader belongs.

Often used with: Availability–if using Durable Subscriptions.

1.11 History

Controls how much data to store and how stored data is managed for a DataWriter or DataReader.

Controls how Connext manages data sent by a DataWriter or received for a DataReader. Two settings are available: KEEP_ALL or KEEP_LAST with a value (depth). KEEP_ALL does not imply that Connext will store infinite data. How much data can actually be stored (and thus memory allocation) is controlled by the ResourceLimits QoS.

When using the KEEP_LAST setting, the value of depth (number of data samples to keep) applies on a per instance-basis (unique key value) for Topics that are keyed. For example, for a Topic that provides data about the positions of aircraft and using the aircraft ID as a key, a KEEP_LAST setting of 1 will tell Connext to keep the last value for each unique aircraft ID.

The major use of history is to help tune the reliability between DataWriters and DataReaders. You must use KEEP_ALL History for both the DataWriter and DataReader if you want strict-reliability (the DataReader must receive all of the data sent by the DataWriter). Using KEEP_LAST on either side, Connext will only guarantee the reliability of the last N (depth) values sent.

Often used with:

Reliability–using the KEEP_LAST kind for History depth, the level of reliability can be tuned.
Durability–for the DataWriter side to specify how much data need to be stored and sent to new DataReaders who request previously published data using the non-VOLATILE Durability settings.

1.12 LatencyBudget

Suggests how much time is allowed to deliver data.

This is an optional QoS; its implementation and usage may be determined by the implementer.

RTI uses this QoS policy to help schedule data to be sent by an asynchronous thread with a Flow Controller. Data with low latency requirements can be sent ahead of data that is not latency sensitive when using this QoS policy and the asynchronous publishing mode for a DataWriter.

The default value is 0, which implies you want to send with minimum latency.

If using this QoS policy, then all DataWriters whose data is sent by the same Flow Controller must set the value for this QoS policy accordingly. The data of any DataWriter that uses the default value for this QoS policy will always be sent ahead of DataWriters with non-zero values for this QoS policy.

Only used with:

PublishMode–specifically when using DDS_ASYNCHRONOUS_PUBLISH_MODE_QoS and a flow controller.
DDSFlowController – specifically the DDS_EDF_FLOW_CONTROLLER_SCHED_POLICY for DDS_FlowControllerProperty_t.

1.13 Lifespan

Specifies how long Connext should consider data sent by a user application to be valid.

Connext will timestamp all data sent and received. When a finite Lifespan is specified for a DataWriter or DataReader, Connext will check to see how long the data has been stored in the DataWriter’s send queue or the DataReader’s receive queue and remove any data that has exceeded its Lifespan duration.

Connext will always compare times from the same local clock when checking Lifespan. Thus, the Lifespan for data in the DataReader uses the time as stamped by the local clock when the data was received as the start time for the Lifespan calculation.

You can use this QoS policy to limit how much data is stored by Connext. Even if configured for KEEP_ALL History QoS, data may be dropped by Connext due to the use of the Lifespan QoS.

May interact with the Reliability QoS. Due to expired Lifespan, data in the DataWriter that has not yet been acknowledged as have been received in a reliable connection may be dropped and thus never repaired if the initial sample was lost.

Data in the DataReader that has not yet been accessed by the user code may also be removed due to an expired Lifespan.

You can use this QoS policy to ensure applications don’t receive or act on data, commands, or messages that are too old and have "expired."

1.14 Liveliness

Configures the mechanism that allows DataReaders to detect when matching DataWriters become disconnected or dead.

In a connectionless communications model, the only way a DataReader can know if it is able to receive data from a DataWriter is if it actually receives a message from the DataWriter. This message can either be real data sent by user code, or a message that indicates that the DataWriter is indeed alive and that all elements of the communications link between the DataWriter and DataReader applications is working (network cards, switches, routers, etc.).

By using the Liveliness QoS, the user configures how the DataWriter application maintains liveliness with the DataReader application and how fast the DataReader application is able to detect when the DataWriter is unable to send data to the DataReader (because the sending application has died or perhaps the link between the two applications has broken).

You can use this to ensure that important messages can be received if they are sent. For example, if a command message like “Emergency Stop” is never sent unless the situation is encountered, Liveliness can be used to periodically send a message to test the end-to-end connectivity of the system so that when an “Emergency Stop” message is sent, it will likely be received by all subscribers.

You can use it at run time to detect when systems are performing outside of design specifications. Receiving applications can take appropriate actions in response to disconnected DataWriters.

1.15 Logging

Configures the logging feature.

Allows users to configure various aspects associated with logging via XML profile files: verbosity, category, print format, and output file.

1.16 Monitoring

Configures the RTI Monitoring Library 2.0, which is used by the RTI Connext Observability Framework to collect and distribute telemetry data (metrics and logs) associated with the observable resources created by a Connext application. These observable resources are DomainParticipants, Publishers, Subscribers, DataWriters, DataReaders, Topics, and applications (an application is a process running Connext).

Note: This QoS policy configures the RTI Monitoring Library 2.0, not the RTI Monitoring Library.

For more information, see the RTI Observability Framework documentation.

1.17 Ownership

Specifies if a DataReader can receive new samples for an instance of data from multiple DataWriters at the same time.

By default, DataReaders for a given topic can receive data from any matching DataWriter for the same topic—this is the "shared" setting for the Ownership QoS policy. You can also configure an application to use "exclusive" Ownership for a topic so that DataReaders only receive data from one DataWriter at a time. Ownership applies on a per key value (instance) basis for Topics that are keyed. Thus, with exclusive Ownership, DataReaders will only receive data from a single DataWriter for a particular instance (unique value for the key) of a Topic. This implies that a DataReader may receive data from multiple DataWriters as long as the DataWriters are sending data for different instances.

The value of Ownership must be the same for a DataWriter to be connected to a DataReader. Either both sides must be shared or both sides must be exclusive. Mismatched DataWriter and DataWriter pairs are not connected and will never exchange data.

The Ownership QoS policy can also be used to create data channels or Topics designed to be taken over by external applications for testing or maintenance.

Often used with:

Liveliness—to detect when DataWriters are dead and change ownership.
OwnershipStrength

1.18 OwnershipStrength

The OwnershipStrength QoS policy is used to determine which DataWriter is allowed to send data (or updates for instances for keyed Topics) to DataReaders when Ownership is exclusive and there are multiple DataWriters all sending data for the same instance. The DataWriter with the highest value for the OwnershipStrength QoS policy will be considered the owner of the instance of the Topic and whose data is delivered to DataReaders. Data for the instance sent by all other DataWriters with lower OwnershipStrength will be dropped by Connext when received at the subscribing application.

An arbitrary but deterministic method is used to select a single DataWriter among multiple DataWriters with the same highest OwnershipStrength, so all DataReaders will receive the data from the same DataWriter even when the OwnershipStrength is the same value.

When the DataWriter with the highest Ownership strength loses its liveliness (as controlled by the Liveliness QoS policy) or misses a deadline (as controlled by the Deadline QoS policy) or whose application quits, dies, or otherwise disconnects, Connext will change ownership of the Topic instance to the DataWriter with the highest OwnershipStrength from the remaining DataWriters.

This QoS policy can help you build systems that have redundant elements to safeguard against component or application failures. When systems have active and hot standby components, the Ownership QoS policy can be used to ensure that data from standby applications are only delivered in the case of the failure of the primary.

Ownership QoS policy can also be used to create data channels or Topics designed to be taken over by external applications for testing or maintenance.

Often used with:

Deadline–to detect when DataWriters have not sent data in time so that a lower strength data is accepted.

1.19 Partition

Adds additional string identifiers for matching DataWriters and DataReaders for the same Topic or for matching DomainParticipants with the same domain ID and domain tag.

Specified for Publishers and Subscribers, the Partition QoS policy can be used to add identifiers in the form of strings that Connext will use to match DataWriters and DataReaders. Normally, DataWriters are connected (matched) to DataReaders of the same Topic (assuming that their QoS settings are mutually compatible). However, by using the Partition QoS policy, additional criteria is used to decide if a DataWriter’s data is allowed to be sent to a DataReader. Referred to as partitions, one or more strings can be added to the DataWriter’s Publisher or DataReader’s Subscriber parent. When the Partition QoS policy is used, then a DataWriter is only connected (matched) to a DataReader for the same Topic only if their Publisher and Subscribers have a common partition (intersecting partitions).

Specified for DomainParticipants, the Partition QoS policy can be used to add identifiers in the form of strings that Connext will use to allow DomainParticipants with the same domain ID and domain tag to communicate with each other.

DomainParticipant partitions and Publisher/Subscriber partitions are independent of each other. You can use both features independently or in combination to provide the right level of isolation.

Direct comparison of partition strings is the nominal way to determine if there is a common partition. However, one can also use strings that contain wildcards (actually regular expressions as defined by the POSIX fnmatch API) as partitions. In that case, as long as one of the wildcard partitions matches one of the concrete partition strings on the other side, then the entities are connected.

The set of partitions of an entity can be dynamically changed. This can be used to quickly control which entities are allowed to connect. This facility is useful for creating temporary separation groups among entities that would otherwise be connected to and exchange data each other. Therefore, if sometimes you want an application to be connected to another application and at other times you don’t, then you can use the Partition QoS policy to dynamically configure the connection topology without stopping/starting or destroying/re-creating applications or entities.

The application of the Partition QoS policy to DomainParticipants is an extension to the OMG Data Distribution Service (DDS) standard API, version 1.4.

1.20 Profile

Configures how XML documents containing QoS profiles are loaded by the DomainParticipantFactory.

QoS values for Entities can be configured in QoS profiles defined in XML documents. The XML documents that define QoS profiles can be passed to Connext as a string in XML format or loaded through XML files found on a file system.

The Profile QoS policy for the DomainParticipantFactory configures Connext to load XML documents via 3 independent mechanisms that may be used together or individually disabled.

Environment variable – the value of the environment variable NDDS_QOS_PROFILES can be used to set the locations of files on the file system that contain XML documents to be loaded automatically by Connext. You can also set a XML-formatted string as a value for the environment variable. You can disable the use of the environment variable using the Profile QoS policy.

Default XML files – there are default locations where Connext will look for XML files to load QoS profiles. These include the current working directory from where an application is started and a file in the distribution directory for Connext. You may disable any or all of these default locations using the Profile QoS policy.

The locations of files as well as strings containing XML-formatted QoS profiles can be specified directly via the Profile QoS policy.

1.21 Property

Specifies name/value pairs used to configure parameters not exposed via formal QoS policies

The Property QoS policy allows name/value pairs (in the form of strings) to be attached to the QoS of different entities. These strings are often used to add configuration parameters to an entity without having to change formal QoS policies. Behaviors configured by means of this policy are often not known a priori (for example, dynamically loaded network transport plug-ins) or are provided on a provisional basis. You may also add your own name/value pairs to the Property QoS policy of an Entity and direct Connext to propagate this information with the Entity’s discovery information so it can be accessed in other applications. This allows you to add meta-information about an Entity for application-specific uses.

Used to configure the property of builtin transports before DomainParticipant creation.
Used to specify dynamic loading of external transports (such as TCP Transport).
Used to specify multiple instances of the builtin transports.
Allows full pluggable transport configuration for non-C/C++ languages (Java, C#, etc.).
Used to select a clock.

Configures Durable Writer History and Durable Reader State for high reliability in the face of component or system failures (see the chapter on "Mechanisms for Achieving Information Durability and Persistence" in the RTI Connext Core Libraries User's Manual).

Allows you to attach additional information to entities—such as for identification, authentication, and authorization.

Often used with:

TransportBuiltin, TransportSelection, TransportUnicast, TransportMulticast—configures aspects of builtin and dynamically loaded transports.
DomainParticipantResourceLimits—configures maximum size of discoverable properties.
Availability, Durability, DurabilityService—also relevant to highly reliable and available systems.

See also: UserData and DataTag—these QoS policies also attach discoverable meta-data to entities.

1.22 PublishMode

Specifies the mechanism that sends user data in an external middleware thread

By default, data is sent in the context of the user thread that calls write()—this is typically the lowest-latency approach. However, there are times when you may want an internal middleware thread to send the data asynchronously instead. Thus when the user thread calls write(), the data is only serialized and copied to an internal buffer. A thread owned by the Publisher is responsible for sending the data when it is scheduled. This QoS policy configures this behavior. It may be SYNCHRONOUS (default) or ASYNCHRONOUS. You can also use this QoS policy to select a Flow Controller to "shape" the flow of data onto the network.

"Shaping" a data flow usually means limiting the maximum data rates that Connext will use to send data for a DataWriter. The flow controller will buffer data sent by the DataWriter faster than the maximum rate configured for the Flow Controller, and then only send the excess data when the send rate drops below the maximum rate.

Note that a single thread will be used to send data for all of the asynchronous DataWriter’s of a Publisher. If you want to have different threads to send data asynchronously, you must use multiple Publishers.

Often used with:

LatencyBudget—controls the scheduling of asynchronously published data onto the network across DataWriters.
AsynchronousPublisher—lower-level settings pertaining to asynchronous publication, like thread priority and options.

See also: Flow Controllers (must be configured via the API, see the RTI Connext Core Libraries User's Manual)

1.23 Reliability

Enables reliability protocol for a DataWriter/DataReader connection.

This QoS policy turns on the RTPS reliability protocol between those DataWriters and DataReaders that set this QoS policy to the RELIABLE value. When the reliability protocol is used, Connext will attempt to repair samples that were not successfully received by reliable DataReaders.

By itself, the Reliability policy does not set the level of reliability for a connection between a DataWriter and DataReader. Instead, the level of reliability is controlled in conjunction with other policies, such as History and ResourceLimits, to determine which data remains relevant and therefore eligible for repair. For example, as a tradeoff for less memory, CPU, and network usage, you can choose a reduced level of reliability where only the last N values are guaranteed to be delivered reliably to DataReaders (N is configurable). With the reduced level of reliability, there are no guarantees that data sent before the last N are received; only the last N data packets are monitored and repaired if necessary.

A connection between a DataWriter and DataReader may be configured for BEST_EFFORT Reliability, which means Connext will not use any resources to monitor or guarantee that the data sent by a DataWriter is received by a DataReader. For some use cases, such as the periodic update of sensor values to a GUI displaying values to a person, "best effort" delivery is often good enough. It is the fastest, most efficient, and least resource-intensive (CPU and network bandwidth) method of getting the newest/latest value for a topic from DataWriters to DataReaders. However, there is no guarantee that the data sent will be received. It may be lost due to a variety of factors, including data loss by the physical transport such as wireless RF or even Ethernet.

For some data streams (topics), you need to be assured that all data from the DataWriter is received reliably by the DataReaders. Connext will ensure data was received and repair any lost data by resending a copy as many times as needed until the DataReader receives it. This level of reliability is considered “strictly reliable.” For strict reliability, use the KEEP_ALL setting for the History QoS policy for both the DataWriter and DataReader along with the RELIABLE setting for the Reliability QoS policy.

The Reliability policy also includes the instance_state_consistency_kind property to support instance state consistency. Instance state consistency refers to the property of a DDS system where all DataReaders of a given Topic have the same view of the states of instances. Recall that an instance state can be ALIVE, NOT_ALIVE_DISPOSED, or NOT_ALIVE_NO_WRITERS. Setting the instance_state_consistency_kind to DDS_RECOVER_INSTANCE_STATE_CONSISTENCY ensures that the instance states on a DataReader are recovered when liveliness is regained with a DataWriter. Instance state consistency does not apply to unkeyed topics (since unkeyed topics have no way to differentiate between instances). The DDS_RECOVER_INSTANCE_STATE_CONSISTENCY instance_state_consistency_kind value requires a RELIABLE kind setting in the Reliability QoS policy.

RELIABLE DataWriters may send data to both BEST_EFFORT and RELIABLE DataReaders, but RELIABLE DataReaders can only receive data from RELIABLE DataWriters. Set exact_reliability_kind_match to true in the DataWriter to save memory and CPU cycles if communication with BEST_EFFORT DataReaders is not required.

DataWriters with DDS_RECOVER_INSTANCE_STATE_CONSISTENCY enabled may send data to DataReaders with or without this setting enabled, but DataReaders with DDS_RECOVER_INSTANCE_STATE_CONSISTENCY enabled can only receive data from DataWriters that have DDS_RECOVER_INSTANCE_STATE_CONSISTENCY enabled.

The RTPS reliability protocol is highly configurable using the DataWriterProtocol and DataReaderProtocol QoS policies.

Most users will need to configure the reliability protocol to meet their real-time requirements since the default configuration is not designed for speedy packet-loss detection and repair. In the examples directory of the Connext installation, you should find an example QoS configuration for the reliability protocol that is better suited for many applications.

To maintain reliability in the face of component or system failures, you can use RTI Persistence Service to store sent data on other nodes or even to disk elsewhere on the network using the Durability and DurabilityService QoS policies.

Often used with:

History—governs how many previously written samples remain relevant; set history kind to KEEP_ALL for TCP-like reliability over connectionless transports like UDP
Lifespan—governs how long previously written samples remain relevant; data with an expired lifespan will not be repaired even if lost
ResourceLimits—governs the total sizes of DataWriter sample caches used to maintain commitments if a finite reliability send window has not been set (see DataWriterProtocol)
Availability, Durability, DurabilityService—configure additional data sources to maintain reliable delivery in the face of partial or total system failure
DataWriterProtocol—a variety of parameters for controlling the RTPS reliability protocol for a reliable DataWriter, including the size of the reliability “send window” and the rate at which heartbeats are sent. This also controls whether reliability will be maintained only by means of negative acknowledgments, or by a combination of positive and negative acknowledgments (the default).
DataReaderProtocol—includes corresponding parameters for controlling the reliability protocol for the reliable DataReader. Among other things, this controls whether reliability will be maintained only by means of negative acknowledgments, or by a combination of positive and negative acknowledgments (the default).

1.24 ResourceLimits

Controls amount of physical memory is allocated for middleware entities; if dynamic allocations are allowed and how they occur; and memory usage among different instance values for keyed topics.

Configures the amount of memory a DataWriter or DataReader may allocate to store data in a local cache (also referred to as send or receive queues, respectively). The max_samples parameter in this policy also has a role in throttling the send rate of reliable DataWriters; however, using the “send window” properties of the DataWriterProtocol QoS policy is the recommended way to configure this behavior.

This QoS policy can limit how much system memory can be allocated by the middleware. For embedded real-time systems and safety-critical systems, predetermination of maximum memory usage is often required. In addition, dynamic memory allocation may introduce non-deterministic latencies in time-critical paths. By setting the initial and maximum settings to the same values for different parameters of this QoS policy, you can be assured that an entity will not dynamically allocate more memory after its initialization phase.

Often used with:

History—configures the window of relevant previously written samples, which must fit within the limits set by the ResourceLimits policy.
Reliability—the physical data storage limits of the DataWriter and DataReader caches can affect the performance of the protocol for reliable connections.

1.25 TimeBasedFilter

Sets a minimum time period before new data for an instance is provided to a DataReader, excess data sent faster than the period set are not sent or otherwise discarded.

DataWriters may send data faster than needed by a DataReader. For example, a DataReader of sensor data that is displayed to a human in a GUI application often does not need data updates faster than a human can reasonably perceive changes in data values. The period between updates is often measured in tenths (0.1) of a second up to several seconds. However, a sensor-information DataWriter may have DataReaders that are processing the sensor information to control parts of the system and thus need new data updates with periods of hundredths (0.01) or thousandths (0.001) of a second. This policy allows you to optimize resource usage (CPU and possibly network bandwidth) by only delivering the required amount of data to different DataReaders and filtering out samples that arrive faster than a rate you specify (in terms of a period of time between data arrival).

You can use this QoS policy reduce the amount of data received by a DataReader in order to avoid overwhelming a potentially slow consumer. You can also use it to reduce the amount of data placed on the network by a DataWriter, to avoid overwhelming network resources.

Different DataReaders for the same Topic are allowed to set their own time-based filters, so that data published faster than the period set by a DataReader will be dropped by the middleware and not delivered to the DataReader—without perturbing other DataReaders.

This time-based data-filtering does not depend on any DataWriter settings. However, it also does not force the DataWriter to send at a specific rate. How fast a DataWriter updates new data is entirely under the control of the user code.

See also: ContentFilteredTopics (Not a QoS policy but a feature in which you can create DataReaders that receive data that are filtered based on the value of the data in addition to time. See the RTI Connext Core Libraries User's Manual.)

1.26 TopicQueryDispatch

Configures the ability of a DataWriter to publish samples in response to a TopicQuery.

Enables a DataWriter to publish historical samples upon reception of a TopicQuery and controls how often they are published. Since a TopicQuery selects previously written samples, the DataWriter must have a non-VOLATILE DurabilityQosPolicy::kind. The ReliabilityQosPolicy::kind must be set to RELIABLE.

A TopicQuery may select multiple samples at once. The writer will publish them periodically, independently from newly written samples. TopicQueryDispatchQosPolicy::publication_period configures the frequency. TopicQueryDispatchQosPolicy::samples_per_period configures the maximum number of samples to publish each period. If the DataWriter blocks during the publication of one of these samples, it will try again the next period. All DataWriters that belong to a single Publisher and enable TopicQueries share the same event thread, but each DataWriter schedules separate events. To configure that thread, see AsynchronousPublisherQosPolicy::topic_query_publication_thread. If the DataWriter is dispatching more than one TopicQuery at the same time, the configuration of this periodic event applies to all of them.

1.27 TransportBuiltin

Specifies which builtin transports are used.

Three transport plugins are built into the core Connext libraries: UDPv4, shared memory, and UDPv6. (This is true for most supported target platforms. However, on certain embedded platforms, shared memory and/or UDPv6 may not be supported. Please consult the Platform Notes for more information.) This QoS policy controls which of these builtin transport plugins are to be used by a DomainParticipant.

By default, the UDPv4 and (on platforms that support it) shared memory transports are enabled. Most applications will not need to change this default.

You may want to disable the shared memory transport if you do not want applications to use shared memory to communicate when running on the same node. This may be the case in a lab environment, for example, where some users kill their applications ungracefully, leaving shared memory regions orphaned and unable to be cleaned up by other users of the same machines. Be aware that the availability of the shared memory transport should be set in the same way for all applications running on the same machine in the same domain. Otherwise, discovery will not complete.

See also: Property—Used to install external (that is, not builtin) transports.

1.28 TransportMulticast

Specifies the multicast address on which a DataReader is to receive its data.

By default, DataWriters will send individually addressed packets to each DataReader that subscribes to the topic of the DataWriter; this is known as unicast delivery. One copy of the data is sent for each DataReader. This configuration is the simplest to configure and the easiest to manage. However, the network bandwidth used by a DataWriter increases linearly with the number of DataReaders. Multicast addressing (on UDP/IP transports) allows a DataWriter to send a single network packet that will be received by many DataReaders. Thus the network bandwidth usage will be nearly constant independent of the number of DataReaders.

Coordinating the multicast address specified by DataReaders can help optimize network bandwidth usage in systems where there are multiple DataReaders for the same Topic. Note that you can also specify a port number as well as a subset of the available transports with which to receive the multicast data. These settings—multicast address, port number, and transports—do not need to be set uniformly for all DataReaders of the same Topic. A DataWriter will automatically detect which DataReaders can be reached at the same network location and which other DataReaders need to be addressed separately.

1.29 TransportUnicast

Specifies a subset of transports and a port number that can be used by an Entity to receive data.

Connext may send data to a variety of Entities, not just DataReaders. For example, reliable DataWriters may receive ACK/NACK packets from reliable DataReaders. During discovery, each Entity announces to remote applications a list of (up to 4) unicast addresses to which the remote application should send data (either user data packets or reliable protocol meta-data such as ACK/NACKs and heartbeats).

By default, the list of addresses is populated automatically with values obtained from the enabled transport plug-ins that are allowed to be used by the Entity (see the TransportBuiltin and TransportSelection QoS policies). The associated ports are automatically determined. This default behavior is appropriate for most applications.

Use this QoS policy to manually select a subset of the available receive addresses for an Entity or to specify a non-default receive port.

1.30 TypeConsistencyEnforcement

Defines rules that determine whether the type used to publish a given topic is consistent with that used to subscribe to it.

This policy specifies a type consistency kind, either DISALLOW_TYPE_COERCION or DDS_ALLOW_TYPE_COERCION (default). When Connext is introspecting the builtin topic data declaration of a remote DataReader in order to determine whether it can match with a local DataWriter, if it observes that no TypeConsistencyEnforcementQosPolicy value is provided, it assumes a kind of DISALLOW_TYPE_COERCION.

1.31 WireProtocol

Configures the DDS on-the-wire protocol (RTPS).

Configures some global RTPS properties. The DataWriterProtocol and DataReaderProtocol QoS policies configure RTPS and reliability properties on a per DataWriter or DataReader basis.