DDS-XTypes 1.0b2 FTF Avatar
  1. OMG Issue

DDSXTY — DDS-XTypes @Key annotation Issue

  • Key: DDSXTY-28
  • Legacy Issue Number: 16007
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    The @key annotation is currently defined as:

    local interface Key

    { attribute boolean value default true; }


    Now suppose I have the following topic type:

    struct ATopicType

    { string a; @Key @ID(20) long b; long c; @Key @ID(10) }


    What is the key (a,b) or (b,a)? What if there were no annotations?

    The order of the key should be formally defined by the spec as this has an impact, among other things, on the computation of the keyhash.

    The rule could be as simple as taking the key element in the same order of the attribute ID. The other option is to extend the key to support a value, yet I think the first alternative is more orthogonal.

  • Reported: DDS-XTypes 1.0b1 — Wed, 2 Feb 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    The key hash is currently calculated in the following way, according to the DDS-RTPS specification:
    1. Serialize the key members…
    a. …in their declaration order
    b. …in big-endian CDR format
    2. If the serialization is less than or equal to 128 bits, that is the key hash.
    3. Otherwise, apply an MD5 hash to reduce the result to 128 bits.
    Update step (1a) above such that key fields are always serialized in ascending order by member ID rather than by declaration order. Note that this change applies only when calculating the key hash, not at any other time.
    This change is backwards compatible with pre-XTypes DDS implementations, because legacy type definitions will lack @ID annotations, and hence all members will always be in ascending ID order.

  • Updated: Fri, 6 Mar 2015 20:58 GMT