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 (SPDP), 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 (ParticipantBootstrapBuiltinTopicData), configuration messages (ParticipantConfigBuiltinTopicData), and liveliness messages—and by allowing each of these messages to be sent at separately configured periods with different reliability settings.

Out of the box, SPDP and SPDP2 participants cannot communicate with each other. For information on using RTI Routing Service to achieve this communication, see this Knowledge Base article on the RTI Community Forum.

Since SPDP and SPDP2 participants do not communicate with each other directly, currently, Connext Tools do not automatically see SPDP and SPDP2 participants at the same time, although you can see one or the other. For example, RTI DDS Spy and RTI DDS Ping, which use SPDP by default, do not by default interact with participants using SPDP2; however, you can use the -qosProfile option to load a QoS profile that enables SPDP2, so that DDS Spy and DDS Ping will interact with SPDP2 participants (but not SPDP ones).

See 22.2.4 Features under Consideration for SPDP2 for more information on future directions for SPDP2.

Bootstrap Messages (ParticipantBootstrapBuiltinTopicData)

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)).

A participant will stop sending bootstrap messages to a unicast address in the DiscoveryQosPolicy::initial_peers if it fully discovers a remote participant using that unicast address (both the address and port must match). "Fully discovered" in this scenario means that the participants have compatible discovery information (domain ID, partition, security information, etc.), and the participant has received a configuration message from the remote participant.

After the initial set of announcements are sent, bootstrap messages are resent to the DiscoveryQosPolicy::initial_peers list (minus any unicast addresses with fully discovered remote participants) 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 (ParticipantConfigBuiltinTopicData)

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. This message contains the rest of the configuration that has not yet been exchanged between the two participants, as well as any 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 minimum between the DiscoveryConfigQosPolicy::participant_liveliness_assert_period (see 44.3 DISCOVERY_CONFIG QosPolicy (DDS Extension)) and the LivelinessQosPolicy::lease_duration / LivelinessQosPolicy::assertions_per_lease_duration (see 47.15 LIVELINESS QosPolicy) of any DataWriters that have been configured to use DDS_AUTOMATIC_LIVELINESS. Participant discovery with SPDP2 utilizes the same mechanism that DataWriters can use for automatically maintaining DataWriter liveliness, so the assertion period used will be the fastest period required between the DomainParticipant and all DataWriters. As DataWriters are added to and removed from the participant, this period will be updated to reflect the current minimum assertion period of all active writers.

Figure 22.1: SPDP2: Summary

In Figure 22.1: SPDP2: Summary, the participant on Node A (Participant A) sends a bootstrap message to Address B and to an additional address (Address C) that is in Participant A’s peers list. The participant on Node B (Participant B) sends two bootstrap messages (new_remote_participant_announcements) to Participant A in response, as well as a configuration message. When Participant A receives both of these messages and completes compatibility checks, it will consider Participant B as a "matched" participant and will begin maintaining liveliness with Participant B. Participant A will then stop sending bootstrap messages to Address B. When Participant B receives the configuration from Participant A, it will also begin maintaining liveliness with Participant A and stop sending bootstrap messages to Address A.

At Participant A’s participant_announcement_period, Participant A will only send a bootstrap message to Address C. It will not send a bootstrap message to Address B, since it has already fully discovered Participant B.

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).

When Participant A makes a change to its 47.30 USER_DATA QosPolicy, it sends a bootstrap message to Address C and a configuration message to Participant B with the updated configuration information.

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.

Figure 22.4: SPDP2: Bootstrap Messages after Participant Removal

In Figure 22.4: SPDP2: Bootstrap Messages after Participant Removal, Participant A and Participant B discover each other. At Participant A’s participant_announcement_period, Participant A does not send any bootstrap messages to Participant B. After a bit of time, Participant B is destroyed and sends a DISPOSE message on the participant configuration DataWriter to Participant A. Participant A removes Participant B from its database. At Participant A’s next participant_announcement_period, Participant A sends a bootstrap message to Node B again.

22.2.1 ParticipantBootstrapBuiltinTopicData

