Issues for DDS Interoperability Wire Protocol Revision Task Force

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 12499: Clarify usage of KeyHash (dds-interop-rtf)

Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:

Usage of keyHash is currently underspecified.  It is not clear whether its presence in the message is mandatory and how it should be processed.  Resolution:  Expanded descriptions of the intended usage of keyHash parameter are added.  Revised Text:  Insert new Section 8.7.8    8.7.8 "Key Hash"    The Key Hash provides a hint for the key that uniquely identifies the data-object that is being changed within the set of objects that have been registered by the RTPS Writer.    Nominally the key is part of the serialized data of a data submessage.  Using the key hash benefits implementations providing a faster alternative than deserializing the full key from the received data-object.    When the key hash is not received by a DataReader, it should be computed from the data itself. If there is no data in the submessage, then a default zero-valued key hash should be used by the DataReader       If there is a KeyHash, if present, shall be computed as described in Section 9.6.3.3

Resolution: Expanded descriptions of the intended usage of keyHash parameter are added
Revised Text: Insert new Section 8.7.8 after Section 8.7.7 (Original Writer Info) 8.7.8 "Key Hash" The Key Hash provides a hint for the key that uniquely identifies the data-object that is being changed within the set of objects that have been registered by the RTPS Writer. Nominally the key is part of the serialized data of a data submessage. Using the key hash benefits implementations providing a faster alternative than deserializing the full key from the received data-object. When the key hash is not received by a DataReader, it should be computed from the data itself. If there is no data in the submessage, then a default zero-valued key hash should be used by the DataReader The KeyHash, if present, shall be computed as described in Section 9.6.3.3.
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Issue 12500: Add implementation note on not serializing redundant info in builtin topic (dds-interop-rtf)

Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:

Simple discovery data has parameters containing redundant information.  To not waste bandwidth, implementations should be able to refrain from sending redundant information.  As such, the spec should include an implementation note on this matter.  Resolution:  Add text in PSM, Section 9.6.2.2 describing the general allowable case in which implementations may avoid serializing parameters with redundant information.  Revised Text:  Add to Section 9.6.2.2, right before section 9.6.2.2.1 the following paragraph::    For optimization, implementations of the protocol may refrain from include in the Data submessage a parameter if it contains information that is redundant with parameters present in that same Data submessage.  As a result of this optimization an implementation can omit the serialization of the parameters listed in - ParameterId subspaces- ParameterId subspaces    Table 9.1 	- ParameterId subspaces  BuiltinEndpoint	Parameter which may be omitted	Parameter where the information on the omitted parameter can be found  SPDPdiscoveredParticipantData	ParticipantProxy::guidPrefix	ParticipantBuiltinTopicData::key  		  DiscoveredReaderData	ReaderProxy::remoteReaderGuid	SubscriptionBuiltinTopicData::key  		  DiscoveredWriterData	ReaderProxy::remoteWriterGuid	PublicationBuiltinTopicData::key  .  For example, an implementation of the protocol sending DATA message containing the SPDPdiscoveredParticipantData may omit the parameter that contains the guidPrefix. If the guidPrefix is not present in the DATA message, the implementation of the protocol in the receiver side must derive this value from the "key" parameter which is always present in the DATA message.

Resolution: Add text in PSM, Section 9.6.2.2 describing the general allowable case in which implementations may avoid serializing parameters with redundant information.
Revised Text: Add to Section 9.6.2.2 (Simple Discovery Protocol built-in Endpoints), right before section 9.6.2.2.1 (ParameterId space) the following paragraph:: For optimization, implementations of the protocol may choose not to include a parameter in the Data submessage if it contains information that is redundant with other parameters already present in that same Data submessage. As a result of this optimization an implementation can omit the serialization of the parameters listed in Table 9.10 Table 9.10 - ParameterId subspaces BuiltinEndpoint Parameter which may be omitted Parameter where the information on the omitted parameter can be found SPDPdiscoveredParticipantData ParticipantProxy::guidPrefix ParticipantBuiltinTopicData::key DiscoveredReaderData ReaderProxy::remoteReaderGuid SubscriptionBuiltinTopicData::key DiscoveredWriterData ReaderProxy::remoteWriterGuid PublicationBuiltinTopicData::key . For example, an implementation of the protocol sending DATA message containing the SPDPdiscoveredParticipantData may omit the parameter that contains the guidPrefix. If the guidPrefix is not present in the DATA message, the implementation of the protocol in the receiver side must derive this value from the "key" parameter which is always present in the DATA message.
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Issue 12501: Include key in serialized ParticipantMessageData (dds-interop-rtf)

Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:

The specification states in section 9.6.2.1 that the key portion of ParticipantMessageData is not serialized as part of the DATA submessage.  The stated argument is that the key is already part of the DATA submessage. This argument is incorrect, the DATA message may optionally include a KeyHash which is not necessarily the same as the key.  Moreover this makes the ParticipantMessageData special in the way it is serialized. The saving in bandwidth consumed do not justify all this "special code". It would be far better if the ParticipantMessageData  was treated as any regular data message and the key was serialized along.  Resolution:  Change the description in Section 9.6.2.1 to not refrain from serializing the key of ParticipantMessageData.

Resolution: Change the description in Section 9.6.2.1 to not refrain from serializing the key of ParticipantMessageData.
Revised Text: Remove following existing sentence from 9.6.2.1 (Data Representation for the ParticipantMessageData Built-in Endpoints): "On the wire, the participantGuidPrefix and the kind are not serialized as part of the ParticpantMessageData because they are already explicitly serialized as part of the Data Submessages (see Section 8.3.7.2)."
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Issue 12502: Clarify when a Payload is present in a submessage (dds-interop-rtf)

Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:

Some submessages can optionally include a payload. For example the DATA submessage includes a payload in most cases, except in some special cases where the submessage indicates unregistration and/or disposal of the data.    Currently the presence of the payload is tied to the value of the unregister and dispose flags. This is inflexible and also does not support some use-cases where it is desirable to send data with dispose messages. It would be much better to make the presence of the Data Payload separately configurable in the submessage.    Resolution:  Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information

