${taskforce.name} Avatar
  1. OMG Task Force

DDS Interoperability RTF — Closed Issues

Open Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

The specification does not state how to generate unique GUIDs

  • Legacy Issue Number: 12509
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Niels Kortstee)
  • Summary:

    In RTPS each entity has a so-called GUID_t. It consists of a 12 Byte GuidPrefix_and a 4-Byte EntityId_t and must be globally unique. In heterogeneous systems (with multiple RTPS implementations), the specification provides no mechanism or guidance to ensure global uniqueness.

    A solution would be to make the vendorId part of the GuidPrefix_t.

    Resolution:
    The first two bytes of the GUID_t prefix should be the vendor id.

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    The first two bytes of the GUID_t prefix should be the vendor id, the rest can be
    chosen by the vendors as they see fit, as long as they ensure uniqueness.
    This approach avoids collisions between vendors, but has the drawback that it limits
    the range of available GUID prefixes for each vendor. But as we can see below, this
    limitation should not cause a problem as the remaining 10 Bytes are sufficient to
    generate unique GUIDs even in very large DDS domains.
    The GUID_t prefix is 12 bytes, after 2 are used for the vendor there remain only 10
    bytes that can be used to generate unique DDS Entity GUIDs, this means there can
    be S = 2^80 different GUID prefixes.
    GUID prefixes are assigned in one-to-one correspondence with DDS
    DomainParticipants as all the DDS Entities within a participant share the same GUID
    Prefix.
    Assume that a particular DDS domain has ‘n’ DDS participants, if a good algorithm is
    used to generate GUID prefixes, the probability of a collision P (i.e. two or more
    entities having the same GUID) can be approximated as: P ~ 1 – exp(-(n^2)/(2*S))
    In a very large system with 1 Million DDS Participants the probability of a collision
    would be extremely small: 4e-13
    In a system with 1 Billion (10^9) DDS Participants the probability of a collision would
    be 4e-7 also very small.
    Therefore the solution requiring the first 2 bytes of the GUID_t Prefix to match the
    vendorId will not prevent the generation of unique GUID prefixes.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Update protocol version to 2.1

  • Legacy Issue Number: 12506
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Summary:
    The set of proposed changes necessitates updating the protocol version.
    Resolution:
    Change protocol version from 2.0 to 2.1.

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Change protocol version from 2.0 to 2.1.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Change StatusInfo from SubmessageElement to Parameter

  • Legacy Issue Number: 12505
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Summary:
    The statusInfo field of DATA submessage holds flags relating DDS-level concepts that are interpreted at higher layers than RTPS. Hence, it is not necessary to have statusInfo as an explicit field; rather, it can be included in the inlineQos SubmessageElement.

    Resolution:
    Replace all instances of the statusInfo field of DATA with the new statusInfo inline parameter.

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Replace all instances of the statusInfo field of DATA with the new statusInfo inline parameter.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Computation of KeyHash is unspecified

  • Legacy Issue Number: 12508
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Niels Kortstee)
  • Summary:

    Summary:
    The specification does not describe how the KeyHash is computed from the Key.

    This implicates that key hashes in messages coming from different RTPS implementations can never be interpreted, because one implementation may utilize a different key hash algorithm then the other.

    I would prefer that the hash algorithm becomes part of the specification. RTPS implementations can choose to implement the prescribed algorithm or simply use a zero-valued key.

    Resolution:
    The UDP PIM should mandate that the KeyHash is computed either as the serialized key or else as an MD5 digest, depending on whether the serialize key for the type can exceed the 128 that are used for the KeyHash.

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    The UDP PIM should mandate that the KeyHash is computed either as the serialized key or else as an MD5 digest, depending on whether the serialize key for the type can exceed the 128 that are used for the KeyHash.

    The resolution of this issue depends on the presence of new section 9.6.3.3 titled "Key Hash" added as part of the resolution of issue. 12504. If issue 12504 is resolved in a way that does not add this section, then the resolution proposed here would not be valid.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Properly assign vendor IDs

  • Legacy Issue Number: 12507
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Summary:
    Section 9.4.5.1.1 leaves unspecified the list of vendor IDs
    Resolution:
    Modify section to include a reference to an appendix or table where all the vendor IDs are listed.

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Modify section to specify that vendor ID’s are managed separately from the
    specification and include a link to http://www.omgwiki.org/dds/content/page/ddsrtps-
    vendor-and-product-ids

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Some submessage kinds are logically redundant and not extensible

  • Legacy Issue Number: 12503
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    The submessages required to send Keyed and Unkeyed data are mapped in the PSM as two different submessages (DATA and NOKEY_DATA). These submessages have almost identical content so there is no reason to use two submessages for this. Furthermore having two different submessages at the PSM level and exposing the KeyHash as part of the submessage introduces problems with regards to the implementation and the extensibility of the protocol. For example, future versions of the protocol may want to support keyhashes that are either bigger or smaller than the 16 Bytes used today, and do that in an inter-operable manner without breaking backwards compatibility. They may also want to omit sending a key hash when the size of the key itself is small. As the key is always included as part of the data, sending the KeyHash for small keys is inefficient at best.
    This could be resolved by combining the two PSM submessages and moving the KeyHash into the InlineQos.

    Resolution:
    Combine the DATA and NOKEY_DATA submessages. Also combine the DATA_FRAG and NOKEY_DATA_FRAG. Include additional fields in these submessages to enable extensibility for future submessage-specific options.

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Combine the DATA and NOKEY_DATA submessages. Also combine the DATA_FRAG and NOKEY_DATA_FRAG. Include additional fields in these submessages to enable extensibility for future submessage-specific options

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Change KeyHash from SubmessageElement to Parameter

  • Legacy Issue Number: 12504
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • 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.

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Replace mentioned instances of keyHashPrefix/Suffix with keyHash inline parameter.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Clarify when a Payload is present in a submessage

  • Legacy Issue Number: 12502
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Some submessages can optionally include a payload. For example the DATA submessage includes a payload in most cases, except in some special cases where the submessage indicates unregistration and/or disposal of the data.

    Currently the presence of the payload is tied to the value of the unregister and dispose flags. This is inflexible and also does not support some use-cases where it is desirable to send data with dispose messages. It would be much better to make the presence of the Data Payload separately configurable in the submessage.

    Resolution:
    Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Include key in serialized ParticipantMessageData

  • Legacy Issue Number: 12501
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    The specification states in section 9.6.2.1 that the key portion of ParticipantMessageData is not serialized as part of the DATA submessage. The stated argument is that the key is already part of the DATA submessage. This argument is incorrect, the DATA message may optionally include a KeyHash which is not necessarily the same as the key. Moreover this makes the ParticipantMessageData special in the way it is serialized. The saving in bandwidth consumed do not justify all this "special code". It would be far better if the ParticipantMessageData was treated as any regular data message and the key was serialized along.
    Resolution:
    Change the description in Section 9.6.2.1 to not refrain from serializing the key of ParticipantMessageData.

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Change the description in Section 9.6.2.1 to not refrain from serializing the key of ParticipantMessageData.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Add implementation note on not serializing redundant info in builtin topic

  • Legacy Issue Number: 12500
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Simple discovery data has parameters containing redundant information. To not waste bandwidth, implementations should be able to refrain from sending redundant information. As such, the spec should include an implementation note on this matter.
    Resolution:
    Add text in PSM, Section 9.6.2.2 describing the general allowable case in which implementations may avoid serializing parameters with redundant information.
    Revised Text:
    Add to Section 9.6.2.2, right before section 9.6.2.2.1 the following paragraph::

    For optimization, implementations of the protocol may refrain from include in the Data submessage a parameter if it contains information that is redundant with parameters present in that same Data submessage. As a result of this optimization an implementation can omit the serialization of the parameters listed in - ParameterId subspaces- ParameterId subspaces

    Table 9.1 - ParameterId subspaces
    BuiltinEndpoint Parameter which may be omitted Parameter where the information on the omitted parameter can be found
    SPDPdiscoveredParticipantData ParticipantProxy::guidPrefix ParticipantBuiltinTopicData::key

    DiscoveredReaderData ReaderProxy::remoteReaderGuid SubscriptionBuiltinTopicData::key

    DiscoveredWriterData ReaderProxy::remoteWriterGuid PublicationBuiltinTopicData::key
    .
    For example, an implementation of the protocol sending DATA message containing the SPDPdiscoveredParticipantData may omit the parameter that contains the guidPrefix. If the guidPrefix is not present in the DATA message, the implementation of the protocol in the receiver side must derive this value from the "key" parameter which is always present in the DATA message.

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Add text in PSM, Section 9.6.2.2 describing the general allowable case in which implementations may avoid serializing parameters with redundant information.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Clarify usage of KeyHash

  • Legacy Issue Number: 12499
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Usage of keyHash is currently underspecified. It is not clear whether its presence in the message is mandatory and how it should be processed.
    Resolution:
    Expanded descriptions of the intended usage of keyHash parameter are added.
    Revised Text:
    Insert new Section 8.7.8

    8.7.8 "Key Hash"

    The Key Hash provides a hint for the key that uniquely identifies the data-object that is being changed within the set of objects that have been registered by the RTPS Writer.

    Nominally the key is part of the serialized data of a data submessage. Using the key hash benefits implementations providing a faster alternative than deserializing the full key from the received data-object.

    When the key hash is not received by a DataReader, it should be computed from the data itself. If there is no data in the submessage, then a default zero-valued key hash should be used by the DataReader

    If there is a KeyHash, if present, shall be computed as described in Section 9.6.3.3

  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Expanded descriptions of the intended usage of keyHash parameter are added

  • Updated: Fri, 6 Mar 2015 22:56 GMT