Hello.
I am trying to use the RTI Routing for to route the Shapes demo between two separate Linux computers. Each Linux computer is running one instance of RTI Routing and one instance of Shapes demo. Each routing instance is also executed inside a Docker container. I have published the port using the parameter --publish 7400:7400 in the Docker run command. I am usinga slightly modified version of the example tcp_transport.xml, the one for WAN.
The routing seems to only work when I use port 7400 and only with local/participant 1 on domain id 0. When changin port or domain id I also change related config, like update Docker run command or change the domain id the Shapes demo is running at.
Why does it not work to use a domain id of e.g. 9 for participant 1 and the Shapes demo?
RTI routing is starting fine without any notable error or warning when using some other port or domain id. One notable difference, is that the routing instance only shows up in RTI Admin Console when using domain id 0 for participant 1.
Any help would be appreciated!
The XML file used for the routing:
<?xml version="1.0"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="/usr/dds/resource/schema/rti_routing_service.xsd">
<!--
**********************************************************************
RTI Routing service for TCP over WAN
This file use env variable SELF_IP, SELF_PORT and PEER_PORT
to configure the TCP connection.
**********************************************************************
UDP/Shared memory (domain 0) <=> TCP (domain 71)
**********************************************************************
-->
<routing_service name="TCP">
<annotation>
<documentation>
In a WAN, routes from UDP or shared memory to TCP.
</documentation>
</annotation>
<domain_route name="DR_UDPLAN_TCPWAN">
<participant name="1">
<domain_id>0</domain_id>
</participant>
<participant name="2">
<domain_id>71</domain_id>
<participant_qos>
<transport_builtin>
<mask>MASK_NONE</mask>
</transport_builtin>
<property>
<value>
<element>
<name>dds.transport.load_plugins</name>
<value>dds.transport.TCPv4.tcp1</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.library</name>
<value>nddstransporttcp</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.create_function</name>
<value>NDDS_Transport_TCPv4_create</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.parent.classid</name>
<value>NDDS_TRANSPORT_CLASSID_TCPV4_WAN</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.public_address</name>
<value>$(SELF_IP):$(SELF_PORT)</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.server_bind_port</name>
<value>$(PEER_PORT)</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.disable_nagle</name>
<value>1</value>
</element>
</value>
</property>
</participant_qos>
</participant>
<session name="Session">
<auto_topic_route name="FromLocal">
<publish_with_original_info>true</publish_with_original_info>
<input participant="1">
<deny_topic_name_filter>rti/*</deny_topic_name_filter>
<creation_mode>ON_DOMAIN_MATCH</creation_mode>
</input>
<output>
<deny_topic_name_filter>rti/*</deny_topic_name_filter>
<creation_mode>ON_DOMAIN_OR_ROUTE_MATCH</creation_mode>
</output>
</auto_topic_route>
<auto_topic_route name="FromTCP">
<publish_with_original_info>true</publish_with_original_info>
<input participant="2">
<deny_topic_name_filter>rti/*</deny_topic_name_filter>
<creation_mode>ON_DOMAIN_OR_ROUTE_MATCH</creation_mode>
</input>
<output>
<deny_topic_name_filter>rti/*</deny_topic_name_filter>
<creation_mode>ON_DOMAIN_MATCH</creation_mode>
</output>
</auto_topic_route>
</session>
</domain_route>
</routing_service>
Hi Rikard,
So, you state:
So, changing the TCP port used by the TCP transport for the 2nd participant (guessing this is the one used to interconnect Linux computers and changing the domain id for the 1st participant (used to connect to the local shapesdemo) are independent actions. While it's possible that both changes causes a problem in the ability for shapesdemo to connect to each other through the routing services, that only means that there are 2 issues. That is, the problems aren't rooted to a single issue. So you need to address one at a time.
Assuming that you have a configuration that works (I'm not sure what you mean by
I assume that this is something outside of DDS but sets the environment variables used by the XML configuration passed to Routing Service, e.g., $(SELF_IP):$(SELF_PORT) and $(PEER_PORT) correctly...)
then the next step is to change one thing and get that to work.
Another thing to note is that RoutingService is just another DDS application that creates 2 domain participants.
To get shapesdemo to work with Routing Service with a domain ID other than 0, you can first get shapesdemo to work with another instance of shapesdemo on with a domain ID other than 0 (starting both instances of shapesdemo in docker containers like you do with Routing Service).
If that doesn't work, then you'll have to troubleshoot that to get it to work. Hint, it's not a DDS issue, it'll be a Docker configuration issue.
The same approach can be taken for the TCP connection between the Linux boxes. Again, there's nothing special about Routing Service. Thus, I would simplify the problem and use 2 helloworld apps configured via XML to use the TCP transport to connect to each other.
Assuming that you get it to work with port 7400, then try changing the port. There's nothing special about port 7400. Again, it's likely to be an issued that's resolved by modifying your Docker network configuration...or possibly firewalls.
--Howard
Hi Howard.
Thanks for the reply.
I have found the problem, which was that I did not configure NDDS_DISCOVERY_PEERS correctly. I had only included the public IP of the peer. So the routing service could not find the Shapes demo running on the same computer but in another Docker container. Adding local multicast or the Shapes demo Docker container to NDDS_DISCOVERY_PEERS solved the problem.
I still don´t know why it found the Shapes demo when using domain id 0, but now it is working as intended.