pub enum KeyHolderOrder {
AscendingMemberId,
Declaration,
}Expand description
In what order the members of a key holder are serialized.
XTypes 1.3 §7.6.8 orders the holder’s members by member id, and DDSI-RTPS 2.5 §9.6.3.8 hashes whatever that produces. Two peers that disagree about the order compute two different KeyHashes for one sample, which is the same instance arriving under two handles — a wrong value with nothing on the wire to say so.
§What the implementations do
Measured 2026-08-10 through n3-keyholder/ on the Linux test
host — Cyclone DDS 11.0.1 via dds_stream_extract_keyBE_from_key(…, DDS_CDR_KEY_SERIALIZATION_KEYHASH, …), RTI Connext 7.7.0 via
PRESTypePlugin_interpretedSerializeKeyForKeyhash under all five
encapsulations, Fast DDS via the generated
KeyOrderPubSubType::compute_key. Two types, each declared in the
reverse of its id order, so the KeyHash says which order won:
@final struct KeyOrder { @id(5) @key long b; @id(2) @key long a; }; // b = 2, a = 1
@final struct KeyMixed { @id(5) @key octet b; @id(2) @key long a; }; // b = 2, a = 1KeyOrder KeyHash | KeyMixed KeyHash | |
|---|---|---|
| Cyclone, XCDR1 and XCDR2 | 00000001 00000002 | 00000001 02 |
RTI, XCDR2 (CDR2_BE, D_CDR2_BE, PL_CDR2_BE) | 00000001 00000002 | 00000001 02 |
| Fast DDS, both | 00000001 00000002 | 00000001 02 |
RTI, XCDR1 (CDR_BE, PL_CDR_BE) | 00000002 00000001 | 02000000 00000001 |
— all sixteen bytes wide, zero-extended. So the clause’s order is
what three of the four combinations write, and RTI under encoding
version 1 is the one that keeps declaration order: the same version
split KeyHolderExtensibility and KeyHolderNesting already
carry for RTI, on a third axis.
KeyMixed is the case that shows it is an ordering and not a
coincidence of equal-width members: RTI’s XCDR1 holder is eight
octets, with the octet first and three of padding behind it, and
everyone else’s is five with no padding at all.
Cyclone’s serdata key buffer — dds_stream_extract_key_from_data,
which is not the KeyHash — is in declaration order in both versions.
It is an intermediate: dds_stream_extract_keyBE_from_key reorders
it on the way to the hash, and reading the intermediate as the answer
gives Cyclone a divergence it does not have.
Variants§
AscendingMemberId
Ascending effective member id. The clause, and what three of the four measured combinations write.
Declaration
The order the members are declared in, which is the order the sample carries them in.
RTI Connext 7.7 under XCDR1. Under XCDR2 RTI orders by member id
like everyone else, which is why Dialect::key_holder_order
takes the encoding.
Implementations§
Source§impl KeyHolderOrder
impl KeyHolderOrder
Sourcepub const fn is_default(self) -> bool
pub const fn is_default(self) -> bool
Whether this is the default.