Almost every object in the Connext DDS API is associated with QoS policies that govern its behavior. These policies govern everything from the amount of memory the object may use to store incoming or outgoing data, to the degree of reliability required, to the amount of meta-traffic that the middleware will send on the network, and many others. The following is a short summary of just a few of the available policies:
Reliability: Specifies whether or not the middleware will deliver data reliably. The reliability of a connection between a DataWriter and DataReader is entirely user configurable. It can be done on a per DataWriter-DataReader connection.
For some use cases, such as the periodic update of sensor values to a GUI displaying the value 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. But 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 Ethernet.
However, there are data streams (topics) in which you want an absolute guarantee that all data sent by a DataWriter is received reliably by DataReaders. This means that the middleware must check whether or not data was received, and repair any data that was lost by resending a copy of the data as many times as it takes for the DataReader to receive the data.
When a DataWriter sends data or a DataReader receives data, the data sent or received is stored in a cache whose contents are controlled by the History QosPolicy. The History QosPolicy can tell the middleware to store all of the data that was sent or received, or only store the last n values sent or received. If the History QosPolicy is set to keep the last n values only, then after n values have been sent or received, any new data will overwrite the oldest data in the queue. The queue thus acts like a circular buffer of length n.
This QoS policy interacts with the Reliability QosPolicy by controlling whether or not the middleware guarantees that (a) all of the data sent is received (using the KEEP_ALL setting of the History QosPolicy) or (b) that only the last n data values sent are received (a reduced level of reliability, using the KEEP_LAST setting of the History QosPolicy). See the Reliability QosPolicy for more information.
Also, the amount of data sent to new DataReaders whose Durability QosPolicy (see below) is set to receive previously published data is controlled by the History QosPolicy.
The middleware attaches timestamps to all data sent and received. When you specify a finite Lifespan for your data, the middleware will compare the current time with those timestamps and drop data when your specified Lifespan expires. You can use the Lifespan QosPolicy to ensure that applications do not receive or act on data, commands or messages that are too old and have "expired."
Liveliness: Specifies and configures the mechanism that allows DataReaders to detect when DataWriters become disconnected or "dead." It can be used during system integration to ensure that systems meet their intended responsiveness specifications. It can also be used during run time to detect possible losses of connectivity.
When the DataWriter with the highest Ownership strength loses its liveliness (as controlled by the Liveliness QosPolicy) or misses a deadline (as controlled by the Deadline QosPolicy) or whose application quits, dies, or otherwise disconnects, the middleware will change ownership of the topic to the DataWriter with the highest Ownership Strength 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 QosPolicy can be used to ensure that data from standby applications are only delivered in the case of the failure of the primary.
Deadline: For a DataReader, this QoS specifies the maximum expected elapsed time between arriving DDS data samples. For a DataWriter, it specifies a commitment to publish DDS samples with no greater than this elapsed time between them.
This policy can be used during system integration to ensure that applications have been coded to meet design specifications. It can be used during 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.
You can specify an object's QoS two ways: (a) programmatically, in your application's source code or (b) in an XML configuration file. The same parameters are available, regardless of which way you choose. For complete information about all of the policies available, see Chapter 4 in the RTI Connext DDS Core Libraries User's Manual or see the API Reference HTML documentation.
The examples covered in this document are intended to be configured with XML files.
By default, examples are copied into your home directory the first time you run RTI Launcher or any script in <NDDSHOME>/bin. This document refers to the location of the copied examples as <path to examples>.
Wherever you see <path to examples>, replace it with the appropriate path.
Default path to the examples:
Where 'your Windows documents folder' depends on your version of Windows. For example, on Windows 7, the folder is C:\Users\your user name\Documents; on Windows Server 2003, the folder is C:\Documents and Settings\your user name\Documents.
Note: You can specify a different location for rti_workspace. You can also specify that you do not want the examples copied to the workspace.
You can find several example configurations, called profiles, in the directory examples/connext_dds/qos. The easiest way to use one of these profile files is to either set the environment variable NDDS_QOS_PROFILES to the path of the file you want, or copy that file into your current working directory with the file name USER_QOS_PROFILES.xml before running your application.
© 2015 RTI