22.2 (Experimental) Simple Participant Discovery 2.0

The Simple Participant Discovery Protocol 2.0 (SPDP2) is an experimental alternative to the original Simple Participant Discovery Protocol, described in 22.1 Simple Participant Discovery. SPDP2 is designed to decrease bandwidth usage and improve the reliability of the participant discovery and update process.

Participant discovery can be broken down into three separate phases: bootstrapping, exchanging configuration, and maintaining liveliness:

  • During bootstrapping, a participant sends out periodic messages to its initial peers list in order to discover other matching participants in the system.
  • During configuration exchange, a participant makes sure that discovered participants have the most up-to-date information about itself.
  • To maintain liveliness, a participant sends out periodic messages to other participants so that they know it is still alive and active.

In SPDP, all of these phases of discovery use the same participant message and send it over a periodic, best-effort channel. This approach is simple and straightforward, but it has a number of drawbacks. The first is that not all phases require the same information to be sent. During bootstrapping, only the information that is needed to determine whether two participants should match needs to be sent (like the domain ID, participant partition, and security configuration). During configuration, any additional information that needs to be communicated to remote participants needs to be sent. And to maintain liveliness, only enough information to identify the participant that is asserting itself needs to be sent. Instead, during all of these phases, all information about a participant is sent, wasting bandwidth with unnecessarily duplicated information.

The second drawback to using the same message sent over the same channel is the lack of flexibility over how often these messages are sent. Messages sent for bootstrapping need to be sent periodically, as frequently as is desired to discover new participants in a system. Configuration messages need to be sent reliably, once upon first communication and then again whenever the participant’s configuration changes. SPDP relies on the periodic nature of the messages to repair any losses. So if a configuration update is lost, it is not resent until the next period—which can delay important updates like partition changes or IP mobility events. Finally, liveliness messages need to be sent periodically at a rate that meets the system requirements for detecting when a participant has been lost, which may be a different period than what is required for the other two phases. Instead, SPDP has a single period, participant_liveliness_assert_period in the 44.3 DISCOVERY_CONFIG QosPolicy (DDS Extension), which configures how often the full participant message is sent.

SPDP2 is designed to address the drawbacks to SPDP by splitting the single message that is sent in SPDP into three different messages—bootstrap messages, configuration messages, and liveliness messages—and by allowing each of these messages to be sent at separately configured periods with different reliability settings.

Bootstrap Messages

When a participant is first enabled, it sends out DiscoveryConfigQosPolicy::initial_participant_announcements number of bootstrap messages (see 44.3 DISCOVERY_CONFIG QosPolicy (DDS Extension)), at a random period between DiscoveryConfigQosPolicy::min_initial_announcement_period and DiscoveryConfigQosPolicy::max_initial_announcement_period to all of the locators on its DiscoveryQosPolicy::initial_peers list (see 44.2 DISCOVERY QosPolicy (DDS Extension)). After the initial set of announcements are sent, they are resent to the DiscoveryQosPolicy::initial_peers list at the DiscoveryConfigQosPolicy::participant_announcement_period in order to match with new participants that may have joined the system. Once a participant receives one of these announcements from a participant that it has not discovered yet, it will respond with DiscoveryConfigQosPolicy::new_remote_participant_announcements number of bootstrap messages, also spaced out at a random interval between DiscoveryConfigQosPolicy::min_initial_announcement_period and DiscoveryConfigQosPolicy::max_initial_announcement_period.

Configuration Messages

When two participants have received each other’s bootstrap messages, they will exchange the rest of their configuration over a reliable channel using another message, the configuration message. In addition to the rest of the configuration that has not been exchanged yet between the two participants, the configuration message also contains fields from the bootstrap message that may change over time, like the participant partition and metatraffic locators. When either participant changes its configuration, this information is sent over this reliable channel.

Liveliness Messages

Two participants that have completed discovery with each other will exchange periodic bootstrap messages and liveliness messages. In upcoming releases of the protocol, the periodic bootstrap message traffic will be eliminated between two participants that have already discovered each other, and the only ongoing traffic between two participants will be small liveliness messages sent at the DiscoveryConfigQosPolicy::participant_liveliness_assert_period (see 44.3 DISCOVERY_CONFIG QosPolicy (DDS Extension)).