Resolution: Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information
Revised Text: Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information . Revised Text: Replace in Table 8.36 (Structure of the Data Submessage ) the row of element "DataFlag"with the following: DataFlag SubmessageFlag Appears in the Submessage header flags. Indicates to the Reader that the dataPayload submesssge element contains the serialized value of the data-object. Add in Table 8.36 (Structure of the Data Submessage ) a row with the following: KeyFlag SubmessageFlag Appears in the Submessage header flags. Indicates to the Reader that the dataPayload submessage element contains the serialized value of the key of the data-object. Replace in Table 8.36 (Structure of the Data Submessage ) the row of element "serializedData" with the following: element type Meaning serializedPayload SerializedPayload Present only if either the DataFlag or the KeyFlag are set in the header. If the DataFlag is set, then it contains the encapsulation of the new value of the data-object after the change.If the KeyFlag is set, then it contains the encapsulation of the key of the data-object the message refers to. ============================================================= Remove in Section 8.3.7.2.5 (Logical Interpretation) the existing second paragraph: Changes to the lifecycle are communicated using the StatusInfo SubmessageElement, which contains the DisposedFlag and the UnregisteredFlag. The settings of the DisposedFlag and UnregisteredFlag indicate whether the corresponding data-object has been disposed or unregistered (or both) by the writer. ============================================================= Revise in Section 8.3.7.2.5 (Logical Interpretation) the existing third paragraph: Changes to the value are communicated by the presence of the serializedData. This element is only present if the DataFlag is set. Changes to the value are communicated by the presence of the serializedPayload. When present, the serializedPayload is interpreted either as the value of the data-object or as the key that uniquely identifies the data-object from the set of registered objects. � If the DataFlag is set and the KeyFlag is not set, the serializedPayload element is interpreted as the value of the data-object. � If the KeyFlag is set and the DataFlag is not set, the serializedPayload element is interpreted as the value of the key that identifies the registered instance of the data-object. ============================================================= Replace in Table 8.37 the row of element "serializedData" with the following: element type Meaning serializedPayload SerializedPayload Present only if either the DataFlag or the KeyFlag are set in the header. If the DataFlag is set, then it contains a consecutive set of fragments of the encapsulation of the new value of the data-object after the change.If the KeyFlag is set, then it contains a consecutive set of fragments of the encapsulation of the key of the data-object the message refers to.In either case the consecutive set of fragments contains fragmentsInSubmessage fragments and starts with the fragment identified by fragmentStartingNum. ============================================================= Replace in Section 9.4.2.12 the existing first sentence of the first paragraph, and the wire representation, with the following: A SerializedPayload SubmessageElement contains the serialized representation of either the value of an application-defined data-object or the value of the key that uniquely identifies the data-object. Replace in section 9.4.2.12 (SerializedData): The wire representation for the SerializedData is: +---------------+---------------+---------------+---------------+ | | ~ octet[] serializedData ~ | | +---------------+---------------+---------------+---------------+ With: The wire representation for the SerializedPayload is: +---------------+---------------+---------------+---------------+ | | ~ octet[] serializedPayload ~ | | +---------------+---------------+---------------+---------------+ Change section name for 9.4.2.12 (SerializedData). New name is SerializedPayload 9.4.2.12 SerializedDataPayload
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Issue 12503: Some submessage kinds are logically redundant and not extensible (dds-interop-rtf)

Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:

The submessages required to send Keyed and Unkeyed data are mapped in the PSM as two different submessages (DATA and NOKEY_DATA). These submessages have almost identical content so there is no reason to use two submessages for this. Furthermore having two different submessages at the PSM level and exposing the KeyHash as part of the submessage introduces problems with regards to the implementation and the extensibility of the protocol.  For example, future versions of the protocol may want to support keyhashes that are either bigger or smaller than the 16 Bytes used today, and do that in an inter-operable manner without breaking backwards compatibility. They may also want to omit sending a key hash when the size of the key itself is small. As the key is always included as part of the data, sending the KeyHash for small keys is inefficient at best.  This could be resolved by combining the two PSM submessages and moving the KeyHash into the InlineQos.    Resolution:  Combine the DATA and NOKEY_DATA submessages. Also combine the DATA_FRAG and NOKEY_DATA_FRAG.  Include additional fields in these submessages to enable extensibility for future submessage-specific options.

Resolution: Combine the DATA and NOKEY_DATA submessages. Also combine the DATA_FRAG and NOKEY_DATA_FRAG. Include additional fields in these submessages to enable extensibility for future submessage-specific options
Revised Text: Revise Section 9.4.5.1.1 (SubmessageId) to: enum SubmessageKind { PAD = 0x01, /* Pad */ ACKNACK = 0x06, /* AckNack */ HEARTBEAT = 0x07, /* Heartbeat */ GAP = 0x08, /* Gap */ INFO_TS = 0x09, /* InfoTimestamp */ INFO_SRC = 0x0c, /* InfoSource */ INFO_REPLY_IP4 = 0x0d, /* InfoReplyIp4 */ INFO_DST = 0x0e, /* InfoDestination */ INFO_REPLY = 0x0f, /* InfoReply */ NACK_FRAG = 0x12, /* NackFrag */ HEARTBEAT_FRAG = 0x13 /* HeartbeatFrag */ DATA = 0x15, /* Data */ DATA_FRAG = 0x16, /* DataFrag */ }; ============================================================= In existing Section 9.4.5.5 (Data Submessage), update the DATA submessage-stream: Replace: 0...2...........8...............16..............24..............32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DATA |X|X|X|I|H|D|Q|E| octetsToNextHeader | +---------------+---------------+---------------+---------------+ | EntityId readerId | +---------------+---------------+---------------+---------------+ | EntityId writerId | +---------------+---------------+---------------+---------------+ | | + SequenceNumber writerSN + | | +---------------+---------------+---------------+---------------+ | | + + | KeyHashPrefix keyHashPrefix [only if H=1] | + + | | +---------------+---------------+---------------+---------------+ | KeyHashSuffix keyHashSuffix | +---------------+---------------+---------------+---------------+ | StatusInfo statusInfo [only if I==1] | +---------------+---------------+---------------+---------------+ | | ~ ParameterList inlineQos [only if Q==1] ~ | | +---------------+---------------+---------------+---------------+ | | ~ SerializedData serializedData [only if D==1] ~ | | +---------------+---------------+---------------+---------------+ where statusInfo 0...2...........8...............16..............24..............32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|U|D| +---------------+---------------+---------------+---------------+ With: 0...2...........8...............16..............24..............32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DATA |X|X|X|X|K|D|Q|E| octetsToNextHeader | +---------------+---------------+---------------+---------------+ | Flags extraFlags | octetsToInlineQos | +---------------+---------------+---------------+---------------+ | EntityId readerId | +---------------+---------------+---------------+---------------+ | EntityId writerId | +---------------+---------------+---------------+---------------+ | | + SequenceNumber writerSN + | | +---------------+---------------+---------------+---------------+ | | ~ ParameterList inlineQos [only if Q==1] ~ | | +---------------+---------------+---------------+---------------+ | | ~ SerializedPayload serializedPayload [only if D==1 || K==1] ~ | | +---------------+---------------+---------------+---------------+ ============================================================= Revise Section 9.4.5.5.1 (Flags in the Submessage Header) to state the following: In addition to the Endianness Flag, the Data Submessage introduces the InlineQosFlag, DataFlag, and KeyFlag. The PSM maps these flags as follows: The InlineQosFlag is represented with the literal 'Q'. Q=1 means that the Data Submessage contains the inlineQos SubmessageElement. The value of the InlineQosFlag can be obtained from the expression: Q = SubmessageHeader.flags & 0x02 The DataFlag is represented with the literal 'D'. The value of the DataFlag can be obtained from the expression: D = SubmessageHeader.flags & 0x04 The KeyFlag is represented with the literal 'K'. The value of the KeyFlag can be obtained from the expression: K = SubmessageHeader.flags & 0x08 The DataFlag is interpreted in combination with the KeyFlag as follows: � D=0 and K=0 means that there is no serializedPayload SubmessageElement. � D=1 and K=0 means that the serializedPayload SubmessageElement contains the serializedData. � D=0 and K=1 means that the serializedPayload SubmessageElement contains the serializedKey. � D=1 and K=1 is an invalid combination in this version of the protocol. ============================================================= Remove Section 9.4.5.5.2 (Interpretation of the StatusInfo SubmessageElement) ============================================================= Remove Section 9.4.5.3 (NoKeyData Submessage) ============================================================= Remove Section 9.4.5.4 (NoKeyDataFrag Submessage) ============================================================= Insert new sections 9.4.5.5.2 and 9.4.5.5.3 as subsection of 9.4.5.5 (Data Submessage): 9.4.5.5.2 extraFlags The extraFlags field provides space for an additional 16 bits of flags beyond the 8 bits provided as in the submessage header. These additional bits will support evolution of the protocol without compromising backwards compatibility. This version of the protocol should set all the bits in the extraFlag to zero. 9.4.5.5.3 octetsToInlineQos The representation of this field is a CDR unsigned short (ushort). The octetsToInlineQos field contains the number of octets starting from the first octet immediately following this field until the first octet of the inlineQos SubmessageElement. If the inlineQos SubmessageElement is not present (i.e. the InlineQosFlag is not set), then octetsToInlineQos contains the offset to the next field after the inlineQos. Implementation of the protocol that are processing a received submessage should always use the octetsToInlineQos to skip any submessage headers it does not expect or understand and continue to process the inlineQos SubmessageElement (or the first submessage element that follows inlineQos if the inlineQos is not present). This rule is necessary so that the receiver will be able to interoperate with senders that use future versions of the protocol which may include additional submessage headers before the inlineQos. ============================================================= Revise Section 9.4.5.6 (DataFrag Submessage) the submessage-stream of a DATA_FRAG to be the following: 0...2...........8...............16..............24..............32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DATA_FRAG |X|X|X|X|X|K|Q|E| octetsToNextHeader | +---------------+---------------+---------------+---------------+ | Flags extraFlags | octetsToInlineQos | +---------------+---------------+---------------+---------------+ | EntityId readerId | +---------------+---------------+---------------+---------------+ | EntityId writerId | +---------------+---------------+---------------+---------------+ | | + SequenceNumber writerSN + | | +---------------+---------------+---------------+---------------+ | FragmentNumber fragmentStartingNum | +---------------+---------------+---------------+---------------+ | ushort fragmentsInSubmessage | ushort fragmentSize | +---------------+---------------+---------------+---------------+ | unsigned long sampleSize | +---------------+---------------+---------------+---------------+ | | ~ ParameterList inlineQos [only if Q==1] ~ | | +---------------+---------------+---------------+---------------+ | | ~ SerializedPayload serializedPayload ~ | | +---------------+---------------+---------------+---------------+ ============================================================= Revise in Section 9.4.5.6.1 (Flags in the Submessage Header): Replace the paragraph: The KeyHashFlag is represented with the literal 'H'. H=1 means that the DataFrag Submessage contains the KeyHashPrefix SubmessageElement. The value of the KeyHashFlag can be obtained from the expression: H = SubmessageHeader.flags & 0x04 With: The KeyFlag is represented with the literal 'K.' The value of the KeyFlag can be obtained from the expression: K = SubmessageHeader.flags & 0x04 K=0 means that the serializedPayload SubmessageElement contains the serializedData. K=1 means that the serializedPayload SubmessageElement contains the serializedKey. Replace the following text in Section 8.3.7 (RTPS Submesssages) o NoKeyData: Contains information regarding the value of an application Data-object. NoKeyData Submessages are sent by a NO_KEY Writer to NO_KEY Reader endpoints. o Data: Contains information regarding the value of an application Data-object. Data Submessages are sent by WITH_KEY Writers to WITH_KEY Readers. o NoKeyDataFrag: Equivalent to NoKeyData, but only contains a part of the new value (one or more fragments). Allows data to be transmitted as multiple fragments to overcome transport message size limitations. o DataFrag: Equivalent to Data, but only contains a part of the new value (one or more fragments). Allows data to be transmitted as multiple fragments to overcome transport message size limitations. With o Data: Contains information regarding the value of an application Data-object. Data Submessages are sent by Writers (NO_KEY Writer or WITH_KEY Writer) to Readers (NO_KEY Reader or WITH_KEY Reader). o DataFrag: Equivalent to Data, but only contains a part of the new value (one or more fragments). Allows data to be transmitted as multiple fragments to overcome transport message size limitations. Remove the NoKeyData and NoKeyDataFrag from figures 8.13 RTPS Submessages. New figure 8.13 (this figure also includes the changes diescribed in the resolution of 12505) : Modify text in section 8.3.7.2 (Data) Replace : This Submessage is sent from an RTPS Writer with topic_kind==WITH_KEY to an RTPS Reader with topic_kind==WITH_KEY. With : This Submessage is sent from an RTPS Writer (NO_KEY or WITH_KEY) to an RTPS Reader (NO_KEY or WITH_KEY). Modify text in section 8.3.7.3 (Data) Replace : This Submessage is sent from an RTPS Writer with topic_kind==WITH_KEY to an RTPS Reader with topic_kind==WITH_KEY. With : This Submessage is sent from an RTPS Writer Writers (NO_KEY or WITH_KEY) to an RTPS Reader (NO_KEY or WITH_KEY). Remove section 8.3.7.12 (NoKeyData) Remove mention of NoKeyData and NoKeyDataFrag from section 8.3.4.1 (Rules Followed by the Message Receiver) o It can affect the behavior of the Endpoint to which the message is destined. This applies to the basic RTPS messages: NoKeyData, Data, NoKeyDataFrag, DataFrag, HeartBeat, AckNack, Gap, HeartbeatFrag, NackFrag. Remove mention of NoKeyData and NoKeyDataFrag from section 8.4.1.1 (Example Behavior) 1. 7. The RTPS Writer sends the contents of the CacheChange changes to the RTPS Reader using the Data (or the NoKeyData) Submessage and requests an acknowledgment by also sending a Heartbeat Submessage. Remove the crossed-out text from the first paragraph in section 8.4.8.1 (Best-Effort StatelessWriter Behavior) The behavior of the WITH_KEY Best-Effort RTPS StatelessWriter with respect to each ReaderLocator is described in Figure 8.16. In the case of a NO_KEY Best-Effort StatelessWriter, the protocol remains identical, but the NoKeyData Submessage is used instead of the Data Submessage. Remove the crossed-out text from the first paragraph in section 8.4.9.1 (Best-Effort StatefulWriter Behavior) The behavior of the WITH_KEY Best-Effort RTPS StatefulWriter with respect to each matched RTPS Reader is described in Figure 8.16. The behavior of a NO_KEY Best-Effort RTPS StatefulWriter is identical except that NoKeyData Submessages are used instead of Data Submessages. . Remove the crossed-out text from the first paragraph in section 8.4.9.2 (Reliable StatefulWriter Behavior) The behavior of the WITH_KEY Reliable RTPS StatefulWriter with respect to each matched RTPS Reader is described in Figure 8.17. The behavior of a NO_KEY Reliable RTPS StatefulWriter is identical except that NoKeyData. Remove the crossed-out text from the second paragraph in section 8.4.11.1 (Best-Effort StatelessReader Behavior) The behavior of a NO_KEY Best-Effort RTPS StatelessReader is identical except that the Reader receives NoKeyData Submessages instead of Data Submessages. Remove the crossed-out text from the second paragraph in section 8.4.12.1 (Best-Effort StatefulReader Behavior) The behavior of a NO_KEY Best-Effort RTPS StatefulReader is identical except that the Reader receives NoKeyData Submessages instead of Data Submessages. Remove the crossed-out text from the second paragraph in section 8.4.12.2 (Reliable StatefulReader Behavior) The behavior of the WITH_KEY Reliable RTPS StatefulReader with respect to each matched RTPS Writer is described in 8.18. The behavior of a NO_KEY Reliable RTPS StatefulReader is identical except that the Reader receives NoKeyData Submessages instead of Data Submessages. Remove the following item, from the list in section 8.4.12.3 (ChangeFromWriter illustrated) o received NOKEYDATA(seq_num) : The Reader has received a NOKEYDATA message with NOKEYDATA.sequenceNumber == seq_num. Remove the crossed-out text from the second paragraph in section 8.4.14.1 (Large Data) That said, a transport may impose its own limitations. For example, it may limit the maximum packet size (e.g., 64K for UDP) and hence the maximum RTPS Submessage size. This mainly affects the Data and NoKeyData Submessages, as it limits the maximum size of the serializedData or also, the maximum serialized size of the data type used. In order to address this limitation, Section 8.3.7 introduces the following Submessages to enable fragmenting large data: o DataFrag o NoKeyDataFrag o HeartbeatFrag o NackFrag The following sections list the corresponding behavior required for interoperability. The behavior is identical for DataFrag and NoKeyDataFrag Submessages, so the discussion below only mentions the former. Remove the crossed-out text from Table 8.77 RTPS SPDPdiscoveredParticipantData attributes expectsInlineQos bool Describes whether the Readers within the Participant expect that the QoS values that apply to each data modification are encapsulated with each Data and NoKeyData Submessage. Remove the crossed-out text from the first paragraph in section 8.7.1 (Adding in-line Parameters to Data Submessages) Data, NoKeyData, DataFrag and NoKeyDataFrag Submessages optionally contain a ParameterList SubmessageElement for storing in-line QoS parameters and other information. Remove the crossed-out text from the first paragraph in section 8.7.3.2 (Including in-line filter results with each data sample) In general, when applying filtering on the Writer side, a sample is not sent if it does not pass the remote Reader's filter. In that case, the Data submessage is replaced by a Gap submessage. This ensures the sample is not considered 'lost' on the Reader side. This approach matches that of applying a time-based filter on the Writer side. The remainder of the discussion only refers to Data Submessages, but the same approach is followed for NoKeyData, DataFrag, and NoKeyDataFrag Submessages. Remove the crossed-out text from the 3rd and 7th paragraphe in section 8.7.5 (Coherent Sets) In order to support coherent sets, RTPS uses the in-line QoS parameter extension mechanism to include additional information in-line with each Data Submessage. The additional information denotes membership to a particular coherent set. The remainder of the discussion only refers to Data Submessages, but the same approach is followed for NoKeyData, DataFrag and NoKeyDataFrag Submessages. � Note that a Data or NoKeyData Submessage need not necessarily contain serializedDataPayload. This makes it possible to notify the Reader about the end of a coherent set before the next data is written by the Writer. Change the 1st paragraphe in section 9.6.3 (Coherent Sets). Remove the crossed-out text and add the underlined text. The Messages module within the PIM (Section 8.3) provides the means for the Data (Section 8.3.7.2), NoKeyData (Section 8.3.7.12), and DataFrag (Section 8.3.7.3), and NoKeyDataFrag (Section 8.3.7.13) Submessages to include QoS policies in-line with the Submessage. The QoS policies are encapsulated using a ParameterList. Remove the crossed-out text from the 3rd and 7th paragraphe in section 9.6.3.2 Coherent set (PID_COHERENT_SET) As defined in Section 8.7.4, all Data, NoKeyData, DataFrag and NoKeyDataFrag Submessages that belong to the same coherent set must contain the coherent set in-line QoS parameter with value equal to the sequence number of the first sample in the set. Remove the crossed-out text from Table 8.13 (Types used to define RTPS messages) SubmessageKind Enumeration used to identify the kind of Submessage.The following values are reserved by version 2.0 of the protocol:NOKEY_DATA, DATA, GAP, HEARTBEAT, ACKNACK, PAD, INFO_TS, INFO_REPLY, INFO_DST, INFO_SRC, DATA_FRAG, NOKEY_DATA_FRAG, NACK_FRAG, HEARTBEAT_FRAG
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Issue 12504: Change KeyHash from SubmessageElement to Parameter (dds-interop-rtf)

Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:

