18.1.3 Setting Topic QosPolicies
A Topic’s QosPolicies control its behavior, or more specifically, the behavior of the DataWriters and DataReaders of the Topic. You can think of the policies as the ‘properties’ for the Topic. The DDS_TopicQos structure has the following format:
DDS_TopicQos struct {
DDS_TopicDataQosPolicy topic_data;
DDS_DurabilityQosPolicy durability; DDS_DurabilityServiceQosPolicy durability_service; 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_TransportPriorityQosPolicy transport_priority; DDS_LifespanQosPolicy lifespan; DDS_OwnershipQosPolicy ownership;
DDS_DataRepresentationQosPolicy representation } DDS_TopicQos;
Table 18.2 Topic QosPolicies summarizes the meaning of each policy (arranged alphabetically). For information on why you would want to change a particular QosPolicy, see the section noted in the Reference column. For defaults and valid ranges, please refer to the API Reference HTML documentation for each policy.
QosPolicy |
Description |
DataRepresentation |
Specifies which versions of the Extended Common Data Representation (CDR) are offered and requested. See 47.3 DATA_REPRESENTATION QosPolicy. During Publisher_copy_from_topic_qos, only the first DataRepresentationId_t element is copied to the DataWriterQos. The whole sequence is copied to the DataReaderQos during Subscriber_copy_from_topic_qos. |
Deadline |
For a DataReader, specifies the maximum expected elapsed time between arriving DDS data samples. For a DataWriter, specifies a commitment to publish DDS samples with no greater elapsed time between them. |
DestinationOrder |
Controls how Connext 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 47.8 DESTINATION_ORDER QosPolicy. |
Durability |
Specifies whether or not Connext will store and deliver data that were previously published to new DataReaders. See 47.9 DURABILITY QosPolicy. |
DurabilityService |
Various settings to configure the external Persistence Service used by Connextfor DataWriters with a Durability QoS setting of Persistent Durability. See 47.10 DURABILITY SERVICE QosPolicy. |
History |
Specifies how much data must to stored by Connext for the DataWriter or DataReader. This QosPolicy affects the 47.21 RELIABILITY QosPolicy as well as the 47.9 DURABILITY QosPolicy. See 47.12 HISTORY QosPolicy. |
LatencyBudget |
Suggestion to Connext on how much time is allowed to deliver data. See 47.13 LATENCYBUDGET QoS Policy. |
Lifespan |
Specifies how long Connext should consider data sent by an user application to be valid. See 47.14 LIFESPAN QoS Policy. |
Liveliness |
Specifies and configures the mechanism that allows DataReaders to detect when DataWriters become disconnected or "dead." See 47.15 LIVELINESS QosPolicy. |
Along with Ownership Strength, specifies if DataReaders for a topic can receive data from multiple DataWriters at the same time. See 47.17 OWNERSHIP QosPolicy. |
|
Reliability |
Specifies whether or not Connext will deliver data reliably. See 47.21 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 47.22 RESOURCE_LIMITS QosPolicy. |
TopicData |
Along with Group Data QosPolicy and User Data QosPolicy, used to attach a buffer of bytes to Connext's discovery meta-data. See 45.1 TOPIC_DATA QosPolicy. |
TransportPriority |
Set by a DataWriter to tell Connext that the data being sent is a different "priority" than other data. See 47.26 TRANSPORT_PRIORITY QosPolicy. |
18.1.3.1 Configuring QoS Settings when the Topic is Created
As described in 18.1.1 Creating Topics, there are different ways to create a Topic, depending on how you want to specify its QoS (with or without a QoS profile).
In Figure 18.2: Creating a Topic with Default QosPolicies , we saw an example of how to create a Topic with default QosPolicies by using the special constant, DDS_TOPIC_QOS_DEFAULT, which indicates that the default QoS values for a Topic should be used. The default Topic QoS values are configured in the DomainParticipant; you can change them with the DomainParticipant’s set_default_topic_qos() or set_default_topic_qos_with_profile() operations (see 16.3.7.5 Getting and Setting Default QoS for Child Entities).
To create a Topic with non-default QoS values, without using a QoS profile, use the DomainParticipant’s get_default_topic_qos() operation to initialize a DDS_TopicQos structure. Then change the policies from their default values before passing the QoS structure to create_topic().
You can also create a Topic and specify its QoS settings via a QoS profile. To do so, call create_topic_with_profile().
If you want to use a QoS profile, but then make some changes to the QoS before creating the Topic, call get_topic_qos_from_profile(), modify the QoS and use the modified QoS when calling create_topic().
18.1.3.2 Comparing QoS Values
The equals() operation compares two Topic’s DDS_TopicQoS structures for equality. It takes two parameters for the two Topics’ QoS structures to be compared, then returns TRUE is they are equal (all values are the same) or FALSE if they are not equal.
18.1.3.3 Changing QoS Settings After the Topic Has Been Created
There are two ways to change an existing Topic’s QoS after it is has been created—again depending on whether or not you are using a QoS Profile.
To change QoS programmatically (that is, without using a QoS Profile), see the example code in Figure 18.3: Changing the QoS of an Existing Topic (without a QoS Profile). It retrieves the current values by calling the Topic’s get_qos() operation. Then it modifies the value and calls set_qos() to apply the new value. Note, however, that some QosPolicies cannot be changed after the Topic has been enabled—this restriction is noted in the descriptions of the individual QosPolicies.
You can also change a Topic’s (and all other Entities’) QoS by using a QoS Profile. For an example, see Figure 18.4: Changing the QoS of an Existing Topic with a QoS Profile. For more information, see Chapter 50 Configuring QoS with XML.
For the C API, use DDS_TopicQos_INITIALIZER or DDS_TopicQos_initialize(). See 42.2 Special QosPolicy Handling Considerations for C.
Figure 18.3: Changing the QoS of an Existing Topic (without a QoS Profile)
DDS_TopicQos topic_qos;
// Get current QoS. topic points to an existing DDSTopic. if (topic->get_qos(topic_qos) != DDS_RETCODE_OK) { // handle error } // Next, make changes. // New ownership kind will be Exclusive topic_qos.ownership.kind = DDS_EXCLUSIVE_OWNERSHIP_QOS; // Set the new QoS if (topic->set_qos(topic_qos) != DDS_RETCODE_OK ) { // handle error }