To whom it may concern,
I want to isolate the DDS communication between 2 docker containers that shared the network with the host. The reason I have to share the network with the host is that my app needs a license server that is only accessible by doing this. Is there a way to isolate the communication between the 2 docker container using something else other than changing the domain id?
Thanks in advance.
Well, given that your Docker network setup is such that the applications in the docker container share the same network and thus the same interfaces and thus use the loopback to communicate between them, then all apps using the same DDS domain ID will be exchanging discovery messages between them. There's no way to prevent an app from receiving discovery messages from apps from other docker containers other than the one that it is supposed to connect to.
So, you can run the 2 apps with a different DDS domain ID (not shared or used by other apps). Why doesn't this work for you?
Or, you can write some special code to listen in on the DomainParticipant Discovery topic, and call DDSDomainParticipant::ignore_participant() for all participants discovered except for the one that it's supposed to connect to.
Or, you can use Domain tags which essentially does the same thing without having to code anything...but this is only available since Connext 6.0.
We need to use the same binary with fixed domain id in hundreds of different docker containers. We want to avoid passing as parameters the domain-id. Do you know if there is a way to restrict the dds traffic to only one port? maybe is what is already done by default I just want to confirm.
No, with the default UDP transport plugin, DDS will use at least 3 ports, and even 4 ports if you're using multicast for user data.
Even if DDS was able to configured to use a single port, different instances of the binary would have to configure DDS to use different ports somehow. Apps can't bind to the same UDP port on the same host (which is the case if your docker containers are sharing the host network).
So, your binary has to do something different than other binaries when it's instanced. Besides passing in a parameter, reading a parameter from a file (and the file is different for each instance of the binary) or coded to read and use an environment variable...which has to be set different for each instance), I don't know what other means is available.
Again, the easiest way is to use the domain id. Domain IDs control the UDP port mapping so that different domain ids map to different UDP ports.
Even if you use the domain tag approach, you still have to set different domain tags for the groups of apps that have to talk to each other. So again, some parameter that affects how the binary initializes itself needs to be passed in or accessed.
are these 3 or 4 ports that dds uses fixed, so I can don't expose them in the docker container?
The UDP ports numbers used are calculated by an equation based on domain ID and participant id (which is automatically determined). The user's manual details are here. A easier to read discussion can be found here.
However, not sure how you think this will help... Not sure how you can control docker to "expose" or not "expose" UDP ports. And if 2 containers need to talk to each other as you indicated, then those ports will need to be "exposed". But as far as I understand, not that I'm a docker expert, when a docker container is configured to share the host network, the ports that it creates are in the "port space" of the host...as if a non-docker application on the host created those ports.