Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The current Writer liveliness mechanism piggybacks on SPDP messaging. As RTPS should also be able to support other discovery protocols beyond SPDP, including a static configuration, this is not the best approach.
It is true that all implementations must support at least SPDP, but if a customer wants to disable it (e.g. no need to interoperate with a different vendor so it possible to use a different protocol exclusively), this should not affect the DW liveliness mechanism. To some extent, it does not, but sending SPDPDiscoveredParticipantData to maintain a DWs liveliness is wasteful, especially if SPDP is not even used.
Resolution:
Update the Writer liveliness protocol to be independent of Discovery.
Revised Text:
Since this change is lengthy, the editorial instructions appear in a blue font to help the reader distinguish them from document content.
· Section 8.7.2.2.3, first paragraph, first bulleted item, replace:
DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the SPDPbuiltinParticipantWriter. For a given Participant, in order to maintain the liveliness of its Writer Entities with LIVELINESS QoS set to AUTOMATIC, implementations must refresh the Participant's liveliness (i.e., send the SPDPDiscoveredParticipantData) at a rate faster than the smallest lease duration among the Writers.
with:
DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. For a given Participant, in order to maintain the liveliness of its Writer Entities with LIVELINESS QoS set to AUTOMATIC, implementations must refresh the Participant's liveliness (i.e., send the ParticipantMessageData, see Section 8.4.13.5 for details) at a rate faster than the smallest lease duration among the Writers.
· Section 8.7.2.2.3, first paragraph, first bulleted item, replace:
DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS : liveliness is maintained through the SPDPbuiltinParticipantWriter. If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant's liveliness (i.e send the SPDPDiscoveredParticipantData) and add the PID_PARTICIPANT_MANUAL_LIVELINESS_COUNT in-line QoS, where the value of the in-line QoS is incremented each time.
with:
DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant's liveliness (i.e send the ParticipantMessageData, see Section 8.4.13.5 for details).
· Section 8.5.2, change the title from "RTPS built-in Endpoints" to "RTPS built-in Discovery Endpoints"
· Add the following row to the end of Table 8.50:
ParticipantMessageData Type used to hold data exchanged between Participants. The most notable use of this type is for the Writer Liveliness Protocol.
· Insert new Section following 8.4.12 (so a new 8.4.13) with the following content:
8.4.13 Writer Liveliness Protocol
The DDS specification requires the presence of a liveliness mechanism. RTPS realizes this requirement with the Writer Liveliness Protocol. The Writer Liveliness Protocol defines the required information exchange between two Participants in order to assert the liveliness of Writers contained by the Participant.
All implementations must support the Writer Liveliness Protocol in order to be interoperable.
8.4.13.1 General Approach
The Writer Liveliness Protocol uses pre-defined built-in Endpoints. The use of built-in Endpoints means that once a Participant knows of the presence of another Participant, it can assume the presence of the built-in Endpoints made available by the remote participant and establish the association with the locally-matching built-in Endpoints.
The protocol used to communicate between built-in Endpoints is the same as used for application-defined Endpoints.
8.4.13.2 Built-in Endpoints required by the Writer Liveliness Protocol
The built-in Endpoints required by the Writer Liveliness Protocol are the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. The names of these Endpoints reflect the fact that they are general-purpose. These Endpoints are used for liveliness but can also be used for other data in the future.
The RTPS Protocol reserves the following values of the EntityId_t for these built-in Endpoints:
ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER
ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER
The actual value for each of these EntityId_t instances is defined by each PSM.
8.4.13.3 BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader QoS
For interoperability, both the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader use the following QoS values:
· reliability.kind = RELIABLE_RELIABILITY_QOS
· durability.kind = TRANSIENT_LOCAL_DURABILITY_QOS
· history.kind = KEEP_LAST_HISTORY_QOS
· history.depth = 1
8.4.13.4 Data Types associated with the built-in Endpoints used by the Writer Liveliness Protocol
Each RTPS Endpoint has a HistoryCache that stores changes to the data-objects associated with the Endpoint. This is also true for the RTPS built-in Endpoints. Therefore, each RTPS built-in Endpoint depends on some DataType that represents the logical contents of the data written into its HistoryCache.
Figure X defines the ParticipantMessageData DataType associated with the RTPS built-in Endpoints for the "DCPSParticipantMessage" Topic.
Figure X The ParticipantMessageData structure.
8.4.13.5 Implementing the Writer Liveliness Protocol using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader
The liveliness of a subset of Writers belonging to a Participant is asserted by writing a sample to the BuiltinParticipantMessageWriter. If the Participant contains one or more Writers with a liveliness of AUTOMATIC_LIVELINESS_QOS then one sample is written at a rate faster than the smallest lease duration among the Writers sharing this QoS. Similarly, a separate sample is written if the Participant contains one or more Writers with a liveliness of MANUAL_BY_PARTICIPANT_LIVELINESS_QOS at a rate faster than the smallest lease duration among these Writers. The two instances are orthogonal in purpose so that if a Participant contains Writers of each of the two liveliness kinds described, two separate instances must be periodically written. The instances are distinguished using their DDS key which is comprised of the participantGuidPrefix and the kind fields. Each of the two types of liveliness QoS handled through this protocol will result in a unique kind field and therefore form two distinct instances in the HistoryCache.
In both liveliness cases the participantGuidPrefix field contains the GuidPrefix_t of the Participant that is writing the data (and therefore asserting the liveliness of its Writers).
The DDS liveliness kind MANUAL_BY_TOPIC_LIVELINESS_QOS is not implemented using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. It is discussed in Section 8.7.2.2.3.
· Add the following entries to Table 9.2
BuiltinParticipantMessageWriter ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER =
{00,02,00,C2}
BuiltinParticipantMessageReader ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER =
{00,02,00,C7}
· Insert a new Section 9.6.2.1 with the following content:
9.6.2.1 Data representation for the ParticipantMessageData built-in Endpoints
The Behavior Module within the PIM (Section 8.4) defines the DataType ParticipantMessageData. This type is the logical content of the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader built-in Endpoints.
The PSM maps the ParticipantMessageData type into the following IDL:
struct ParticipantMessageData
{
KeyHashPrefix_t participantGuidPrefix;
KeyHashSuffix_t kind;
sequence<octet> data;
}
;
The DDS key consists of the both the participantGuidPrefix and the kind fields. On the wire, the participantGuidPrefix and the kind are not serialized as part of the ParticipantMessageData because they are already explicitly serialized as part of the Data Submessage (see Section 8.3.7.2).
The following values for the kind field are reserved by RTPS:
#define PARTICIPANT_MESSAGE_DATA_KIND_UNKNOWN
{0x00,0x00,0x00,0x00}
#define PARTICIPANT_MESSAGE_DATA_KIND_AUTOMATIC_LIVELINESS_UPDATE
{0x00,0x00,0x00,0x01}
#define PARTICIPANT_MESSAGE_DATA_KIND_MANUAL_LIVELINESS_UPDATE
{0x00,0x00,0x00,0x02}
RTPS also reserves for future use all values of the kind field where the most significant bit is not set. Therefore:
kind.value[0] & 0x80 == 0 // reserved by RTPS
kind.value[0] & 0x80 == 1 // vendor specific kind
Implementations can decide the upper length of the data field but must be able to support at least 128 bytes.
Following the CDR encoding, the wire representation of the ParticipantMessageData structure is:
0...2...........8...............16.............24...............31
--------------
| unsigned long data.length |
--------------
~ octet[] data.value ~
--------------
· Insert a new Section called 9.6.2.2
Use the contents of Section 9.6.2 from the start until the beginning of Section 9.6.2.1