Hello,
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!
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)?
https://community.rti.com/kb/how-do-i-change-multicast-time-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.
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:
https://community.rti.com/static/documentation/connext-dds/7.0.0/doc/manuals/connext_dds_professional/users_manual/users_manual/DISCOVERY_Qos.htm?Highlight=initial_peer#domains_2763211417_595036
https://community.rti.com/static/documentation/connext-dds/7.0.0/doc/manuals/connext_dds_professional/users_manual/users_manual/PartAppsDiscover.htm
https://community.rti.com/kb/how-do-i-set-initial-peers-and-multicast-receive-address-programmatically-or-xml
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:
https://community.rti.com/static/documentation/connext-dds/7.0.0/doc/manuals/connext_dds_professional/users_manual/users_manual/Setting_the_Initial_Peers.htm#53.2.4_Setting_the_Initial_Peers
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.
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!
Huge thank you @Howard 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. The definition of remote static IP addresses in my network within the QoS config as you suggest aligns with what the RTI Engineer told me, so are spot on with that. Since my post and after some Wireshark analysis I've realised that my original post was misleading in that I now believe the TCP / IP protocol is not used as part of the Client & Server App comms. Therefore, I now also agree with your guidance that RTI in my application is using UDP multicast for Client - Server discovery with unicast for message exchange once the Client & Server have discoverd themselves. As well as specifying remote IP addresses, I'm also looking to evaluate configuring RTI's Routing Service or Cloud Discovery Service/Real-Time WAN Transport as recommended by the RTI Engineer. So these are my next steps. Thank you!