The periodic, best-effort bootstrap messages contain the subset of the DDS_ParticipantBuiltinTopicData that is required to determine if two DomainParticipants will match. The complete list of fields sent in a bootstrap message are in Table 22.1 Participant Bootstrap Built-in Topic’s Data Type (DDS_ParticipantBootstrapBuiltinTopicData). The first set of rows are also part of the ParticipantConfigBuiltinTopicData.

Table 22.1 Participant Bootstrap Built-in Topic’s Data Type (DDS_ParticipantBootstrapBuiltinTopicData)

Type

Field

Description

These fields are part of both the ParticipantConfigBuiltinTopicData and ParticipantBootstrapBuiltinTopicData

struct DDS_GUID_t

guid

GUID of the DomainParticipant

struct DDS_LocatorSeq

metatraffic_unicast_locators

Unicast locators of the DomainParticipant that are used for discovery

struct DDS_LocatorSeq

metatraffic_multicast_locators

Multicast locators of the DomainParticipant that are used for discovery

struct DDS_PartitionQosPolicy

partition

Partition of the DomainParticipant. See 44.6 PARTITION QosPolicy.

DDS_UnsignedLong

vendor_builtin_endpoints

Mask of the builtin vendor-specific endpoints used by the DomainParticipant

These fields are part of the ParticipantBootstrapBuiltinTopicData only

DDS_DomainId_t

domain_id

Domain ID of the DomainParticipant. See 16.3.4 Choosing a Domain ID and Creating Multiple DDS Domains.

struct DDS_PropertyQosPolicy

domain_tag

Domain tag of the DomainParticipant. This field is sent as part of the struct DDS_PropertyQosPolicy. This field is the only DDS_PropertyQosPolicy property that is populated in the bootstrap message. See 16.3.5.1 Choosing a Domain Tag.

struct DDS_ProductVersion_t

product_version

Vendor-specific parameter. The current version of Connext.

struct DDS_Duration_t

lease_duration

participant_liveliness_lease_duration of the DomainParticipant

struct DDS_TransportInfoSeq

transport_info

Sequence containing information about the installed transports of the DomainParticipant

struct DDS_ServiceQosPolicy

service

Service associated with the DomainParticipant. See 47.23 SERVICE QosPolicy (DDS Extension).

DDS_ParticipantTrustProtectionInfo

trust_protection_info

Trust Plugins information associated with the discovered DomainParticipant. Trust Plugins is a generic abstraction that represents any plugin intended to do transformation, interception, and validation of exchanged DomainParticipant data and metadata.

trust_protection_info contains information about how RTPS wire serialization, discovery, and liveliness interact with the loaded Trust Plugins.

The meaning of the contents of this field may vary depending on what Trust Plugins the DomainParticipant is using. For information about how this field interacts with the RTI Security Plugins, see the RTI Security Plugins User's Manual.

DDS_ParticipantTrustAlgorithmInfo

trust_algorithm_info

Trust Plugins algorithms associated with the discovered DomainParticipant.

Trust Plugins is a generic abstraction that represents any plugin intended to do transformation, interception, and validation of exchanged DomainParticipant data and metadata. trust_algorithms contains information about what algorithms the loaded Trust Plugins are running. Two DomainParticipants will not match if their trust_algorithm_info are incompatible.

The meaning of the contents of this field may vary depending on what Trust Plugins the DomainParticipant is using. For information about how this field interacts with the RTI Security Plugins, see the RTI Security Plugins User's Manual.

22.2.2 ParticipantConfigBuiltinTopicData

The reliable configuration messages contain the remaining information about the DomainParticipant that was not sent in the bootstrap message, as well as any information that is mutable and may need to be updated. The complete list of fields sent in a configuration message are in Table 22.1 Participant Bootstrap Built-in Topic’s Data Type (DDS_ParticipantBootstrapBuiltinTopicData). The first set of rows are also part of the ParticipantBootstrapBuiltinTopicData.

Table 22.2 Participant Configuration Built-in Topic’s Data Type (DDS_ParticipantConfigBuiltinTopicData)

Type

Field

Description

These fields are part of both the ParticipantConfigBuiltinTopicData and ParticipantBootstrapBuiltinTopicData

struct DDS_GUID_t

guid

GUID of the DomainParticipant

struct DDS_LocatorSeq

metatraffic_unicast_locators

Unicast locators of the DomainParticipant that are used for discovery

struct DDS_LocatorSeq

metatraffic_multicast_locators

Multicast locators of the DomainParticipant that are used for discovery

struct DDS_PartitionQosPolicy

partition

Partition of the DomainParticipant. See 44.6 PARTITION QosPolicy.

DDS_UnsignedLong

vendor_builtin_endpoints

Mask of the builtin vendor-specific endpoints used by the DomainParticipant

These fields are part of the ParticipantConfigBuiltinTopicData only

DDS_EntityNameQosPolicy

participant_name

name and role_name of the DomainParticipant. See 47.11 ENTITY_NAME QosPolicy (DDS Extension).

struct DDS_PropertyQosPolicy

property

The full list of pairs of names/values that are stored with the DomainParticipant. This list does not include the domain_tag, which is immutable and was sent in the bootstrap message. See 47.19 PROPERTY QosPolicy (DDS Extension) .

DDS_LocatorSeq

default_unicast_locators

Default unicast locators that are used for user data. If the 47.28 TRANSPORT_UNICAST QosPolicy (DDS Extension) is not specified when a DataWriter/DataReader is created, these will be used to send user traffic.

DDS_LocatorSeq

default_multicast_locators

Default multicast locators that are used for user data. If the 47.28 TRANSPORT_UNICAST QosPolicy (DDS Extension) is not specified when a DataWriter/DataReader is created, these will be used to send user traffic.

DDS_UnsignedLong

builtin_endpoint_mask

Bitmap of the builtin endpoints used by the DomainParticipant. This does not include vendor-specific endpoints, since those are part of the vendor_builtin_endpoint_mask.

DDS_UnsignedLong

builtin_endpoint_qos_mask

Bitmap of QoS settings used by the builtin endpoints

struct DDS_Duration_t

reachability_lease_duration

locator_reachability_lease_duration of the DomainParticipant

DDS_UserDataQosPolicy

user_data

user_data of the DomainParticipant. See 47.30 USER_DATA QosPolicy.

22.2.3 Interaction with DDS_ParticipantBuiltinTopicData

A DomainParticipant using SPDP2 does not have a public builtin DataReader for either the ParticipantBootstrapBuiltinTopicData or the ParticipantConfigBuiltinTopicData. A call to lookup_datareader() on the builtin Subscriber for these types will not return references to the internal DataReaders used by Connext. Instead, a DomainParticipant will combine the information that it receives in the bootstrap message and the configuration message into a single DDS_ParticipantBuiltinTopicData that contains the populated fields from both messages. This sample is provided to the Participant Builtin Topic’s builtin DataReader after the DomainParticipant receives the configuration message of the remote DomainParticipant so that the sample provided to the user is complete.

If you also need to receive a sample on the Participant Builtin Topic’s builtin DataReader when the DomainParticipant receives a bootstrap message, set ignore_default_domain_announcements in the 44.3 DISCOVERY_CONFIG QosPolicy (DDS Extension) to FALSE. A sample will then be provided to the user builtin DataReader both when the DomainParticipant receives a bootstrap message and when the DomainParticipant receives a configuration message. See Table 28.1 Participant Built-in Topic’s Data Type (DDS_ParticipantBuiltinTopicData) for a description of which fields of the DDS_ParticipantBuiltinTopicData are valid when receiving a bootstrap message.

22.2.4 Features under Consideration for SPDP2

SPDP2 is actively in development. RTI does not guarantee the following features for any release or timeline. If any of these enhancements is of interest to you, please provide that feedback through your account team.

The following features, which are not currently supported, are being considered for SPDP2 in future releases:

  • Use of SPDP2 with RTI Cloud Discovery Service.
  • Use of SPDP2 with custom security plugins. Only the RTI Security Plugins are supported in combination with SPDP2.
  • SPDP and SPDP2 compatibility mode. The compatibility mode will allow some participants to simultaneously communicate with 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. For now, you can use RTI Routing Service to achieve this communication; see this Knowledge Base article on the RTI Community Forum.
  • 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.