Issue 12504: Change KeyHash from SubmessageElement to Parameter (dds-interop-rtf) Source: Real-Time Innovations (Mr. Kenneth Brophy, ken@rti.com ken.brophy@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 Discussion: End of Annotations:===== MG Issue No: 12504R#6 Title: Change KeyHash from SubmessageElement to Parameter Source: Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com) 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. 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 Paramaters Name ID type PID_KEY_HASH 0x0070 KeyHash_t TODO ass 9.6.3.x describing PID_KEY_HASH ============================================================= 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 Submessageexisting 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) TODO Remove from Figure 8.12 the elements: · KeyHashPrefix · KeyHashSuffix ============================================================= Remove from Section 8.3.5 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 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 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 The behavior of the WITH_KEY reliable RTPS StatelessWriter with respect to each ReaderLocator is described in Error! Reference source not found.. 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: TODO: Modify Figure 8.26 ParticipantMessageData. Remove the KeyHashPrefix_t and KeyHashSuffix_t and add a GUID_t Modify section 9.6.2.1 Data Representation for the ParticipantMessageData Built-in Endpoints. Change struct ParticipantMessageData { KeyHashPrefix_t participantGuidPrefix; KeyHashSuffix_t kind; sequence 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 data; }; Disposition: