I have four hosts called A, B, C, D.
A has IP Address 192.168.0.97.
B has IP Address 192.168.0.99.
C has IP Address 192.168.0.98.
D has IP Address 192.168.0.99.
A and B are connected to each other through an ethernet switch S1.
C and D are connected to each other through an ethernet switch S2.
S1 and S2 are not connected to one another.
Multicast router X is connected to S1 on its downstream interface (192.168.0.100). Its upstream interface (192.168.1.1) is connected to an ethernet switch S3.
Multicast router Y is connected to S2 on its downstream interface (192.168.0.100). Its upstream interface (192.168.1.2) is also connected to ethernet switch S3.
Hosts A, B, C, D all have their default routes set to 192.168.0.100.
X is performing simple network address translation of all outgoing traffic on its downstream interface, updating the source IP to 192.168.1.1.
Y is also performing simple network address translation of all outgoing traffic on its downstream interface, updating the source IP to 192.168.1.2.
Our QOS profile for A, B, C, and D currently specifies one multicast (239.255.0.1) address to be used for discovery and also as the initial_peer. It also contains the same multicast address (239.255.0.1) for user data sending/receiving by adding it to the datareader_qos section.
Plenty of multicast traffic is being routed successfully across X and Y. However, we still see a lot of unicast traffic trying to be sent from A to C and vice versa by sniffing switches S1 and S2.
We also don't see A and C properly subscribed to each other's topics as we would expect, which we believe is because this unicast traffic isn't being routed.
Can we force RTI DDS to only use multicast traffic and disable unicast traffic entirely?
Unfortunately routers X and Y cannot run the DDS Routing Service.
Hello,
do you think that this property on the udp transport can help you?
RTI_INT32 NDDS_Transport_UDPv4_Property_t::unicast_enabled (http://community.rti.com/rti-doc/current/ndds/doc/html/api_c/structNDDS__Transport__UDPv4__Property__t.html#adde305603e3b5ee7272355e57c6c8b10)
best,
Gianpiero
Hi,
Are you using best effort or reliable transport?
You mentioned that you configured the peer list with the unicast address. This will make sure that multicast is used for discovery however for user traffic it will use unicast by default unless you configure it to use unicast for transport. See http://community.rti.com/kb/how-do-i-get-data-reader-receive-data-over-multicast for how to configure user data to use multicast. I didn't see anything mentioned about other unicast configurations you made so my guess is that this is missing.
If you use reliable you will need to configure the reliablity protocol to use multicast as well.
Andre
gianpiero:
When I set the unicast_enabled property in my profile to 0, DDS is unable to create the participant. I get the following error messages:
<Error>:[D0001|ENABLE]DDS_DomainParticipantPresentation_reserve_participant_indexI:!enable reserve participant index
<Error>:[D0001|ENABLE]DDS_DomainParticipant_enableI:Automatic participant index failed to initialize. PLEASE VERIFY CONSISTENT TRANSPORT/DISCOVERY CONFIGURATION.
[NOTE: On Windows, verify at least one network interface is enabled.]
<Error>:DDSDomainParticipant_impl::createI:ERROR, Failed to auto-enable entity
<Error>:DomainParticipantFactory_impl::create_participant():!create failure creating participant
More verbose logging shows that DDS is cycling through ports trying to reserve an index. My guess is that DDS is trying to bind a socket to a multicast address, which fails and it incorrectly thinks it failed because a socket is already bound to the port it tried. So it retries this until it runs out of ports to try.
aodermatt:
We're using Best Effort. As I said we use a multicast address (239.255.0.1) for discovery, our initial peer, and user data. Looking into it further, it looks like the second half of the discovery process is what tries to use unicast. However, we want to disable all unicast traffic because we cannot route it correctly.
br_ray,
What you are seeing goig over unicast is for the reliable endpoint discovery. Currently there is no way to configure the reliability protocol (e.g. ACKS) and liveliness messages to go over multicats instead of unicast. Given that endpoint discoery uses reliabilty the answer to your question is that it is currently not possible to disable unicast entirely.
Andre