We are running a DDS micro 2.4.10 as a writer and a DDS (5.3.0) node as a reader, and we would like the data to be sent only over multicast, not unicast.
However, we see the data being sent via unicast AND multicast to the same single reader. Sending each data packet twice is not good.
We are using wireshark to verify the data is being sent twice for only one subscription. Wireshark is being run on a third computer that is connected to a managed switch port which is receiving all of the traffic of the other ports.
We've tried setting the reader's QoS:
<qos_profile name="Benchmark.Data_1" base_name="BenchmarkQosLibrary::Benchmark.Data">
<datareader_qos>
<multicast>
<value>
<element>
<receive_address>239.255.1.1</receive_address>
</element>
</value>
</multicast>
</datareader_qos>
</qos_profile>
We've tried adjusting the writer's enabled_transports:
std::string topicMulticastString("_udp://239.255.1.1");
DDS_StringSeq_set_maximum(&data_writer_QoS.transport.enabled_transports, 1);
DDS_StringSeq_set_length(&data_writer_QoS.transport.enabled_transports, 1);
*REDA_StringSeq_get_reference(&data_writer_QoS.transport.enabled_transports,0) = DDS_String_dup(topicMulticastString.c_str());
But the data always seems to be sent twice.
Adding a complication is the fact that we have the same reader code that seems to behave differently if we compile it differently and run it on different systems on the network (therefore, we can't determine whether the difference is from the compiler or from the network topology or system characteristics)
When DDS Reader is run on System A, all of the traffic for this topic is multicast only, and no unicast is detected.
When DDS Reader is run on System B, all of the traffic is first sent over multicast, then over unicast.
Using multicast-only is very important for us, but I'm very concerned with this statement from the micro manual:
When interoperating with RTI Connext DDS, RTI Connext Micro must specify at least one unicast transport for each DataWriter and DataReader, either from DDS_DomainParticipantQos::transports or the endpoint idref_DataReaderQos_transport and DDS_DataWriterQos::transport, as it expects to use the unicast transport's RTPS port mapping to determine automatic participant IDs if needed. This also affects RTI Connext Micro itself, where participant IDs must be set manually if only multicast transports are enabled.
We've just run the System A executable on System B (using different stdc++ libraries), and we saw the unicast/multicast problem.
Therefore, it appears that the problem is one of operating system, physical hardware and/or network topology. These are all linux systems.
System A is a 4.4.26 kernel, Mentor Graphics.
System B is a 3.10.0 linux kernel, Centos.
As an additional note, we compiled this application using DDS proper and the data was properly multicasted.
So it appears to be limits to Micro, and only on this system.
Hi Aaron,
Your observations of first multicast, then unicast may be indicative of first-time written multicast data not being received by the subscriber, resulting in resending reliable repair unicast data.
1) Are reliable endpoints used? I assume so.
1A) If reliable, in the Wireshark captures, are the unicast RTPS messages reliable repairs? They would have a pattern of an ACKNACK (INFO_DST, ACKNACK), then a repair data (INFO_TS, INFO_DST, DATA), a HEARTBEAT (INFO_TS, INFO_DST, HEARTBEAT), and then a positive ACK (INFO_DST, ACKNACK).
1B) Can you share your Wireshark captures?
2) Are multicast routes enabled from A to B, and B to A?
2A) Does your network require multicast TTL > 1 between A and B? Micro's default multicast TTL is 1. If needed, increase UDP_InterfaceFactoryProperty multicast_ttl.
3) What are the discovery peer addresses?
Regarding multicast-only in Micro, if a DataReader has a multicast receive address, a Micro DataWriter will publish new data to that reader only over multicast. If the DataReader is reliable, a Micro DataWriter will send repair data over unicast if available, otherwise it will send repairs over multicast. Connext DDS requires a reliable endpoint to have at least one unicast locator so that reliability HEARTBEATs and ACKNACKs, and repair data, can be directed to the endpoint, rather than sent to all members of a multicast group. Micro, on the other hand, allows an endpoint to be configured with only multicast locators, with the trade-off of all group members receiving each other's reliablity traffic.
Regards,
Edward