Hi
i am testing out the rti docker routing for docker and remote computer. I had consulted
https://community.rti.com/kb/how-use-rti-connext-dds-communicate-across-docker-containers-using-bridge-driver
and tried out in these following combinations:
1) Without rti routing, i tested out publisher and subscriber in windows and linux and no issue in publishing and receiving.
When used in docker container and following the example to run the netwok in host bridge,
2) A publisher program in a docker container running in a machine with Linux OS sending to a windows machine running the subscriber.
3) A subscriber program in a docker container running in a machine with Linux OS while a program in the windows machine running the publisher.
In the above, i used the RTI admin console (routing service) to input the config file and run it. The config file using the rti routing example. For 2 and 3, nothing can work.
Can query why is it so?
And does it matter if the routing service is run in Linux or Windows (especially if the Linux machine is the publisher in the docker container and the Windows machine is the remote computer running the RTI routing service?) I am unable to run the RTI admin console at Linux due to some issue.
Pls advise. Thank you
Updating my findings:
Manage to get the routing service to have all status up as previously noticed that the Input is red. I saw that from the admin console that the input is shown to connect to the output of the routing service but there is no flow of data.
Thus my question is how does the docker container works with the routing service? i have run my publisher docker in bridge mode but unsure how can i know if that it really see the rti routing service? do i need to enable any port opening in the docker?
In the routing service xml, do i need to specify any QoS as the example here does not have any. https://community.rti.com/kb/how-use-rti-connext-dds-communicate-across-docker-containers-using-bridge-driver
Hi Chun Leo,
I see that you're in Singapore...someone from our Singapore team will get in touch with you as what you're asking might be more efficiently resolved with some direct communication.
In reading your inquiry, there are a few points that need to be cleared up before we can understand what you're trying to do/have done...
I assume that in the above scenario, you are not running the publisher and subscriber applications in a Docker container either?
Did you configure your Docker container configured to use bridge networking or host networking? "host bridge" is not a term and is a bit confusing...as "bridge" networking and "host" networking Docker configurations act very different.
Assuming that you mean Docker containers configured to use bridge networking, that means that applications in the Docker container can only connect to other applications on the same host, but not be able to directly connect to applications on a different host.
This is explained in the article that you referenced: https://community.rti.com/kb/how-use-rti-connext-dds-communicate-across-docker-containers-using-bridge-driver
If configured to use "host" networking, then applications in Docker containers can directly connect to other hosts as if the application was running directly outside of Docker on the host itself.
With respect to Routing Service, as the article explains, if you are using Docker containers with "bridge networking", to have them communicate with applications on other hosts, you can use RTI Routing Service to help do that.
In that scenario, RTI Routing Service is run on the host, outside of Docker, and it would connect to the app on the same host in the Docker container on one "side" of Routing Service, and Routing Service would connect to the other host on the other "side".
In your scenario, you were running a DDS app in a Docker container on one host and a DDS app in a Docker container on a different host, then you would have to run a Routing Service on one host and another instance of the Routing Service on the other host to have the data from DDS app in one host be received by the DDS app in the other host. i.e., *both* hosts would need to run an instance of RTI Routing Service (outside of Docker).
Each application in Docker would connect to their local Routing Service instance, and the 2 Routing Service instances would connect to each other.
I'm not sure what you're saying with the above statement...are you saying that you used RTI Admin Console to start Routing Service with a configuration file. AFAIK, that's not possible. Are you perhaps referring to RTI Launcher?
Typically, you would need to configure the Routing Service to support the QoS needed for the Topics that are being sent from one DDS application to the other.
Routing Service is essentially an DDS application itself, so there's a DDS connection between a user app and Routing Service....that connection needs to use the exact QoS you are/would be using between your own DDS applications.
However, to get things working, if you're not configuring QoS in your example applications, then you don't need to configure Routing Service with any special QoS either. But in real systems, you're likely going to want to configure QoS for your own applications...and thus will also want to do so for Routing Service.
Thank you for the response and detailed explanation. Have managed to get it working (for now :)).
For my Q1) Yes, publisher as in docker container and subscriber in a remote machine not running any docker. Similar to the example link.
For my Q2) Yes, you are correct on the host and bridge terminology in docker. Have been trying both of them during my experiments.
For 3) "used the RTI admin console (routing service) to input the config file and run it" , yes, you are correct. Am referring to the Routing services panel in the Launcher.
Would the running of the routing service matter whether at the publisher or subscriber side? Thank you
The Routing Service has to be running on whichever host is running the DDS application in a Docker container configured to use bridge networking...to route data from the DDS app to remote hosts. It has nothing to do with if the application is sending or receiving data...most applications used DDS both to publish and subscribe to data.
With host networking, Routing Service isn't actually needed since the DDS applications in the Docker container has direct access to the host network interfaces.