Hello,
I'd like to connect RTI DDS applications running on two different networks (both connected to my pc), but I struggled in finding details about the type of traffic generated by the RTI DDS system. Is it TCP or UDP traffic ? Is it a connected service ? in the case, on which port ? Any detail would be useful
Thanks
Hi,
By default, RTI Connext DDS uses UDP as the underlying transport. The middleware can also be configured to use TCP. One thing to consider is that if you do not change anything, when the two applications are started, they will try to discover each other using UDP multicast. If multicast traffic is restricted across your networks you can change this configuration and use unicast by configuring the initial peers for the application Participants.
These are some useful links:
https://community.rti.com/glossary/discovery --> Briefly explains the discovery process
https://community.rti.com/howto/configure-rti-connext-dds-not-use-multicast --> Explains how to configure your applications to not use multicast
Regards,
- Fernando
Thank you.
topic discovery works fine, but for some reason I can't receive messages. I guess that the messages carrying actual data are sent to a specific address (unicast). Which port is used for this purpose ? I want to route messages between two local networks, so I don't have any restriction, can use multicast and everything else, I just need to figure out what kind of routing rule to apply (on linux)
Hi,
What do you mean by topic discovery works? Are you monitoring the Publication or Subscription Built-in Topics? The ports use to exchange information depend on the Domain ID. The following link explains how they are calculated. I wonder if it is a firewall or NAT problem.
https://community.rti.com/howto/statically-configure-firewall-let-omg-dds-traffic-through
Regards,
- Fernando
It means that running the adminConsole on a node on net B I can see the topics published by nodes on net A, but I don't receive any message for them (I try to subscribe and get nothing).
Anyway, many thanks for the info. I need to put this on hold for a couple of days, but I will give it a new try as soon as possible
Hi Fernando,
still trying to figure out the issue. Regarding your question, I'm inclined to think that the problem is natting since:
* domain discovery works (suggesting that there's no UDP filtering on the fw, being multicast there's no natting issue)
* nor nodes on network A or the default gateway for network A are aware of network B. My question now is: would the rti dds communication protocol keep working if I introduce natting for the nodes on network B ? I just wonder whether it would be a problem for nodes on network A to receive packets for different nodes on network B all with the same source address
Dario
Hi Dario,
It is possible that natting is the issue. There are a few things that we can try:
1) For simple NAT scenarios our UDPv4 transport offers a property that you could use to configure the public address of your NAT.
See https://community.rti.com/static/documentation/connext-dds/6.0.0/doc/api/connext_dds/api_c/structNDDS__Transport__UDPv4__Property__t.html#a4fda981516c74d50d31abe161d4f7381
This solution requires proper configuration (port forwarding) of the routers providing the NAT.
The UDPv4 property configuring the public address is this: dds.transport.UDPv4.builtin.public_address
2) For more complicated NATs scenarios, RTI provides a WAN transport that implements UDP hole punching to traverse the NATs. This transport requires deploying a STUN server with a public address that is visible from both networks.
See Part 5: RTI Secure WAN Transport in our user's manual for additiona info.
https://community.rti.com/static/documentation/connext-dds/6.0.0/doc/manuals/connext_dds/RTI_ConnextDDS_CoreLibraries_UsersManual.pdf
The advantage of this solution is that it does not require port forwarding. However, it only works with a few types of NATs (Cone NATs) and requires deploying a STUN server.
3) Another option is to use TCP as the underlying transport. TCP is more friendly to NAT than UDP. RTI provides a TCP transport. For more info take a look into Part 8: RTI TCP Transport in tbe user's manual
Regards,
- Fernando