Hi,
I'm trying to restrict the participant discovery of my applications to localhost only. I use the following configuration:
<participant_qos>
<discovery>
<initial_peers>
<element>localhost</element>
</initial_peers>
</discovery>
</participant_qos>
I thought this config meant "only discover the participants present on localhost" -> Am I wrong?
The trouble I have here, is that another Participant from another computer "broadcasts" a sample on a common topic (same topic name/type, but different QoS).
My first Participant (with previous configuration) receives "incompatible topic" notifications. Do you know why my participant of 2nd computer is "visible" from the 1st one?
Is there another configuration that I missed here?
I want a config were my participant of 1st computer only "sees" local participants (from same computer) and only receives data from local. I hope I'm clear, don't hesitate if I'm not ;-)
Thank you !
Lucie
I have not tried this option yet. Another way, that works for us, would be to configure the TRANSPORT_BUILTIN QosPolicy to only use shared memory:
<participant_qos>
<transport_builtin>
<mask>SHMEM</mask>
</transport_builtin>
</participant_qos>
Hi Lucie,
That setting will make your DomainParticipant to proactively try to discover other DomainParticipants on the same machine. Nevertheless, if a DomainParticipant from a remote machine tries to discover any DomainParticipant from your machine, it will.
There's a setting which suits what you try to achieve: accept_unknown_peers set to false. With this setting, your local DomainParticipant will only match DomainParticipants from the IP addresses that you specify in initial_peers. So, if you set 'localhost' as the initial peer, you would only match DomainParticipants on your local machine. For your information, you can set this policy with this snippet:
<participant_qos> <discovery> <accept_unknown_peers>false</accept_unknown_pers> <initial_peers> <element>localhost</localhost> </initial_peers> </discovery> </participant_qos>Let me know if this helps.
-Fran
Hi !
Thank you very much for your help :-) This configuration sounds great, I try it and come back.
Lucie
Hi,
I want to run a bunch of unit tests in parallel.
Currently we use the following to prevent cross-talk between Jenkins nodes:
<participant_qos><transport_builtin>
<mask>SHMEM</mask>
</transport_builtin>
<discovery>
<initial_peers>
<element>16@builtin.shmem://</element>
</initial_peers>
<accept_unknown_peers>false</accept_unknown_peers>
</discovery>
</participant_qos>
Could you please recommend a way to take this one step further and limit DDS cominication to a single process? This will allow us to run unit tests in parallel on the same machine (e.g. ctest -j)
We have Google Test code that creates a participant and the actual code that creates participant. This is all run in the same googletest EXE. We want to run many of these in parallel to imrove CI pipeline times.
Thanks,
-Ryan
Hey Ryan,
A simple way to prevent apps from talking with each other (allowing you to run multiple apps on the same node without them interfereing with each other) is making sure that your initial_peers doesn't have shmem:// in it.
The above, when paired with SHMEM builtin transport being the only one you use - guarantees, whether you set "accept_unknown_peers" to false or not that you will not have different apps talking with each other.
You might be asking: "but wouldn't this interfere with in-app communications as well?"
If you have more than one participant per application, you are correct.
If you adhere to the best practice of using a single participant per app (per domain) this shouldn't be a problem as discovery within a participant does not require the steps used when discovering other participants.
Hopefully this is helpful,
Roy.