Environment:

• ROS2 Dashing Patch 2
• Windows 10
• RTI Connext DDS
• No customizations of DDS layer through USERQOSPROFILE.xml or other options

Reproduction:

• Start some ROS2 nodes
• Start RTI Admin console

• Observe the warnings on the ROS2 terminals of any started nodes:

  can't reach: locator: shmem://0000:0000:0405:0000:0000:0000:0000:0000:7416 COMMENDSrWriterService_assertRemoteReader:Discovered remote reader with GUID 0XC0A85025,0X81EC,0X1,0X20087 using a non-addressable locator. This can occur if the transport is not installed and/or enabled in the local participant. See https://community.rti.com/kb/what-does-cant-reach-locator-error-message-mean for additional info.

Observation: Looking at the code of node.cpp:

  // forces local traffic to be sent over loopback,
  // even if a more efficient transport (such as shared memory) is installed
  // (in which case traffic will be sent over both transports)
  status = DDS::PropertyQosPolicyHelper::add_property(
    participant_qos.property,
    "dds.transport.UDPv4.builtin.ignore_loopback_interface",
    "0",
    DDS::BOOLEAN_FALSE);
  if (status != DDS::RETCODE_OK) {
    RMW_SET_ERROR_MSG("failed to add qos property");
    return NULL;
  }
  status = DDS::PropertyQosPolicyHelper::add_property(
    participant_qos.property,
    "dds.transport.use_510_compatible_locator_kinds",
    "1",
    DDS::BOOLEAN_FALSE);
  if (status != DDS::RETCODE_OK) {
    RMW_SET_ERROR_MSG("failed to add qos property");
    return NULL;
  }

It seems that the ROS2 codebase is intentionally disabling shmem according to the comment. In Admin console, I observe that the ROS2 participants are not considering shmem as an available defaultunicastlocator.

Side node: I'm able to relate the code above directly to the disabling of shmem, I only observe the comment and the bevahior...

Questions:

• Can this behavior be overruled by the indivudual node developer? As far as I see, currently the node developer does not have that possibility since the creation of the node itself sets the QoS preference and uses it for Participant creation after which this cannot be modified anymore.
• If this setting is intentionally applied for backwards compatibility (e.g. ref https://community.rti.com/kb/what-causes-error-discovered-remote-participant), shouldn't that old compatibility setting be considered as the exception instead of the rule?