47.26 TRANSPORT_PRIORITY QosPolicy
The TRANSPORT_PRIORITY QosPolicy is optional and only partially supported on certain OSs and transports by RTI. However, its intention is to allow you to specify on a per-DataWriter or per-DataReader basis that the data sent by a DataWriter or DataReader is of a different priority.
DDS does not specify how a DDS implementation shall treat data of different priorities. It is often difficult or impossible for DDS implementations to treat data of higher priority differently than data of lower priority, especially when data is being sent (delivered to a physical transport) directly by the thread that called DataWriter’s write() operation. Also, many physical network transports themselves do not have an end-user controllable level of data packet priority.
In Connext, for the IP-based transports (UDPv4, UDPv6, Real-Time WAN Transport, and TCP), the value set in the TRANSPORT_PRIORITY QosPolicy is used in a setsockopt call to set the differentiated services field (DS field) bits of the IPv4 and IPv6 headers for datagrams sent by a DataWriter or DataReader. It is platform-dependent on how and whether the setsockopt has an effect. On some platforms, such as Windows and Linux, external permissions must be given to the user application in order to set the TOS bits.
Note that for the IP-based transports, the transport priority value is not provided as is to the setsockopt call, but transformed according to the transport_priority_mask, transport_priority_mapping_low, and transport_priority_mapping_high properties (see 51.6 Setting Builtin Transport Properties with the PropertyQosPolicy). In most cases, if you want the priority value to be exactly equal to the DS value set with the setsockopt call, then the only change you need to make is to set transport_priority_mask to 0xff (and keep the transport_priority_mapping_low and transport_priority_mapping_high defaults).
It is incorrect to assume that using the TRANSPORT_PRIORITY QosPolicy will have any effect at all on the end-to-end delivery of data between a DataWriter and DataReader. All network elements such as switches and routers must have the capability and be enabled to actually use the TOS bits to treat higher-priority packets differently. Thus the ability to use the TRANSPORT_PRIORITY QosPolicy must be designed and configured at a system level; just turning it on in an application may have no effect at all.
It includes the member in Table 47.43 DDS_TransportPriorityQosPolicy. For the default and valid range, please refer to the API Reference HTML documentation.
|
Type |
Field Name |
Description |
|
DDS_Long |
value |
Hint as to how to set the priority. |
Connext will propagate the value set on a per-DataWriter or per-DataReader basis to the transport when the DataWriter publishes data. It is up to the implementation of the transport to do something with the value, if anything.
You can set the TRANSPORT_PRIORITY QosPolicy on a Topic and use its value to initialize the TRANSPORT_PRIORITY QosPolicies of DataWriters and DataReaders. The TRANSPORT_PRIORITY QosPolicy of a Topic does not directly affect the operation of Connext, see 18.1.3 Setting Topic QosPolicies.
47.26.1 Example
Should Connext be configured with a transport that can use and will honor the concept of a prioritized message, then you would be able to create a DataWriter of a Topic whose DDS data samples, when published, will be sent at a higher priority than other DataWriters that use the same transport.
47.26.2 Properties
This QosPolicy cannot be modified after the entity is created.
47.26.3 Related QosPolicies
This QosPolicy does not interact with any other policies.
47.26.4 Applicable Entities
47.26.5 System Resource Considerations
The use of this policy does not significantly impact the use of resources. However, if a transport is implemented to use the value set by this policy, then there may be transport-specific issues regarding the resources that the transport implementation itself uses.