DDSI-RTPS 2.3 RTF Avatar
  1. OMG Issue


  • Key: DDSIRTP23-28
  • Legacy Issue Number: 15912
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    In section 8.7.9 of the DDSI/RTPS v2.1 protocol is described the KeyHash sub-message-element representing the MD5 hash of the key for the Data sub-message to which it belongs.

    The specification does not mandate the use of the KeyHash all keyed topics – implementations are free to include it or not. However, if implementations are not including the KeyHash the only way to get a clue on the Topic Instance to which the received samples belongs is to de-serialize the payload.

    This leads two at least two problems, (1) DDSI/RTPS routers are forced to de-serialize the data payload even if no content transformation have to be performed and (2) DDS Implementations are forced to deserialize eagerly in order to manage instances, thus preventing DDS implementations to do lazy deserialization (which is now possible with the API provided by the new C++/Java PSM).

    The suggested resolution is to require that Data SubMessage for keyed topic shall always include the KeyHash submessage element.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 5 Jan 2011 05:00 GMT
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    No immediate need to require sending the Keyhash with each sample

    The RTF does not see an immediate need to add the proposed functionality to the specification.

  • Updated: Wed, 19 Dec 2018 16:38 GMT