This QosPolicy specifies the multicast address on which a DataReader wants to receive its data. It can also specify a port number as well as a subset of the available transports with which to receive the multicast data.
By default, DataWriters will send individually addressed packets for each DataReader that subscribes to the topic of the DataWriter—this is known as unicast delivery. Thus, as many copies of the data will be sent over the network as there are DataReaders for the data. The network bandwidth used by a DataWriter will thus increase linearly with the number of DataReaders.
Multicast is a concept supported by some transports, most notably UDP/IP, so that a single packet on the network can be addressed such that it is received by multiple nodes. This is more efficient when the same data needs to be sent to multiple nodes. By using multicast, the network bandwidth usage will be constant, independent of the number of DataReaders.
Coordinating the multicast address specified by DataReaders can help optimize network bandwidth usage in systems where there are multiple DataReaders for the same Topic.
The QosPolicy structure includes the members in .
|
Type |
Field Name |
Description |
|
DDS_TransportMulticastSettingSeq |
value |
A sequence of multicast locators. (See Locator Format.) |
|
DDS_TransportMulticastKind |
This field can be set to one of the following two values: DDS_AUTOMATIC_TRANSPORT_MULTICAST_QOS or DDS_UNICAST_ONLY_TRANSPORT_MULTICAST_QOS. If it is set to DDS_AUTOMATIC_TRANSPORT_MULTICAST_QOS, the behavior depends on the content of DDS_TransportMulticastQosPolicy::value: If DDS_TransportMulticastQosPolicy::value does not have any elements, multicast will not be used. If DDS_TransportMulticastQosPolicy::value first element has an empty address, the address will be obtained from DDS_TransportMulticastMappingQosPolicy. If none of the elements in DDS_TransportMulticastQosPolicy::value are empty, and at least one element has a valid address, then that address will be used. If it is set to DDS_UNICAST_ONLY_TRANSPORT_MULTICAST_QOS, then multicast will not be used. |
|
Type |
Field Name |
Description |
|
DDS_StringSeq |
A sequence of transport aliases that specifies which transports should be used to receive multicast messages for this DataReader. |
|
|
char * |
A multicast group address to which the DataWriter should send data for this DataReader. |
|
|
DDS_Long |
The port that should be used in the addressing of multicast messages destined for this DataReader. A value of 0 will cause Connext DDS to use a default port number based on domain ID. See Ports Used for Discovery. |
To take advantage of multicast, the value of this QosPolicy must be coordinated among all of the applications on a network for DataReaders of the same Topic. For a DataWriter to send a single packet that will be received by all DataReaders simultaneously, the same multicast address must be used.
To use this QosPolicy, you will also need to specify a port number. A port number of 0 will cause Connext DDS to automatically use a default value. As explained in Ports Used for Discovery, the default port number for multicast addresses is based on the domain ID. Should you choose to use a different port number, then for every unique port number used by Entities in your application, depending on the transport, Connext DDS may create a thread to process messages received for that port on that transport. See Connext DDS Threading Model for more about threads.
Threads are created on a per-transport basis, so if this QosPolicy specifies multiple transports for a receive_port, then a thread may be created for each transport for that unique port. Some transports may be able to share a single thread for different ports, others can not. Note that different Entities can share the same port number, and thus, the same thread will process all of the data for all of the Entities sharing the same port number for a transport.
Also note that if the port number specified by this QoS is the same as a port number specified by a TRANSPORT_UNICAST QoS, then the transport may choose to process data received both via multicast and unicast with a single thread. Whether or not a transport must use different threads to process data received via multicast or unicast for the same port number depends on the implementation of the transport.
Notes:
In an airport, there may be many different monitors that display current flight information. Assuming each monitor is controlled by a networked application, network bandwidth would be greatly reduced if flight information was published using multicast.
Figure 20 shows an example of how to set this QosPolicy.
Figure 20 Setting Up a Multicast DataReader
...
DDS_DataReaderQos reader_qos;
reader_listener = new HelloWorldListener();
if (reader_listener == NULL) {
// handle error
}
// Get default data reader QoS to customize
retcode = subscriber->get_default_datareader_qos(reader_qos);
if (retcode != DDS_RETCODE_OK) {
// handle error
}
// Set up multicast reader
reader_qos.multicast.value.ensure_length(1,1);
reader_qos.multicast.value[0].receive_address =
DDS_String_dup("239.192.0.1");
reader = subscriber->create_datareader(
topic,reader_qos,
reader_listener, DDS_STATUS_MASK_ALL);
This QosPolicy cannot be modified after the Entity is created.
For compatibility between DataWriters and DataReaders, the DataWriter must be able to send to the multicast address that the DataReader has specified.
On Ethernet-based systems, the number of multicast addresses that can be “listened” to by the network interface card is usually limited. The exact number of multicast addresses that can be monitored simultaneously by a NIC depends on its manufacturer. Setting a multicast address for a DataReader will use up one of the multicast-address slots of the NIC.
What happens if the number of different multicast addresses used by different DataReaders across different applications on the same node exceeds the total number supported by a NIC depends on the specific operating system. Some will prevent you from configuring too many multicast addresses to be monitored.
Many operating systems will accommodate the extra multicast addresses by putting the NIC in promiscuous mode. This means that the NIC will pass every Ethernet packet to the operating system, and the operating system will pass the packets with the specified multicast addresses to the application(s). This results in extra CPU usage. We recommend that your applications do not use more multicast addresses on a single node than the NICs on that node can listen to simultaneously in hardware.
Depending on the implementation of a transport, Connext DDS may need to create threads to receive and process data on a unique-port-number basis. Some transports can share the same thread to process data received for different ports; others like UDPv4 must have different threads for different ports. In addition, if the same port is used for both unicast and multicast, the transport implementation will determine whether or not the same thread can be used to process both unicast and multicast data. For UDPv4, only one thread is needed per port–independent of whether the data was received via unicast or multicast data. See Receive Threads for more information.
© 2016 RTI