How do I make sure I am using fastdds intra for communication?

[zonghai-yang]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

Is there an api that returns the intra communication type?

Current behavior

Within a process, I use a participant to create a reader and writer. They communicate with each other. How can I determine that they are using intra to communicate? Two participants with identical 8 first bytes on the GuidPrefix_t are considered to be running in the same process, and therefore intra-process delivery is used. but i only have one participant and i had make the xml to this <library_settings> <intraprocess_delivery>FULL</intraprocess_delivery> </library_settings>

when<library_settings> <intraprocess_delivery>OFF</intraprocess_delivery> </library_settings> Within a process, the reader and writer created by a participant, when intraprocess_delivery is OFF, the first eight digits of the guid are also the same.

Steps to reproduce

1.use a participant to create a reader and writer
2.intraprocess_delivery is OFF

Fast DDS version/commit

How do I make sure I am using fastdds intra for communication?

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

Intra-process

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[JesusPoderoso]

Hi @zonghai-yang, thanks for using Fast DDS.
I am afraid there is no straightforward mechanism to detect if intra-process delivery is being used or not.
There is the option to detect it by counter-example proof: checking that the other available delivery mechanisms are NOT being used.
Default buitin transports contain SHM and UDP transports. Also note that data-sharing delivery mechanism can be used, which uses SHM segments for communication.
The aim of this proof is to check that the communication is not performed in any of those mechanisms, so intra-process delivery is used (by sharing payload pools between endpoints in stack).
This check can be easily done by following these steps:

1. Run wireshark with RTPS filter to ensure that your DDS deployment communication is not established over UDP transport.
2. Run fastdds shm clean on a terminal to clean any possible opened SHM segments (or sudo rm -rf /dev/shm/*).
3. Periodically check the SHM segments directory to ensure no segments are created during your DDS deployment (ls /dev/shm/).
4. Deploy your DDS intra-process delivery mechanism application.
5. Make sure that no SHM segments are created, and no UDP traffic is detected.

Hope it helps.

[JesusPoderoso]

I am moving this ticket to the corresponding forum as per Fast DDS CONTRIBUTING guidelines.