Currently, there is no way to create a participant that can communicate with participants that are using SPDP at the same time as other participants that are using SPDP2. In upcoming releases, a compatibility mode will be introduced to allow this backwards compatibility.

Figure 22.1: SPDP2: Summary

In Figure 22.1: SPDP2: Summary, the Participant on Node A sends a bootstrap message to Node B, which is in Node A’s peer list. The Participant on Node B sends two bootstrap messages (new_remote_participant_announcements) to Node A in response, as well as a configuration message. When the Participant on Node A receives both of these messages and completes compatibility checks, it will consider Participant B as a “matched” participant and begin maintaining liveliness with Participant B. When Participant B receives the configuration message from Participant A, it will also begin maintaining liveliness with Participant A.

Both Participant A and Participant B will continue to send bootstrap messages to their peer list at the rate of their respective participant_announcement_period (though only Participant A’s are illustrated in the diagram for clarity).

Both Participant A and Participant B will send liveliness messages to each other at the rate of their respective participant_liveliness_assert_period (though only Participant B’s are illustrated in the diagram for clarity).

Figure 22.2: SPDP2: Ungraceful Termination before Configuration Exchange Completes

In Figure 22.2: SPDP2: Ungraceful Termination before Configuration Exchange Completes, Participant A is removed from Participant B’s database if Participant A does not send a configuration message within its participant_liveliness_lease_duration after it is first discovered by Participant B.

Figure 22.3: SPDP2: Ungraceful Termination after Configuration Exchange Completes

In Figure 22.3: SPDP2: Ungraceful Termination after Configuration Exchange Completes, Participant A is removed from Participant B’s database if it does not send a liveliness message within its participant_liveliness_lease_duration.

22.2.1 Bootstrap Message Fields

The following fields are sent as part of the periodic, best-effort bootstrap message:

  • Also sent in the configuration message:
    • DomainParticipant’s GUID
    • Metatraffic unicast locators
    • Metatraffic multicast locators
    • Participant partition
    • Vendor builtin endpoint mask
  • Domain ID
  • Domain tag
  • Product version
  • Participant liveliness lease duration
  • Transport info
  • 47.23 SERVICE QosPolicy (DDS Extension)
  • Security info
  • Security tokens
  • Security signature algorithms
  • Security key establishment algorithms
  • Security participant symmetric cipher algorithms

22.2.2 Configuration Message Fields

The following fields are sent as part of the reliable configuration message:

  • Also sent in the bootstrap message:
    • DomainParticipant’s GUID
    • Metatraffic unicast locators
    • Metatraffic multicast locators
    • Participant partition
    • Vendor builtin endpoint mask

22.2.3 Unsupported Features with SPDP2

The following features are known to not work when using the SPDP2 protocol:

  • RTI Cloud Discovery Service
  • Custom security plugins. Only the RTI Security Plugins are supported in combination with SPDP2.

22.2.4 Planned Improvements to SPDP2

The SPDP2 protocol is still under development with a number of improvements planned for upcoming releases. These include:

  • A compatibility mode. The compatibility mode will allow some participants to act as bridges between participants that are using SPDP and SPDP2. Participants that are using the compatibility mode will be able to communicate with participants that are using SPDP and other participants that are using SPDP2. Participants that are using SPDP cannot communicate directly with participants that are using SPDP2.
  • Reduced bootstrap traffic after matching with a participant. When a participant matches with another participant that is located at one of its initial peers locators, it will stop sending periodic bootstrap messages to the matched participant. Any configuration updates will be sent over the reliable configuration channel so there is no need for the continued periodic bootstrap messages to go to matched participants.
  • Improved configuration update behavior. Currently, when a participant changes its configuration (partition, locators, etc.), it sends out:
    • If SPDP is enabled: a single Data(p) to all peers (matched or potential)
    • If SPDP2 is enabled: a single reliable message to matched peers, a single bootstrap message to unmatched initial peers

    RTI will add an option to send multiple Data(p)s/bootstrap messages, since these messages are sent best-effort and can get lost, delaying configuration change updates in remote participants until the next periodic message. RTI will also ensure that when a configuration change causes two participants to no longer match (i.e., a partition change), the participant that changed its partition waits for the remote participants to acknowledge reception of this change.