The inclusion of keyHashPrefix and keyHashSuffix fields in DATA and DATA_FRAG submessages should be optional.  The keyHash is a DDS-level optimization whose interpretation by RTPS is unnecessary.  Hence, it is logically better to reassign it as a parameter that may be included inline.  Resolution:  Replace mentioned instances of keyHashPrefix/Suffix with keyHash inline parameter.

Resolution: Replace mentioned instances of keyHashPrefix/Suffix with keyHash inline parameter.
Revised Text: Add to Table 9.4 (PSM mapping of the value types that appear on the wire) Type PSM Mapping KeyHash_t struct { octet[16] value ;} KeyHash_t ============================================================= Add to Table 9.13 (ParameterId Values) Name ID type PID_KEY_HASH 0x0070 KeyHash_t Add to Table 9.14 (Inline QoS Parameaters) Name ID type PID_KEY_HASH 0x0070 KeyHash_t Add Section 9.6.3.3 KeyHash after Section 9.6.3.2 (Coherent set (PID_COHERENT_SET)) 9.6.3.3 KeyHash (PID_KEY_HASH) The key hash inline parameter contains the CDR encoding of the KeyHash_t. The KeyHash_t is defined as a 16-Byte octet array (see Table 9.4) therefore the key hash inline parameter just copies those 16 Bytes. ============================================================= Remove from Table 8.13 (Types used to define RTPS messages) existing rows corresponding to these elements: � keyHashPrefix_t � keyHashSuffix_t ============================================================= Remove from Table 8.36 (Structure of the Data Submessage) existing rows corresponding to these elements: � KeyHashFlag � keyHashPrefix � keyHashSuffix ============================================================= Remove from Table 8.37 (Structure of the DataFrag Submessage) existing rows corresponding to these elements: � KeyHashFlag � keyHashPrefix � keyHashSuffix ============================================================= Remove from Section 8.3.7.2.5 the paragraph: If the KeyHashFlag is set, the keyHashPrefix element contains a valid prefix. In that case, the instance is uniquely identified using: instanceGUID = { Data.keyHashPrefix, Data.keyHashSuffix } If no keyHashPrefix element is sent with the data, the prefix is obtained using the state of the Receiver: instanceGUID = { Receiver.sourceGuidPrefix, Data.keyHashSuffix } ============================================================= Remove section 9.4.2.14 (KeyHashPrefix) ============================================================= Remove section 9.4.2.15 (KeyHashSuffix) Remove from Figure 8.12 (RTPS SubmessageElements) the elements: � KeyHashPrefix � KeyHashSuffix The new figure 8.12 is (this figure also includes the changes diescribed in the resolution of 12505) ============================================================= Remove from Section 8.3.5 (RTPS SubmessageElements) mention of KeyHashPrefix and KeyHashSuffix. This includes the first paragraph, section 8.3.5.10 and section 8.3.5.11 ============================================================= Modify the first paragraph in section 8.4.8.1 (Best-Effort Stateless Writer Behavior) removing the last sentence The behavior of the WITH_KEY Best-Effort RTPS StatelessWriter with respect to each ReaderLocator is described in Figure 8.16. In the case of a NO_KEY Best-Effort StatelessWriter, the protocol remains identical, but the NoKeyData Submessage is used instead of the Data Submessage. Remove the second paragraph in section 8.4.8.1 (Best-Effort Stateless Writer Behavior) As described in Error! Reference source not found., the NoKeyData Submessage is a simplified version of the Data Submessage that omits the keyHashPrefix and keyHashSuffix fields that would indicate the instance of the data-object to which the change applies. These fields are not needed because without keys, the Topic implicitly has only a single data-object. Modify the first paragraph in section 8.4.8.2 (Reliable Stateless Writer Behavior) removing the last sentence in the paragraph. The behavior of the WITH_KEY reliable RTPS StatelessWriter with respect to each ReaderLocator is described in Figure 8.17. For a NO_KEY reliable StatelessWriter, the protocol remains identical except that the NoKeyData Submessage is used instead of the Data Submessage. Remove from Table 9.4 (Types PSM mapping of the value types that appear on the wire) existing rows corresponding to these elements: � keyHashPrefix_t � keyHashSuffix_t Modify first paragraph of section 9.4.5.6.1 (Flags in the Submessage Header) From In addition to the EndiannessFlag, The DataFrag Submessage introduces the KeyHashFlag and InlineQosFlag (see "Contents" on page 49). The PSM maps these flags as follows: To In addition to the EndiannessFlag, The DataFrag Submessage introduces the KeyFlag and InlineQosFlag (see "Contents" on page 49). The PSM maps these flags as follows: Modify Figure 8.26 ParticipantMessageData. Remove the KeyHashPrefix_t and KeyHashSuffix_t and add a GUID_t the modified figure 8.26 is: Modify section 9.6.2.1 Data Representation for the ParticipantMessageData Built-in Endpoints. Change struct ParticipantMessageData { KeyHashPrefix_t participantGuidPrefix; KeyHashSuffix_t kind; sequence<octet> data; }; The DDS key consists of 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 Submessages (see Section 8.3.7.2). To struct ParticipantMessageData { GuidPrefix_t participantGuidPrefix; octet[4] kind; sequence<octet> data; };
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Issue 12505: Change StatusInfo from SubmessageElement to Parameter (dds-interop-rtf)

Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary:  The statusInfo field of DATA submessage holds flags relating DDS-level concepts that are interpreted at higher layers than RTPS.  Hence, it is not necessary to have statusInfo as an explicit field; rather,  it can be included in the inlineQos SubmessageElement.    Resolution:  Replace all instances of the statusInfo field of DATA with the new statusInfo inline parameter.

Resolution: Replace all instances of the statusInfo field of DATA with the new statusInfo inline parameter.
Revised Text: Add to Table 9.4 (PSM mapping of the value types that appear on the wire) Type PSM Mapping StatusInfo_t struct { octet[4] value;} StatusInfo_t ============================================================= Add to Table 9.11 (ParameterId Values) Name ID type PID_STATUS_INFO 0x0071 StatusInfo_t ============================================================= Remove from Table 8.36 (Structure of the Data Submessage) rows corresponding to these elements: � StatusInfoFlag � statusInfo Modify the first paragraph in Section 8.3.5 (RTPS SubmessageElements) Remove the mention of StatusInfo. Remove Section 8.3.5.16 (StatusInfo) Remove from Figure 8.12 RTPS (SubmessageElements the StatusInfo class), the resulting figure is as shown in issue 12504 Remove from Figure 8.13 (RTPS Submessages), Data Submessage the StatusInfo field, the the resulting figure is as shown in issue 12503 Add section 8.7.4 Changes in the Instance LifecycleState after Section 8.7.3 (Content-filtered Topics) 8.7.4 Changes in the Instance LifecycleState Beyond writing data, a DDS DataWriter can register data object instances (operation register_instance) , update their value (operation write), dispose data-object instances (operation dispose), and unregister them (operation unregister_instance). Each one of these operations may cause notifications to be dispatched to the matched DDS DataReaders. The DDS DataReader can determine the nature of the change by inspecting the LifecycleState instance_state field in the SampleInfo that is returned on the DDS DataReader read or take call. RTPS uses regular Data Submessages and the in-line QoS parameter extension mechanism to communicate lifecycle changes. The serialized information within the inline QoS contains the new LifecycleState, that is, whether the instance has been registered, unregistered or disposed. The actual details depend on the PIM (e.g. see Section 9.6.3.4). An implementation of RTPS must use the Data Submessage to communicate a lifecycle changes. When doing so an implementation of RTPS is allowed to include only the Key of the Data-Object within the SerializedPayload submessage element (see Section 8.3.7.2). This is because the Key is sufficient to uniquely identify the Data_Object instance to which the LifecycleState change applies. An implementation of RTPS is not required to propagate registration changes until the DDS DataWriter writes the first value for that Data-Object instance. Add to Table 9.13 (ParameterId Values) Name ID type PID_STATUS_INFO 0x0071 StatusInfo_t Add to Table 9.14 (Inline QoS Parameaters) Name ID type PID_STATUS_INFO 0x0071 StatusInfo_t Add Section 9.6.3.4 StatusInfo_t (PID_STATUS_INFO) 9.6.3.4 StatusInfo_t (PID_STATUS_INFO) The status info parameter contains the CDR encoding of the StatusInfo_t. The StatusInfo_t is defined as a 4-Byte octet array (see Table 9.4) therefore the status info inline parameter just copies those 4 Bytes. The status info parameter may appear in the Data or in the DataFrag submessages. The StatusInfo_t shall be interpreted as a 32-bit worth of flags with the layout shown below: 0...2...........8...............16..............24..............32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|U|D| +---------------+---------------+---------------+---------------+ The flags represented with the literal 'X' are unused by this version of the protocol and should be set to zero by the writer and not interpreted by the reader so that they may be used in future versions of the protocol without breaking interoperability. The flags in the status info provide information on the status of the data-object to which the submessage refers. Specifically the status info is used to communicate changes to the LifecycleState of a data-object instance. The current version of the protocol defines the DisposeFlag and the UnregisterFlag. The DisposeFlag is represented with the literal 'D'. D=1 indicates that the DDS DataWriter has disposed the instance of the data-object whose Key appears in the submessage. The UnregisterFlag is represented with the literal 'U'. U=1 indicates that the DDS DataWriter has unregistered the instance of the data-object whose Key appears in the submessage.
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Issue 12506: Update protocol version to 2.1 (dds-interop-rtf)

Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary:  The set of proposed changes necessitates updating the protocol version.  Resolution:  Change protocol version from 2.0 to 2.1.

Resolution: Change protocol version from 2.0 to 2.1.
Revised Text: Table 8.13 (Types used to define RTPS messages), 5th row (cell reads "SubmessageKind"), change: The following values are reserved by version 2.0 of the protocol: TO The following values are reserved by this version of the protocol: Section 8.3.3.1.2 (version), first paragraph, first sentence. Modify from: The version identifies the version of the RTPS protocol. Implementations following this version of the document implement protocol version 2.0 (major = 2, minor = 0) and have this field set to PROTOCOLVERSION_2_0. To: The version identifies the version of the RTPS protocol. Implementations following this version of the document implement protocol version 2.1 (major = 2, minor = 1) and have this field set to PROTOCOLVERSION. Replace PROTOCOLVERSION_2_0 with PROTOCOLVERSION in: Table 8.16 (Initial State of the Receiver) Modify row in Table 8.2 (Types of the attributes that appear in the RTPS Entities and Classes) as shown: ProtocolVersion_t Type used to represent the version of the RTPS protocol. The version is composed of a major and a minor version number. See also Section 8.6.The following values are reserved by the protocol:PROTOCOLVERSIONPROTOCOLVERSION_1_0PROTOCOLVERSION_1_1PROTOCOLVERSION_2_0PROTOCOLVERSION_2_1PROTOCOLVERSION is an alias for the most recent version, in this case PROTOCOLVERSION_2_1. Modify row in Table 9.4 (PSM mapping of the value types that appear on the wire) as shown: ProtocolVersion_t Mapping of the typetypedef struct { octet major; octet minor;} ProtocolVersion_t;Mapping of the reserved values:#define PROTOCOLVERSION_1_0 {1,0}#define PROTOCOLVERSION_1_1 {1,1}#define PROTOCOLVERSION_2_0 {2,0}#define PROTOCOLVERSION_2_1 {2,1}#define PROTOCOLVERSION {2,1}PROTOCOLVERSION_2_1The Implementations following this version of the document implement protocol version 2.1 (major = 2, minor = 1). Change "2.0" to "2.1" in the following locations: � Section 8.3.3.1.2, first paragraph, first sentence. � Section 8.3.4.1, numbered item 3, second sentence {note: two occurrences in this sentence} � Section 8.3.4.1, numbered item 4, third sentence. � Section 8.3.5, first paragraph, second sentence � Section 8.3.5.3, second paragraph (right after Table 8.20), first sentence � Section 8.3.5.9, within the bulleted items following the second paragraph o the second sentence in the second bulleted item o the second sentence in the third bulleted item � Section 8.3.7, first paragraph, first sentence � Section 8.6, first paragraph, remove crossed-out sections sentence replace: Implementations of this version of the RTPS protocol (2.0) should be able to process RTPS Messages not only with the same major version (2) but possibly higher minor versions. Change "2.0" to "2.1" in wherever it appears in the document, specifically the following locations: � Section 9.3.1.2, last paragraph (right before Table 9.1), second sentence � Section 9.3.1.4, the title � Section 9.3.1.4, first paragraph, first and second sentences � Table 9.3, the caption � Section 9.4.2.11, last paragraph, first (and only) sentence � Section 9.4.5.1.1, first paragraph, last sentence � Section 9.4.5.1.2, last paragraph, first and second sentences � Section 9.6.4, the title � Section 9.6.4, first paragraph, first and second sentences Other changes: � Table 8.2, 6th row (cell in first column reads "ProtocolVersion_t"), the cell in the second column, change "PROTOCOLVERSION_2_0" to "PROTOCOLVERSION_2_1" o NOTE: there are two instances of this change in this cell. � Table 8.16, 2nd row (cell in first column reads "sourceVersion"), the cell in the second column, change "PROTOCOLVERSION_2_0" to "PROTOCOLVERSION_2_1" � Section 8.3.3.1.2, change "(major = 2, minor = 0)" to "(major = 2, minor = 1)" � Section 8.3.5.3, second paragraph, within the list of special values, change "PROTOCOLVERSION_2_0" to "PROTOCOLVERSION_2_1"
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Issue 12507: Properly assign vendor IDs (dds-interop-rtf)

Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary:  Section 9.4.5.1.1 leaves unspecified the list of vendor IDs  Resolution:  Modify section to include a reference to an appendix or table where all the vendor IDs are listed.

