RTI Connext DDS - Establishing Client_Server comms across subnet boundary

4 posts / 0 new
Last post
Last seen: 2 hours 35 min ago
Joined: 03/01/2023
Posts: 2
RTI Connext DDS - Establishing Client_Server comms across subnet boundary


My knowledge level alas is low in relation to RTI Connext DDS...

In my organisation we are using the middleware to manage the data exchange between a Server and Client App successfully.

From a physical architecture perspective, Client and Server PCs are all hosted within the same subnet.

However, I am now looking at a new configuration where the Client is sat on a remote subnet and I'm finding that the Client and Server are now not able to discover each other across that subnet boundary.

How do I configure RTI Connext DDS to discover a remote Client? The Server is configured with a Client hostname for the Client PC, and clearly I know the IP addresses inc default gateways of all my devices on my network.

The network is inter-connected with 3L switches to manage the routing across the subnets.

Data exchange between the Client and Server is a combination of UDP Multicast streams and TCP_IP messaging.

I'm not aware of running any discovery services at the Client and Server ends.

Any advice for a simpleton hugely appreciated!


Last seen: 1 week 5 days ago
Joined: 09/23/2018
Posts: 57

The problem might be related to the Multicast Time to Live parameter -- the default is 1.   When more then a single switch is involved, you have to bump this up.   

How do I change the multicast time-to-live (TTL)?


As an experiment, you can try running the RTI DDS Ping Utility between the two end points.   Have the publisher on one end and the subscriber on the other.   You can run the ping utility either from the Launcher GUI or from the command line. In both cases,  the ping utility has options of specifying the TTL value.   If bumping the TTL doesn't help, you can try ping with explicitly listed initial peers .. this will help determine if the issue is with multicast not making it through the switches.   Listing explicit IPs will use unicast for discovery of the endpoints.



Howard's picture
Last seen: 17 hours 4 min ago
Joined: 11/29/2012
Posts: 490

You can set the IPs of the hosts that Connext DDS need to discover in the Discovery QoS policy.  Please see these documentation and posts:




When you wrote: "Data exchange between the Client and Server is a combination of UDP Multicast streams and TCP_IP messaging.", do you mean that Connext DDS has been configured to use UDP Multicast and TCP/IP between the client/server apps?

That's unusual because by default, Connext DDS will use multicast for discovery, but only UDP unicast for data exchange.  If you want Connext DDS to use UDP multicast for user data exchange and/or TCP/IP as a network protocol, you have to explicity configure Connext DDS to do so.

If you confirm that Connext DDS is configured to TCP/IP as a network transport, then you have to configure the initial_peers to use the IP address and TCP port of the other other application (e.g., server's IP for the client and client's IP for the server).  Please see this doc:


And finally, if the DDS QoS is actually configuring Connext DDS to use multicast to receive data, then you have to do what Gary wrote in his response...change the multicast TTL used by Connext DDS to a value > 1 so that the Layer 3 switch will pass the multicast packet beween subnets.

Last seen: 2 hours 35 min ago
Joined: 03/01/2023
Posts: 2

Huge thank you @garyb for taking the time to reply to me! Since my post I've had the benefit of receiving some training / support on the middleware by one of the RTI application engineers which has been a great help. I'm not adding any networking components between my Client & Server PCs other than the one switch - all I'm doing is reconfiguring the IP address of the Client PC to be on a different subnet and then configuring a static route at the switch. The lower layer physical connectivity is there as I can ping either way happily and RDP onto the Server from the Client, but it's the mutual discovery that sems to be missing. So I'm note sure about whether the TTL parameter is the root cause here. But your advice to use the Launcher GUI facilities and look at explicity listing IP addresses as peers is very much in line with what the RTI engineer told me. I'm also looking at configuring RTI's Routing Service or Cloud Discovery Service/Real-Time WAN Transport. So these are my next steps. Thank you!