DDSI-Extended (DDSI2E) is an extended version of the DDSI2 networking service, giving extra features for:
- Network partitions: Network partitions provide the ability to use alternative multicast addresses for combinations of DCPS topics and partitions to separate out traffic flows, for example for routing or load reduction.
- Security: Encryption can be configured per network partition. This enables configuring encrypted transmission for subsets of the data.
- Bandwidth limiting and traffic scheduling: Any number of ‘network channels’ can be defined, each with an associated transport priority. Application data is routed via the network channel with the best matching priority. For each network channel, outgoing bandwidth limits can be set and the IP ‘differentiated services’ options can be controlled.
Channel and Transport Priority
This attribute sets the transport priority of the channel. Messages sent to the network have a transport_priority quality of service value. Selection of a networking channel is based on the priority requested by the message and the priority offered by the channel. The priority settings of the different channels divide the priority range into intervals. Within a channel, messages are sorted in order of priority.
Can I specify the value for Priority of the channel with Lower limit & Higher Limit for the particular range?
The transport priorities have no explicit mapping onto the operating system’s scheduling priorities. When we say transport priority ranges and intervals, it means you can create multiple channels each with a “transport priority” value. As an example, you might create 4 channels, one with priority 25, one with 50, one with 75 and one with 100. Then messages with transport priority 20 will be sent over the first channel, messages with priority 30 will be sent over the second channel etc. The priority of these messages are programmatically set by the “transport_priority QoS”.
The default priority is 0. Does this mean that it is the lowest or normal priority?
0 is the lowest priority.
Is the priority handled by the DDS library or does it need to be handled by the application?
All transport priorities are handled by the networking services with OpenSplice DDS. The user does not need to have thread priorities within their applications to manage this, the threading priority of the application code is independent to the threading of the network channels.
Are the priority values the same with respect to OpenSplice DDS operating on different platforms?
Priority ranges are comparable across different operating systems, it is the job of OpenSpliceDDS to define the operating system’s scheduling classes and the priorities of each channel in order to satisfy the channel priorities requested in the XML configuration file. A channel with transport priority 100 will always take precedent over one with 50, in that sense the ranges are comparable, but the threading that is selected to achieve this can vary across operating systems.
Could you provide some more information on DiffServField with respect to channel configuration?
The DiffServField value is included in all message packets sent over a particular channel and contains routing information. It uses the “Differentiated Services Code Point” DSCP) standard. It is independent to the network channel priority discussed above.
How does the networking service handle data sent with no channel or transport priority defined?
The networking service will always use a channel with the reliability attribute that matches the Reliability QoS of the message, the only exception to this rule, is the case where there is no channel configured with the matching reliability attribute. In that case the networking service will fall back to the channel that is labeled as default. This will happen if an application writes a message with RELIABLE reliability, while the networking configuration only contains channels with the the reliability attribute set to FALSE.
When there are multiple channels defined with a matching reliability attribute, than the networking will select one of those channels based on the Transport Priority QoS of the message. This value is compared with the priority attribute of the matching channels, and the networking service will select the channel with the the closest priority, equal or higher than that of the Transport Priority QoS of the message. If there is no matching channel with a priority equal or higher than that of the Transport Priority QoS, the channel with the highest priority is chosen.
The traffic of each channel is handled by a specific set of threads, of which the scheduling_class and thread_priority can be configured. These values do not depend upon the value of the Transport Priority QoS, but only on the channel chosen by the method described above. In addition to the choice of channel, the Transport Priority QoS is also used in the channels, where it will be used (among other factors) to determine the sequence in which messages are handled.