Overview & Summary

Participant discovery in RTI Connext Professional allows DomainParticipant entities to discover each other automatically across a network. The legacy Simple Participant Discovery Protocol (SPDP) periodically broadcasts full participant declarations via DATA(p) messages (~800 bytes) for both initial bootstrapping and ongoing liveliness assertion.

The Simple Participant Discovery Protocol 2.0 (SPDP2) introduces a modular discovery model. Instead of repeating large, full participant announcements, SPDP2 decouples discovery into distinct message flows:

• Bootstrapping (DATA(Pb)): Minimal initial participant announcement (~212–240 bytes) used solely to initiate contact.

• Configuration Exchange (DATA(Pc)): Point-to-point reliable exchange (~729–764 bytes) containing complete participant attributes and QoS policies.

• Liveliness Assertions (DATA(m)): Lightweight periodic pulse messages (~50 bytes) to maintain participant state during steady-state operations.

Note: The message sizes shown above correspond to participant configuration using the default quality of service (QoS) settings and disabling observability (one single UDPv4 interface enabled, multicast configuration, and no Security Plugins). Message sizes are highly influenced by system QoS and application configuration, and may vary in other scenarios.

This protocol significantly reduces steady-state bandwidth consumption and improves network reliability, though it introduces a two-phase handshake during initial discovery that can delay discovery

See Simple Participant Discovery and Simple Participant Discovery Protocol 2.0 in the Users Manual for more details about the two protocols.

Summary Performance Comparison

The following data was gathered from testing the discovery phase over SPDP and SPDP2 for 10, 30, 60, 90, 150, and 210 participants, one single topic and ten endpoints per participant (meaning 2100 endpoints in total in the system for the 210 participants-test). 

The QoS configuration was set to the default one but with Observability Framework disabled (monitoring.enable in the participant_factory_qos QoS policy set to false). Only one UDPv4 interface was set and no Security Plugin was enabled.

Other application configurations may vary the results shown below. Find the complete set of results in the Discovery Performance.

Performance Analysis & Metrics

Discovery Time

• SPDP and SPDP2 exhibit similar maximum discovery completion times. The maximum observed discovery time across test scales (up to 210 participants) is approximately 10 seconds (using a low-jitter configuration in the performance machines that significantly reduces the throughput in the results in exchange for reducing variability in the results), with no differences greater than 2 seconds observed in the discovery time between SPDP and SPDP2. Because discovery test variance is naturally within 1 to 2 seconds, this baseline delta is not considered statistically significant.

• QoS optimizations improve the maximum discovery time reported in SPDP2.

Discovery Bytes Sent

• Multicast Environments: SPDP2 generates 65% more transmitted bytes in default multicast configurations. This overhead stems from SPDP2's reliable unicast repair packets sent during the configuration handshake. However, adjusting the configuration channel QoS (e.g., enabling multicast repairs via a non-zero NACK response delay) reduces this overhead to approximately 40%. SPDP is the better option if you need fewer bytes sent.

• Unicast Environments: SPDP2 is substantially more bandwidth-efficient, transmitting 25% fewer bytes than SPDP. SPDP2 transmits compact DATA(Pb) messages initially and stops sending them once discovery completes, whereas SPDP repeatedly unicasts heavy DATA(p) messages to every configured peer address. After enabling bandwidth optimizations (disabling properties propagation) during discovery, SPDP2 yields an approximate 2% reduction.

Discovery Bytes Received

• Multicast Environments: SPDP incurs approximately 17% higher received byte counts than SPDP2. In SPDP, all participants receive full DATA(p) announcements from every broadcasting participant via multicast. When configured with bandwidth optimization enabled, SPDP2 consumes roughly 8% more received bytes than SPDP.

• Unicast Environments: SPDP receives 20% more bytes than SPDP2. When utilizing a bandwidth-saving configuration, SPDP receives only 3% more bytes.

CPU Utilization

• Multicast Environments: SPDP2 requires 10% to 15% more CPU processing time during active discovery. In absolute terms, this represents a minimal processing overhead (approximately 0.062 seconds of additional CPU time for a 210-participant deployment).

• Unicast Environments: CPU overhead differences are negligible in the default configuration, with SPDP2 consuming roughly 5% more CPU time than SPDP during peak discovery. Through QoS optimizations, SPDP2 raises CPU usage by as much as 14% more than in SPDP.

Steady State

Steady-State Bandwidth Reduction: Because liveliness assertion messages (DATA(m)) in SPDP2 are significantly smaller than the full participant announcements (DATA(p)) repeated by SPDP, SPDP2 achieves substantial bandwidth savings once discovery completes. In tests measuring network traffic over a 5-minute steady-state window following initial discovery (evaluated with 10 participants, a single topic), SPDP2 achieved a bandwidth reduction of approximately 59% in multicast environments and over 78% in unicast environments compared to SPDP. When bandwidth reduction optimizations are enabled during discovery, total network traffic recorded over 5 minutes is 8% lower for SPDP2 in multicast, whereas SPDP2 achieves approximately a 47% decrease in unicast mode.

Note: Consistency Across Application Configurations: These performance metrics demonstrate general consistency across varied application profiles. Performance remains stable when integrating security extensions (such as Lightweight Security or Domain Protection), scaling the number of user endpoints per participant, or writing user data on the DataWriters included in the test.

Protocol Recommendations & Decision Matrix

To select the ideal participant discovery protocol, evaluate your system context against the following architectural criteria:

• Vendor Interoperability: Use SPDP. SPDP2 is currently an RTI-specific protocol. Standard OMG DDS interoperability across multi-vendor deployments requires SPDP. 

• Backwards Compatibility: Use SPDP. SPDP2 is not backwards-compatible with older versions of RTI Connext DDS that do not support SPDP2.

• IP Fragmentation & Small MTU Networks: Use SPDP2 if no optimizations are permitted. In constrained networks (such as WAN or Cloud environments with MTUs less or equal to 1200 bytes), full SPDP DATA(p) packets often fragment when participant property lists or executable file paths are large. SPDP2 isolates participant metadata into separate DATA(Pb) and DATA(Pc) messages, preventing IP fragmentation. This phenomenon can be avoided in SPDP if discovery optimizations are used.

• Steady-State Bandwidth Optimization: Use SPDP2. Systems operating over bandwidth-sensitive links benefit significantly from SPDP2. Once initial discovery completes, SPDP2 replaces periodic ~800-byte DATA(p) messages with lightweight ~50-byte DATA(m) liveliness assertions.

• Lossy Networks & Dynamic Configurations: Use SPDP2. Dynamic changes (such as IP mobility updates or partition changes) sent over SPDP can be lost on lossy links and are not recovered until the next periodic announcement (30 seconds by default). SPDP2 transmits configuration updates over a reliable channel, allowing missing updates to be repaired immediately.

• Networks with no multicast support: Use SPDP2. When multicast is disabled or unsupported in the network topology, SPDP2 provides superior performance across discovery completion time, transmitted bandwidth, and received network traffic.