DDS Interoperability Wire Protocol Avatar
  1. OMG Specification

DDS Interoperability Wire Protocol — Open Issues

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

Issues Descriptions


Builtin Interparticipant Channel should have DataReader reliability kind BEST_EFFORTS

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Currently it is RELIABLE. The problem is that this channel is used to send the Liveliness assertions. Being reliable if one is lost, future assertions cannot make it through even if they are written by the DataWriter. Rather it has to wait for the repair packet which depends on timing for HeartBeat and repair which may be longer than the assertion period.

    Since the assertion message is small, it is more efficient to send it faster than rely on faster heartbeats and ACKNACKs.

    This change would be backwards compatible since the DataWriter would still have reliability kind RELIABLE.

  • Reported: DDSI-RTPS 2.2 — Mon, 21 Aug 2017 22:09 GMT
  • Updated: Mon, 21 Aug 2017 22:09 GMT

RTPS Minor version should take into consideration DDS-Security

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The DDS-Security 1.1 specification updated the RTPS minor version to 3. Consequently the result of the RTPS 2.3 RTF should be update the Minor version to 4 (not 3), assuming there are changes to the protocol.

    The section that states the RTPS minor revision should also reference DDS-Security so is clear that that specification may also update the minor versions and future revisions of RTPS take it into consideration.

  • Reported: DDSI-RTPS 2.2 — Sat, 8 Jul 2017 00:15 GMT
  • Updated: Sat, 8 Jul 2017 00:15 GMT

Reference reserved ParameterIDs for DDS-Security and dependencies

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The DDS-Security specification reserved a range of parameter IDs. Specifically section 7.4.1.3 (Reserved RTPS parameter IDs) of DDS-Security 1.1 states:

    This specification reserves the RTPS Simple Discovery Protocol ParameterIDs in the range: 0x1000 to 0x1FFF and 0x5000 to 0x5FFF.
    The second interval covers the same range of parametersID, except they have the must-understand bit set.
    This reserved range applies to RTPS version 2.3 (see 7.3.6.1) and higher minor revisions of RTPS. Future revisions of the DDS-RTPS specification shall take into consideration this fact.

    This reserved range should be included into the RTPS specification itself and a reference to DDS-Security so future revisions of RTPS can respect this reservation.

  • Reported: DDSI-RTPS 2.2 — Sat, 8 Jul 2017 00:12 GMT
  • Updated: Sat, 8 Jul 2017 00:12 GMT

Incorrect definition of SequenceNumberSet

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 9.4.2.6 (SequenceNumberSet)

    Specifies that

    A valid SequenceNumberSet must satisfy the following conditions:
    • bitmapBase >= 1
    • 0 < numBits <= 256
    • there are M=(numBits+31)/32 longs containing the pertinent bits

    This is seems like an error in how the spec is worded.
    What it was trying to say is that for the bitset to represent a set f bits then it must be that 0 < numBits <= 256

    However the case with numBits=0 is still valid. It represents an empty set, but the bitmapBase still carries information since. This is use by the ACKNAK sub-message to acknowledges al sequence numbers less or equal to bitmapBase without Nacking anything.

  • Reported: DDSI-RTPS 2.2 — Wed, 30 Mar 2016 20:21 GMT
  • Updated: Wed, 30 Mar 2016 20:21 GMT

Semantics of AckNack's Final Flag

  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Users found that OpenDDS and CoreDX did not interoperate due to different interpretations of the Final Flag in AckNack.

    The use of FinalFlag in Heartbeat is pretty clear, but its extension to AckNack seems to be under-specified.

    This section tells us little:

    The FinalFlag indicates whether a response by the Writer is expected by the Reader or if the decision is left to the Writer. The use of this flag is described in 8.4.

    That last sentence is unhelpful as section 8.4 takes up about 60 pages. Searching through 8.4 results in very little about the AckNack's Final Flag.

    The key question is what is meant by "response by the Writer". Considering AckNacks that are both Final and have at least one "1" bit in the bitmap, is the Writer obligated to send the nacked DATA?

    One interpretation is that the Final Flag is a simple (constant-time) indication that the Writer need not resend DATA even with a "1" in the bitmap – in this scenario the Writer need not even read the bitmap. The AckNack is still useful because the bitmapBase can bump up the acknowledge sequence number.

    The other interpretation is that the presence of a "1" in the bitmap overrides the Final flag and the Writer must reply with DATA. In this interpretation the Final flag is used to indicate whether or not another HEARTBEAT is sent "soon" (instead of waiting for periodic heartbeat), but has no impact on sending DATA.

  • Reported: DDSI-RTPS 2.2 — Wed, 27 Jan 2016 16:06 GMT
  • Updated: Wed, 27 Jan 2016 16:06 GMT

Clarify start of alignment for SerializedPayload

  • Legacy Issue Number: 19660
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 9.4.2.12 should clearly state where the alignment begins. Is it before the encapsulation header or after the encapsulation header?

    Note that 9.4.2.11 already talks about it for the ParameterList encapsulation so 9.4.2.12 should use the same approach.

    The language in 9.4.2.11 should also be improve to make it less ambiguous, specifically stating that the reset of the alignment occurs after the parameterID before the parameter data is serialized.

  • Reported: DDSI-RTPS 2.2 — Mon, 24 Nov 2014 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:55 GMT

Locator_t kind needs a reserved range and a range for vendor extensions

  • Legacy Issue Number: 19694
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The Locator_t contains an integer field that identifies the type of locator. Currently only the values -1, 0, 1, 2 are defined. Which correspond to reserved values as well as UDPv4 and UDPv6.

    Future revisions of the protocol may define additional kinds for things like TCP v4, TCPv6, shared memory and other transports.

    At the same time vendors are using this field to identify their own custom transports.

    To avoid collisions with future revisions of the protocol, the RTPS specification should reserve a range. For example, all kinds with value less than 0x01000000. These values should be reserved for future revisions of the protocol. Vendors that want to define their custom transport should use Locator_t kind with values 0x01000000. And these values should be interpreted in the context of the RTPS vendorId so that different vendors can use the same value to mean different things.

  • Reported: DDSI-RTPS 2.2 — Thu, 18 Dec 2014 05:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT