Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
The [RTPS] version referenced in section 3 is version 2.2. It should be updated to version 2.3.
The reference to [RTPS] in [RTPS] Clause 184.108.40.206, “KeyHash (PID_KEY_HASH)”, should change to [RTPS] Clause 220.127.116.11, “KeyHash (PID_KEY_HASH)”. This is because the section number changed in RTPS 2.3.
Section 7.6.7 was not fully updated to account for CDR version 2. For example it does not clearly state whether DHEADER is serialized for the purposes of computing the KeyHash.
Also the sentence about backwards compatibility is no longer relevant.
The decision of whether to serialize DHEADER or not should be taken as soon as possible as it would affect interoperability.
Reported: DDS-XTypes 1.2 — Fri, 20 Apr 2018 12:56 GMT
Disposition: Resolved — DDS-XTypes 1.3
Update 7.6.7 with more complete description of KeyHash computation
Update section 3 [RTPS] to reference version 2.3.
Define the KeyHash computation in a more unambiguous as described below.
Take the AggregatedType "Foo" that is the container of the key members for which we want to compute the key hash.
For the purposes of computing the key hash, define a key holder type FooKeyHolder as follows.
- Start with the original Foo type
- Remove any no-key members
- Reorder the key members in the order of memberId (this handles the cases where the AggregateType is Final/Appendable/Mutable).
- Apply this recursively to the types of the key members if they are of an AggregatedType.
Consider FooKeyHolder (and any KeyHolder types resulting from key members that were of an AggregatedType) as having @extensibility(FINAL).
After FooKeyHolder has been constructed. We have two cases:
(a) If the maximum Serialized Size of FooKeyHolder <= 16 then KeyHash = CDR_BigEndian(FooKeyHolder)
(b) If the maximum Serialized Size of FooKeyHolder > 16, then KeyHash = MD5(CDR_BigEndian(FooKeyHolder))
CDR_BigEndian uses XCDR version 2 encoding rules and assume serialization on a 4-byte aligned buffer.
Therefore the resulting serialized type does not have any encapsulation header, not any DHEADER (from Appendable/Mutable types) nor any MemberHeader (from Mutable types), and uses a maximum alignment of 4-bytes.
Updated: Tue, 8 Oct 2019 17:55 GMT