Issue 12503: Some submessage kinds are logically redundant and not extensible (dds-interop-rtf) Source: Real-Time Innovations (Mr. Kenneth Brophy, ken@rti.com ken.brophy@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 Discussion: End of Annotations:===== MG Issue No: 12503R#5 Title: Some submessage kinds are logically redundant and not extensible Source: Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com) 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. Revised Text: ============================================================= Revise Section 9.4.5.1.1 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 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: 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 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: 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 . 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. . Data: Contains information regarding the value of an application Data-object. Data Submessages are sent by WITH_KEY Writers to WITH_KEY Readers. . 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. . 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 . 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). . 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. TODO Remove the NoKeyData and NoKeyDataFrag from figures 8.13 RTPS Submessages. 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 TODO Search and remove all NoKeyData from document. Remove mention of NoKeyData and NoKeyDataFrag from section 8.3.4.1 . 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 1. 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 The behavior of the WITH_KEY Best-Effort RTPS StatelessWriter with respect to each ReaderLocator is described in Error! Reference source not found.. 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 The behavior of the WITH_KEY Best-Effort RTPS StatefulWriter with respect to each matched RTPS Reader is described in Error! Reference source not found.. 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 The behavior of the WITH_KEY Reliable RTPS StatefulWriter with respect to each matched RTPS Reader is described in Error! Reference source not found.. 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 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 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 The behavior of the WITH_KEY Reliable RTPS StatefulReader with respect to each matched RTPS Writer is described in Error! Reference source not found.. 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 . 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 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, Error! Reference source not found. introduces the following Submessages to enable fragmenting large data: . DataFrag . NoKeyDataFrag . HeartbeatFrag . 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 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 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 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 Disposition: