Simple Participant Discovery 2.0

25.2 Simple Participant Discovery 2.0

The Simple Participant Discovery Protocol 2.0 (SPDP2) is an alternative to the original Simple Participant Discovery Protocol (SPDP), described in 25.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 56.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 Known Issues with Discovery in the RTI Connext Core Libraries Release Notes for more information on future directions for SPDP2 and other known issues.

Bootstrap Messages (ParticipantBootstrapBuiltinTopicData)

When a participant is first enabled, it sends out DiscoveryConfigQosPolicy::initial_participant_announcements number of bootstrap messages (see 56.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 56.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 remote participant that it has not discovered yet, it will respond with a maximum of 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. The participant will stop sending these bootstrap messages to the remote participant's unicast locators and multicast locators that are not in the initial_peers list once it receives the configuration message from the remote participant. Receiving the configuration message indicates that the remote participant has received a bootstrap message from the participant and no longer needs to complete bootstrapping. Therefore, not all of DiscoveryConfigQosPolicy::new_remote_participant_announcements bootstrap messages will necessarily be sent to the remote participant; however, they will all be sent to the remote participant's multicast locators that are also in the initial_peers list.

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.

If a participant sends a configuration change that results in unmatching with a remote participant (for example, a partition change going from matching to unmatching), the local participant will wait until the remote participant acknowledges that it has received the configuration change before fully removing the remote participant. This allows the local participant to resend this configuration change if the sample is lost, ensuring true reliability. The local participant will remove the remote participant after the remote participant's participant_liveliness_lease_duration (in the 56.3 DISCOVERY_CONFIG QosPolicy (DDS Extension)) has passed, even if the local participant has not received an acknowledgment of the configuration change from the remote participant.

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 56.3 DISCOVERY_CONFIG QosPolicy (DDS Extension)) and the LivelinessQosPolicy::lease_duration / LivelinessQosPolicy::assertions_per_lease_duration (see 59.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 25.1: SPDP2: Summary

In Figure 25.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 59.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 25.2: SPDP2: Ungraceful Termination before Configuration Exchange Completes

In Figure 25.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 25.3: SPDP2: Ungraceful Termination after Configuration Exchange Completes

In Figure 25.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 25.4: SPDP2: Bootstrap Messages after Participant Removal

In Figure 25.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.

25.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 25.1 Participant Bootstrap Built-in Topic’s Data Type (DDS_ParticipantBootstrapBuiltinTopicData). The first set of rows are also part of the ParticipantConfigBuiltinTopicData.

Table 25.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 56.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 19.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 19.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 59.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.

25.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 25.1 Participant Bootstrap Built-in Topic’s Data Type (DDS_ParticipantBootstrapBuiltinTopicData). The first set of rows are also part of the ParticipantBootstrapBuiltinTopicData.

Table 25.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 56.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 59.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 59.19 PROPERTY QosPolicy (DDS Extension) .
DDS_LocatorSeq	default_unicast_locators	Default unicast locators that are used for user data. If the 59.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 59.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 59.30 USER_DATA QosPolicy.

25.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 56.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 31.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.