RTI Connext Professional: Configure Unicast-Only Communication

Submitted by BrianRTI on Wed, 06/17/2026 - 09:40

Summary

This article explains how to configure RTI Connext Professional so DomainParticipants discover each other using UDPv4-unicast or SHMEM only.

Target outcome:

  • No discovery multicast (discovery multicast receive disabled)
  • Explicit unicast peers for discovery
  • Optional hard disable of UDP multicast at transport level
  • SHMEM or UDPv4-unicast for all communication

Original Questions

  1. How do I completely disable multicast for discovery so participants only discover each other via unicast peers?
  2. What QoS settings (in XML and via API) are required, including DISCOVERY_QOS and TRANSPORT_BUILTIN QoS settings?
  3. Does the initial_peers list support specifying a port?
  4. What is a minimal XML example for a participant that does discovery and user data over UDPv4 unicast only or SHMEM?

Problem

By default, Connext is configured to use multicast for discovery. In controlled or multicast-restricted networks, you may need to use unicast-only discovery and user data transports.

Solution Overview

Use these four settings together:

  1. Clear the discovery multicast receive address.
  2. Define explicit unicast initial peers. The default initial peers list contains a multicast address. By defining unicast initial peers we are achieving our goal by also removing the multicast address from the list.
  3. Set the default domain announcement period to infinite.
  4. Set UDPv4 transport multicast_enabled to false (recommended for strict no-multicast environments).

Note: Since all user data in Connext is unicast by default, you must only change discovery configuration to fully disable multicast communication.

Example XML QoS Profile

<?xml version="1.0" encoding="UTF-8"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="https://community.rti.com/schema/7.7.0/rti_dds_profiles.xsd"
version="7.7.0">
<qos_library name="MyQosLibrary">
    <qos_profile name="Udpv4UnicastOnly" is_default_qos="true">
        <domain_participant_qos>
            <transport_builtin>
                <udpv4>
                    <!-- Disable UDPv4 multicast at transport level -->
                    <multicast_enabled>false</multicast_enabled>
                </udpv4>
            </transport_builtin>
            <discovery>
                <!-- Disable multicast discovery reception -->
                <multicast_receive_addresses/>
                <!-- Explicitly define unicast peers, including participant ID limit -->
                <initial_peers>
                    <element>10@builtin.udpv4://192.168.1.10</element>
                    <element>10@builtin.shmem://</element>
                </initial_peers>
            </discovery>
            <discovery_config>
                <default_domain_announcement_period>
                    <sec>DURATION_INFINITE_SEC</sec>
                    <nanosec>DURATION_INFINITE_NSEC</nanosec>
                </default_domain_announcement_period>
            </discovery_config>
        </domain_participant_qos>
    </qos_profile>
</qos_library>
</dds>

Configuration Explanation

  • transport_builtin.udpv4.multicast_enabled = false: Disables UDPv4 multicast capability in transport plugin.
  • discovery.multicast_receive_addresses = empty: Stops listening for discovery multicast and does not announce any multicast locators during discovery.
  • discovery.initial_peers = unicast peers: Defines where discovery messages are sent.
  • discovery_config.default_domain_announcement_period = infinite: Suppress output of discovery message for RTI utilities such as RTI Admin Console, RTI Spy, etc.

Configuring Initial Peers

You can configure the initial_peers list a number of ways with the following precedence (highest to lowest):

  1. API
  2. QoS XML
  3. NDDS_DISCOVERY_PEERS file
  4. NDDS_DISCOVERY_PEERS environment variable
  5. Built-in defaults

Example:

export NDDS_DISCOVERY_PEERS="10@builtin.udpv4://192.168.1.10,10@builtin.shmem://"

Important:

  • Explicitly setting this variable replaces defaults; it is not concatenated with other initial_peers configurations.
  • For unicast-only behavior, do not include multicast peer descriptors.

Do initial_peers Entries Support Custom Ports?

IP ports are derived from the RTPS well-known port mapping (a function of domain ID and participant ID). The initial_peers is a configuration of the remote participant ID range, transport, and remote host. If you would like to learn more about how Connext maps the participant's domain ID and participant ID to an IP port under the hood, this is a great article.

Important Participant ID Range Note

You must configure initial_peers announce to a specified participant IDs (the implicit default is participant IDs 0-4). Please see this documentation on specifying the peer descriptor format.

Examples:

<!-- This sends discovery messages to participant IDs 0 through 10 on the remote host via UDPv4. -->
<element>10@builtin.udpv4://192.168.1.10</element>

<!-- This sends discovery messages to participant IDs 0 through 10 on the local host via SHMEM. -->
<element>10@builtin.shmem://</element>

Validation Checklist

After deployment, verify:

  • No multicast receive configured for discovery.
  • Initial peers list contains only intended unicast addresses.
  • Network capture shows UDP and SHMEM unicast discovery/user traffic only.

Troubleshooting

  • Discovery not finding all processes on a host:
    • Increase participant-ID probe range with n@transport://host, where n is the participant ID range specified for discovery.
  • Slow discovery in lossy networks:
    • Tune participant announcement-related discovery parameters.
  • Unexpected multicast traffic:
    • Recheck multicast_receive_addresses is empty and transport_builtin.udpv4.multicast_enabled=false is applied from the active profile.
Product:
Keywords: