DDS Interoperability Wire Protocol Avatar
  1. OMG Specification

DDS Interoperability Wire Protocol — Open Issues

  • Acronym: DDSI-RTPS
  • Issues Count: 4
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Referencing current version of DDS spec (was: Clarification of link comment)

  • Legacy Issue Number: 19237
  • Status: open  
  • Source: gmail.com ( James Pope)
  • Summary:

    Please excuse my learning curve here.

    Section 6.1 says that this formal is a supplement to Version 1.1 formal, However there is now a version 1.2. That MIGHT suggest that aspects of 1.2 is not within interoperability to this specification. and that this one is interoperable to 1.1. Which I understand is across major versions and not a mandate.

    Anyway Please clareify.
    Is there a document that has version differences overview. If so a reference to that would be value added as well.

  • Reported: DDSI-RTPS 2.1 — Tue, 11 Feb 2014 05:00 GMT
  • Updated: Wed, 15 Nov 2017 22:11 GMT

RTF needs to agree any change of name and/or URL for specification

  • Legacy Issue Number: 15885
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The DDS interoperability protocol is also referred to as RTPS. OMG staff have received conflicting suggestions for the short name of the protocol (RTPS vs. DDSI). This short name determines (amongst other things) the URL by which the mist recent version of the specification is always accessible.

    The RTF must decide what short name to use for this specification.

  • Reported: DDSI-RTPS 2.1 — Thu, 9 Dec 2010 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:13 GMT

Message Size should be included as part of DDSI/RTPS Messages

  • Legacy Issue Number: 17286
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    The DDSI/RTPS wire protocol currently expects the transport to provide the size for the message – said in other terms, the current version of the protocol can only work with message oriented transports, such as UDP/IP.

    This assumptions should be dropped in order to enable the use of DDSI/RTPS over stream oriented transports such as TCP/IP.

    One possible approach to overcome this limitation w/o breaking backward compatibility with other implementation is to add a new sub-message element, say MESSAGE_LEN structured as follows:

    --------------------------+

    ID Flags octect2NextSME

    --------------------------+

    Message Length

    -----------------------------------

    In addition, for efficient parsing, if the sub-message above, when used, should be always placed right after the RTPS header.

  • Reported: DDSI-RTPS 2.1 — Fri, 30 Mar 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

The Writer Liveliness Protocol should be removed

  • Legacy Issue Number: 17285
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    The DDSI v2.1 specification describes in section 8.4.13 the Writer Liveliness Protocol as the mechanism used by participants to assess the liveliness of their contained data writers (with automatic liveliness).

    The Writer Liveliness Protocol is specified as mandatory for compliant implementations.

    The first remark is that the Writer Liveliness Protocol is not required at all for interoperability, thus it should not be a mandatory requirement for compliant implementation. This is not only easy to reason about, but wireshark captures made during the DDS interoperability demo of the past March 2012 showed how different DDS implementations could work w/o using this protocol.

    Beyond that, the protocol is simply superfluous as DataWriter liveliness can be anyway asserted via the Participant Liveliness, this in turns is asserted by the participant discovery protocol.

    Beyond the potential waste of resource required by yet another periodic information flow, what seems very odd is the choices of QoS for the built-in entities that write this periodic message. As described in section 8.4.13.3 these built-int entities communicate reliably and have a history set to KeepLast(1), along with TransientLocal durability.

    This QoS settings only "works" best for those implementations that tie the reliability send queue to the writer history but is less than ideal for those that rightfully decouple history and reliability.

    Anyway, however one looks at it this part of the specs seems bogus. In addition as mentioned above is not required for interoperability and generates yet another stream of periodic messages.

    The recommendation is to remove this section from the next version of the standard.

  • Reported: DDSI-RTPS 2.1 — Thu, 29 Mar 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT