I am using DDS Ping to test out communication between two networks but run into problems with the NAT IP address. Here is the setup.
Server A has IP address 172.5.1.100 on network A and the NDDS_DISCOVERY_PEERS is 12@udpv4://172.5.18.200,12@udpv4://172.5.1.100
Server B has internal IP address 10.3.1.5 on network B and external IP address of 172.5.18.200. The NDDS_DISCOVERY_PEERS is 12@udpv4://172.5.18.200,12@udpv4://172.5.1.100
Both servers are running Windows 10 and the network profiles are private and firewalls are off.
Server A can ping Server B external IP address 172.5.18.200 and Server B can ping Server A 172.5.1.100.
I tried to run DDS Ping on Server B to be the publisher and Server A to be the subscriber. The subscriber just didn't get any messages and I noticed in the wireshark capture, somehow Server A was sending packets to the internal IP address of server B (10.3.1.5). Any ideas where did Server A get the internal IP address of Server B from?
Any help would be greatly appreciated.
When a DomainParticipant starts, it queries the OS for the IP addresses of the network interfaces. A host is not aware of its external address. It only knows about its internal address. A DomainParticipant will send a list of its local addresses to remote DomainParticipants to let the remote participants know how to contact it (i.e., to which address(es) to send UDP packets to reach the local participant).
So when Server B sends discovery packets to Server A, it has, by default, the local IP address of the host of Server B.
But because Server B is behind a NAT router, Server A cannot contact Server B via Server B's local address.
Now assuming that the NAT router is configured to do port forwarding such data packets arriving on specific ports on the external IP address are forward to Server B, then you can configure the Connext DDS UDP transport properties to use the External IP address in the discovery packet.
Please see this:
https://community.rti.com/static/documentation/connext-dds/7.1.0/doc/api/connext_dds/api_cpp/structNDDS__Transport__UDPv4__Property__t.html#a4fda981516c74d50d31abe161d4f7381
However, the builtin UDP transport will use multiple ports, which all need to be port forwarded in the Router's NAT configuration. If that is not possible, then I suggest for you to look in to the RTI Real-Time WAN transport instead...that can be configured to use a single port for communications...making your NAT Router configuration easier...and depending on the Router (and NAT type), even unnecessary.
You can read about the RTI Real-Time Wan Transport here:
https://community.rti.com/static/documentation/connext-dds/7.1.0/doc/manuals/connext_dds_professional/users_manual/users_manual/PartRealtimeWAN.htm
Thank you Howard.
I added public_address to the XML file on the Server B DDS Ping but I am still seeing the internal address 10.3.1.5 in Wireshark. Is this the correct property name dds.transport.UDPv4.builtin.public_address?
<property>
<value>
<element>
<name>dds.transport.UDPv4.builtin.public_address</name>
<value>172.5.18.200</value>
</element>
</value>
</property>
Where are you setting this property? What version of Connext DDS are you using? The property name looks fine.
A better way is to use
<domain_participant_qos>
<transport_builtin>
<udpv4>
<public_address> </public_address>
</udpv4>
</transport_builtin>
I put the property at the wrong profile. It is working now. I am using 5.3. Now I see the public address in the Wireshark capture. Thank you for you help.