Resolution: Modify section to specify that vendor ID�s are managed separately from the specification and include a link to http://www.omgwiki.org/dds/content/page/ddsrtps- vendor-and-product-ids
Revised Text: Modify section to specify that vendor ID�s are managed separately from the specification and include a link to http://www.omgwiki.org/dds/content/page/ddsrtps- vendor-and-product-ids
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Issue 12508: Computation of KeyHash is unspecified (dds-interop-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Niels Kortstee, niels.kortstee(at)adlinktech.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary:  The specification does not describe how the KeyHash is computed from the Key.     This implicates that key hashes in messages coming from different RTPS implementations can never be interpreted, because one implementation may utilize a different key hash algorithm then the other.     I would prefer that the hash algorithm becomes part of the specification. RTPS implementations can choose to implement the prescribed algorithm or simply use a zero-valued key.    Resolution:  The UDP PIM should mandate that the KeyHash is computed either as the serialized key or else as an MD5 digest, depending on whether the serialize key for the type can exceed the 128 that are used for the KeyHash.

Resolution: The UDP PIM should mandate that the KeyHash is computed either as the serialized key or else as an MD5 digest, depending on whether the serialize key for the type can exceed the 128 that are used for the KeyHash. The resolution of this issue depends on the presence of new section 9.6.3.3 titled "Key Hash" added as part of the resolution of issue. 12504. If issue 12504 is resolved in a way that does not add this section, then the resolution proposed here would not be valid.
Revised Text: Apply the following changes after the modifications indicated in issue 12504 Add to the end of Section 9.6.3.3 (KeyHash (PID_KEY_HASH), which was added by the resolution of issue 12504) The KeyHash_t is computed from the Data as follows using one of two algorithms depending on whether the Data type is such that the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less than 128bits (the size of the KeyHash_t): � If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less than 128 bits then the KeyHash_t shall be computed as the CDR Big-Endian encapsulation of all the Key fields in sequence. Any unfilled bits in the KeyHash_t after all the key fields have been encapsulated shall be set to zero. � Otherwise the KeyHash_t shall be computed as a 128 bit MD5 Digest (IETF RFC 1321) applied to the CDR Big-Endian encapsulation of all the Key fields in sequence. Note that the choice of the algorithm to use depends on the data-type, not on any particular data value. Example 1: Assume the following IDL-described type: struct TypeWithShortKey { long id; /* assume defined as a key field */ string name<6>; /* assume defined as a key field */ /* other non-key fields */ }; Then we know that the maximum size for the CDR encapsulation of the key fields is 15 Bytes (4 for the 'id' field, plus 4 for the length of the string 'name' plus at most 7 Bytes for the string (includes extra byte for terminating NUL). In this example the KeyHash_t shall be computed as: [CDR(id), CDR(name), <zero fill to 16 bytes> ] Where CDR(x) represents the big-endian CDR encapsulation of that field. A concrete data value of this type such as { 32, "hello", �} would be encapsulated as: 0......8.....16.....24.....32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | 0x00 | 0x00 | 0x20 | +------+------+------+------+ | 0x00 | 0x00 | 0x00 | 0x06 | +------+------+------+------+ | 'h' | 'e' | 'l' | 'l' | | 'o' | 0x00 | 0x00 | 0x00 | Note that for clarity use a notation where each byte can be represented either as an hexadecimal number (e.g. 0x20) or as a character (e.g. 'h'); Example 2: Assume the following IDL-described type: struct TypeWithShortKey { long id; /* assume defined as a key field */ string name<8>; /* assume defined as a key field */ /* other non-key fields */ }; Then we know that the maximum size for the CDR encapsulation of the key fields is 17 Bytes (4 for the 'id' field, plus 4 for the length of the string 'name' plus at most 9 Bytes for the string (includes extra byte for terminating NUL). In this example the KeyHash_t shall be computed as: MD5( [CDR(id), CDR(name)]) Proposed Disposition: Resolved
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Issue 12509: The specification does not state how to generate unique GUIDs (dds-interop-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Niels Kortstee, niels.kortstee(at)adlinktech.com)
Nature: Uncategorized Issue
Severity:
Summary:

In RTPS each entity has a so-called GUID_t. It consists of a 12 Byte GuidPrefix_and a 4-Byte EntityId_t and must be globally unique. In heterogeneous systems (with multiple RTPS implementations), the specification provides no mechanism or guidance to ensure global uniqueness.    A solution would be to make the vendorId part of the GuidPrefix_t.    Resolution:  The first two bytes of the GUID_t prefix should be the vendor id.

Resolution: The first two bytes of the GUID_t prefix should be the vendor id, the rest can be chosen by the vendors as they see fit, as long as they ensure uniqueness. This approach avoids collisions between vendors, but has the drawback that it limits the range of available GUID prefixes for each vendor. But as we can see below, this limitation should not cause a problem as the remaining 10 Bytes are sufficient to generate unique GUIDs even in very large DDS domains. The GUID_t prefix is 12 bytes, after 2 are used for the vendor there remain only 10 bytes that can be used to generate unique DDS Entity GUIDs, this means there can be S = 2^80 different GUID prefixes. GUID prefixes are assigned in one-to-one correspondence with DDS DomainParticipants as all the DDS Entities within a participant share the same GUID Prefix. Assume that a particular DDS domain has �n� DDS participants, if a good algorithm is used to generate GUID prefixes, the probability of a collision P(n) (i.e. two or more entities having the same GUID) can be approximated as: P(n) ~ 1 � exp(-(n^2)/(2*S)) In a very large system with 1 Million DDS Participants the probability of a collision would be extremely small: 4e-13 In a system with 1 Billion (10^9) DDS Participants the probability of a collision would be 4e-7 also very small. Therefore the solution requiring the first 2 bytes of the GUID_t Prefix to match the vendorId will not prevent the generation of unique GUID prefixes.
Revised Text: Add the following paragraphs to section 9.3.1.5 (Mapping of the GUID) above the paragraph that starts with �The reserved constant GUID_UNKNOWN � Section 8.2.4 states that all RTPS Entities with a DomainParticipant share the same guidPrefix. Furthermore Section 8.2.4.2 states that implementors have freedom to choose the guidPrefix as long as each DomainParticipant within a DDS Domain has a unique guidPrefix. The PIM restricts this freedom. To comply with this specification, implementations of the RTPS protocol shall set the first two bytes of the guidPrefix to match their assigned vendorId (see Section 8.3.3.1.3). This ensures that the guidPrefix remains unique within a DDS Domain even if multiple implementations of the protocol are used. In other words, implementations of the RTPS protocol are free to use any technique they deem appropriate to generate unique values for the guidPrefix as long as they meet the following constraint: guidPrefix[0] = vendorId[0] guidPrefix[1] = vendorId[1] Future versions of the RTPS 2.x protocol shall also follow this rule for generating the guidPrefix. The value of these first two bytes is set as specified above with the sole purpose of enabling the generation of unique GUIDs across implementations. This value should not be relied upon for other purposes. This ensures the change does not break interoperability with previous versions of the protocol. Use of the reserved vendorId is further described in Section 9.4.4.
Actions taken:
May 20, 2008: received issue
October 27, 2008: closed issue

Discussion: