A DataReader’s QosPolicies control its behavior. This of QosPolicies as the 'properties' of a DataReader.
The DDS_DataReaderQos structure has the following format:
DDS_DataWriterQos struct { DDS_DurabilityQosPolicy durability; DDS_DeadlineQosPolicy deadline; DDS_LatencyBudgetQosPolicy latency_budget; DDS_LivelinessQosPolicy liveliness; DDS_ReliabilityQosPolicy reliability; DDS_DestinationOrderQosPolicy destination_order; DDS_HistoryQosPolicy history; DDS_ResourceLimitsQosPolicy resource_limits; DDS_UserDataQosPolicy user_data; DDS_OwnershipQosPolicy ownership; DDS_TimeBasedFilterQosPolicy time_based_filter; DDS_ReaderDataLifecycleQosPolicy reader_data_lifecycle; DDS_TypeConsistencyEnforcementQosPolicy type_consistency; // extensions to the DDS standard: DDS_DataReaderResourceLimitsQosPolicy reader_resource_limits; DDS_DataReaderProtocolQosPolicy protocol; DDS_TransportSelectionQosPolicy transport_selection; DDS_TransportUnicastQosPolicy unicast; DDS_TransportMulticastQosPolicy multicast; DDS_PropertyQosPolicy property; DDS_ServiceQosPolicy service; DDS_AvailabilityQosPolicy availability; DDS_EntityNameQosPolicy subscription_name; DDS_TransportPriorotyQosPolicy transport_priority; DDS_TypeSupportQosPolicy type_support; } DDS_DataReaderQos;
Note: set_qos() cannot always be used within a listener callback, see Restricted Operations in Listener Callbacks.
DataReader QosPolicies summarizes the meaning of each policy. (They appear alphabetically in the table.) For information on why you would want to change a particular QosPolicy, see the referenced section. For defaults and valid ranges, please refer to the API Reference HTML documentation.
QosPolicy |
Description |
Availability |
This QoS policy is used in the context of two features:
|
DataReaderProtocol |
This QosPolicy configures the DDS on-the-network protocol, RTPS. See DATA_READER_PROTOCOL QosPolicy (DDS Extension). |
DataReaderResourceLimits |
Various settings that configure how DataReaders allocate and use physical memory for internal resources. See DATA_READER_RESOURCE_LIMITS QosPolicy (DDS Extension). |
Deadline |
For a DataReader, it 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 elapsed time between them. See DEADLINE QosPolicy. |
DestinationOrder |
Controls how Connext DDS will deal with data sent by multiple DataWriters for the same topic. Can be set to "by reception timestamp" or to "by source timestamp". See DESTINATION_ORDER QosPolicy. |
Durability |
Specifies whether or not Connext DDS will store and deliver data that were previously published to new DataReaders. See DURABILITY QosPolicy. |
DurabilityService |
Various settings to configure the external Persistence Service1Persistence Service is provided with the Connext DDS Professional, Evaluation, and Basic package types. used by Connext DDS for DataWriters with a Durability QoS setting of Persistent Durability. See DURABILITY SERVICE QosPolicy. |
EntityName |
Assigns a name to a DataReader. See ENTITY_NAME QosPolicy (DDS Extension). |
History |
Specifies how much data must to stored by Connext DDS for the DataWriter or DataReader. This QosPolicy affects the RELIABILITY QosPolicy as well as the DURABILITY QosPolicy. See HISTORY QosPolicy. |
LatencyBudget |
Suggestion to Connext DDS on how much time is allowed to deliver data. See LATENCYBUDGET QoS Policy. |
Liveliness |
Specifies and configures the mechanism that allows DataReaders to detect when DataWriters become disconnected or "dead." See LIVELINESS QosPolicy. |
Property |
Stores name/value (string) pairs that can be used to configure certain parameters of Connext DDS that are not exposed through formal QoS policies. It can also be used to store and propagate application-specific name/value pairs, which can be retrieved by user code during discovery. See PROPERTY QosPolicy (DDS Extension) . |
ReaderDataLifecycle |
Controls how a DataReader manages the lifecycle of the data that it has received. See READER_DATA_LIFECYCLE QoS Policy. |
Reliability |
Specifies whether or not Connext DDS will deliver data reliably. See RELIABILITY QosPolicy. |
ResourceLimits |
Controls the amount of physical memory allocated for entities, if dynamic allocations are allowed, and how they occur. Also controls memory usage among different instance values for keyed topics. See RESOURCE_LIMITS QosPolicy. |
Service |
Intended for use by RTI infrastructure services. User applications should not modify its value. See SERVICE QosPolicy (DDS Extension). |
TimeBasedFilter |
Set by a DataReader to limit the number of new data values received over a period of time. See TIME_BASED_FILTER QosPolicy. |
TransportMulticast |
Specifies the multicast address on which a DataReader wants to receive its data. Can specify a port number as well as a subset of the available transports with which to receive the multicast data. See TRANSPORT_MULTICAST QosPolicy (DDS Extension). |
TransportPriority |
Set by a DataReader to tell Connext DDS that the data being sent is a different "priority" than other data. See TRANSPORT_PRIORITY QosPolicy. |
TransportSelection |
Allows you to select which physical transports a DataWriter or DataReader may use to send or receive its data. See TRANSPORT_SELECTION QosPolicy (DDS Extension). |
TransportUnicast |
Specifies a subset of transports and port number that can be used by an Entity to receive data. See TRANSPORT_UNICAST QosPolicy (DDS Extension). |
TypeConsistencyEnforcement |
Defines rules that determine whether the type used to publish a given data stream is consistent with that used to subscribe to it. See TYPE_CONSISTENCY_ENFORCEMENT QosPolicy. |
TypeSupport |
Used to attach application-specific value(s) to a DataWriter or DataReader. These values are passed to the serialization or deserialization routine of the associated data type. Also controls whether padding bytes are set to 0 during serialization. See TYPESUPPORT QosPolicy (DDS Extension). |
UserData |
Along with Topic Data QosPolicy and Group Data QosPolicy, used to attach a buffer of bytes to Connext DDS's discovery meta-data. See USER_DATA QosPolicy. |
For a DataReader to communicate with a DataWriter, their corresponding QosPolicies must be compatible. For QosPolicies that apply both to the DataWriter and the DataReader, the setting in the DataWriter is considered what the DataWriter “offers” and the setting in the DataReader is what the DataReader “requests.” Compatibility means that what is offered by the DataWriter equals or surpasses what is requested by the DataReader. See QoS Requested vs. Offered Compatibility—the RxO Property.
Some of the policies may be changed after the DataReader has been created. This allows the application to modify the behavior of the DataReader while it is in use. To modify the QoS of an already-created DataReader, use the get_qos() and set_qos() operations on the DataReader. This is a general pattern for all Entities, described in Changing the QoS for an Existing Entity.
As described in Creating DataReaders, there are different ways to create a DataReader, depending on how you want to specify its QoS (with or without a QoS Profile).
For more information, see Creating DataWriters and Configuring QoS with XML.
Figure 11 Creating a DataReader with Modified QosPolicies (not from a profile)
DDS_DataReaderQos reader_qos;2Note: In C, you must initialize the QoS structures before they are used, see Special QosPolicy Handling Considerations for C (Section on page 1). // initialize reader_qos with default values subscriber->get_default_datareader_qos(reader_qos); // make QoS changes reader_qos.history.depth = 5; // Create the reader with modified qos DDSDataReader * reader = subscriber->create_datareader( topic, reader_qos, NULL, DDS_STATUS_MASK_NONE); if (writer == NULL) { // ... error } // narrow it for your specific data type FooDataReader* foo_reader = FooDataReader::narrow(reader);
Figure 12 Creating a DataReader with a QoS Profile
// Create the datawriter DDSDataWriter * writer = publisher->create_datawriter_with_profile( topic, “MyWriterLibrary”, “MyWriterProfile”, NULL, DDS_STATUS_MASK_NONE); if (writer == NULL) { // ... error }; // narrow it for your specific data type FooDataWriter* foo_writer = FooDataWriter::narrow(writer);
Figure 13 Getting QoS Values from Profile, Changing QoS Values, Creating DataReader with Modified QoS Values
DDS_DataReaderQos reader_qos;3Note: In C, you must initialize the QoS structures before they are used, see Special QosPolicy Handling Considerations for C (Section on page 1). // Get reader QoS from profile retcode = factory->get_datareader_qos_from_profile( reader_qos, “ReaderProfileLibrary”, “ReaderProfile”); if (retcode != DDS_RETCODE_OK) { // handle error } // Makes QoS changes reader_qos.history.depth = 5; DDSDataReader * reader = subscriber->create_datareader( topic, reader_qos, NULL, DDS_STATUS_MASK_NONE); if (participant == NULL) { // handle error }
The equals() operation compares two DataReader’s DDS_DataReaderQoS structures for equality. It takes two parameters for the two DataReader’s QoS structures to be compared, then returns TRUE is they are equal (all values are the same) or FALSE if they are not equal.
There are two ways to change an existing DataReader’s QoS after it is has been created—again depending on whether or not you are using a QoS Profile.
Figure 14 Changing the QoS of Existing DataReader (without a QoS Profile)
DDS_DataReaderQos reader_qos;4Note: In C, you must initialize the QoS structures before they are used, see Special QosPolicy Handling Considerations for C. // Get current QoS. if (datareader->get_qos(reader_qos) != DDS_RETCODE_OK) { // handle error } // Makes QoS changes here reader_qos.history.depth = 5; // Set the new QoS if (datareader->set_qos(reader_qos) != DDS_RETCODE_OK ) { // handle error }
Figure 15 Changing the QoS of Existing DataReader with a QoS Profile
retcode = reader->set_qos_with_profile( “ReaderProfileLibrary”,”ReaderProfile”); if (retcode != DDS_RETCODE_OK) { // handle error }
Several DataReader QosPolicies can also be found in the QosPolicies for Topics (see Setting Topic QosPolicies). The QosPolicies set in the Topic do not directly affect the DataReaders (or DataWriters) that use that Topic. In many ways, some QosPolicies are a Topic-level concept, even though the DDS standard allows you to set different values for those policies for different DataWriters and DataReaders of the same Topic. Thus, the policies in the DDS_TopicQos structure exist as a way to help centralize and annotate the intended or suggested values of those QosPolicies. Connext DDS does not check to see if the actual policies set for a DataReader is aligned with those set in the Topic to which it is bound.
There are many ways to use the QosPolicies’ values set in the Topic when setting the QosPolicies’ values in a DataReader. The most straightforward way is to get the values of policies directly from the Topic and use them in the policies for the DataReader, as shown in Figure 16.
Figure 16 Copying Selected QoS from a Topic when Creating a DataReader
DDS_DataReaderQos reader_qos;5Note: In C, you must initialize the QoS structures before they are used, see Special QosPolicy Handling Considerations for C. DDS_TopicQos topic_qos; // topic and publisher already created // get current QoS for the topic, default QoS for the reader if (topic->get_qos(topic_qos) != DDS_RETCODE_OK) { // handle error } if (publisher->get_default_datareader_qos(reader_qos) != DDS_RETCODE_OK) { // handle error } // Copy specific policies from topic QoS to reader QoS reader_qos.deadline = topic_qos.deadline; reader_qos.reliability = topic_qos.reliability; // Create the DataReader with the modified QoS DDSDataReader* reader = publisher->create_datareader(topic, reader_qos,NULL, DDS_STATUS_MASK_NONE);
You can use the Subscriber’s copy_from_topic_qos() operation to copy all of the common policies from the Topic QoS to a DataReader QoS. This is illustrated in Figure 17.
Figure 17 Copying all QoS from a Topic when Creating a DataReader
DDS_DataReaderQos reader_qos;6Note: In C, you must initialize the QoS structures before they are used, see Special QosPolicy Handling Considerations for C. DDS_TopicQos topic_qos; // topic, publisher, reader_listener already created if (topic->get_qos(topic_qos) != DDS_RETCODE_OK) { // handle error } if (publisher->get_default_datareader_qos(reader_qos) != DDS_RETCODE_OK) { // handle error } // copy relevant QoS from topic into reader’s qos publisher->copy_from_topic_qos(reader_qos, topic_qos); // Optionally, modify policies as desired reader_qos.deadline.duration.sec = 1; reader_qos.deadline.duration.nanosec = 0; // Create the DataReader with the modified QoS DDSDataReader* reader = publisher->create_datareader(topic, reader_qos, reader_listener, DDS_STATUS_MASK_ALL);
The special macro, DDS_DATAREADER_QOS_USE_TOPIC_QOS, can be used to indicate that the DataReader should be created with the QoS that results from modifying the default DataReader QoS with the values specified by the Topic. See Figure 23 and Figure 24 for examples involving DataWriters. The same pattern applies to DataReaders.
For more information on the general use and manipulation of QosPolicies, see Getting, Setting, and Comparing QosPolicies.
© 2017 RTI