DDS Interoperability Wire Protocol Avatar
  1. OMG Specification

DDS Interoperability Wire Protocol — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSIRTP23-70 InfoTimestamp dates past 2038 DDSI-RTPS 2.2 open
DDSIRTP23-75 Remove/deprecate Property_t, EntityName_t, PID_PROPERTY_LIST DDSI-RTPS 2.2 open
DDSIRTP23-42 Update section 10 (Data Encapsulation) DDSI-RTPS 2.2 open
DDSIRTP23-90 Reorganizing section 9.3.2 DDSI-RTPS 2.2 open
DDSIRTP23-76 Unused ParameterIds in Table 9.12 DDSI-RTPS 2.2 open
DDSIRTP23-74 PIM-PSM inconsistent BuiltInEndpoints DDSI-RTPS 2.2 open
DDSIRTP23-73 resendDataPeriod in StatelessWriter DDSI-RTPS 2.2 open
DDSIRTP23-36 Semantics of AckNack's Final Flag DDSI-RTPS 2.2 open
DDSIRTP23-38 Reference reserved ParameterIDs for DDS-Security and dependencies DDSI-RTPS 2.2 open
DDSIRTP23-41 Link to RTPS VendorId web page is broken DDSI-RTPS 2.2 open
DDSIRTP23-2 Locator_t kind needs a reserved range and a range for vendor extensions DDSI-RTPS 2.2 open
DDSIRTP23-3 Clarify start of alignment for SerializedPayload DDSI-RTPS 2.2 open
DDSIRTP23-37 Incorrect definition of SequenceNumberSet DDSI-RTPS 2.2 open
DDSIRTP23-66 Sending a HeartBeat message when there is no data is unspecified DDSI-RTPS 2.2 open
DDSIRTP23-72 Deprecate PID_PARTICIPANT_BUILTIN_ENDPOINTS DDSI-RTPS 2.2 open
DDSIRTP23-39 RTPS Minor version should take into consideration DDS-Security DDSI-RTPS 2.2 open
DDSIRTP23-71 Include the padded bits into the Encapsulation options DDSI-RTPS 2.2 open
DDSIRTP23-40 Builtin Interparticipant Channel should have DataReader reliability kind BEST_EFFORTS DDSI-RTPS 2.2 open
DDSIRTP23-69 Normative references for IDL and CDR DDSI-RTPS 2.2 open
DDSIRTP23-78 PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO need further description DDSI-RTPS 2.2 open
DDSIRTP23-77 Table 9.13 "reserved for future use" rows DDSI-RTPS 2.2 open

Issues Descriptions

InfoTimestamp dates past 2038

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

    The seconds portion of the Time_t structure used for InfoTimestamp is limited to 32 bits, so it can't represent dates past 2038.

  • Reported: DDSI-RTPS 2.2 — Thu, 14 Dec 2017 23:22 GMT
  • Updated: Wed, 17 Jan 2018 20:12 GMT

Remove/deprecate Property_t, EntityName_t, PID_PROPERTY_LIST

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

    Table 9.4
    Property_t and EntityName_t are unused, so these can be removed without making any actual changes to the protocol

    Table 9.12
    PID_PROPERTY_LIST is unused, remove it from the table

  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:41 GMT
  • Updated: Wed, 17 Jan 2018 02:48 GMT

Update section 10 (Data Encapsulation)

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

    Section 10 was written before there was a good reference for the data representation used by DDS. Now that we have the DDS-XTYPES specification the section should updated to indicate the minimal requirements to comply with RTPS and reference XTYPES for full DDS type interoperability.

    Note that we should not make RTPS depend on XTYPES. The intent is just to clarify where different things are, not to change the things required for compliance.

  • Reported: DDSI-RTPS 2.2 — Thu, 16 Nov 2017 00:01 GMT
  • Updated: Wed, 17 Jan 2018 00:54 GMT

Reorganizing section 9.3.2

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

    Section 9.3.2 largely consists of a single 5-page table (Table 9.4). This creates a usability issue for the spec where important lists of constants (like the BuiltinEndpointSet_t values) need to be found within the huge table instead of directly being referred to by other parts of this spec or other specs (Security).

  • Reported: DDSI-RTPS 2.2 — Fri, 12 Jan 2018 19:49 GMT
  • Updated: Mon, 15 Jan 2018 15:06 GMT

Unused ParameterIds in Table 9.12

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

    The role of Table 9.12 is "...the list of ParameterIds used to encapsulate the data for the built-in Entities" (9.6.2.2.2).

    The following ParameterIds are not used for built-in entities and therefore do not belong in this table: PID_BUILTIN_ENDPOINT_SET, PID_PROPERTY_LIST, PID_TYPE_MAX_SIZE_SERIALIZED, PID_ENTITY_NAME, PID_KEY_HASH, PID_STATUS_INFO (the last six rows). Some of them are already in Table 9.14.

  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:46 GMT
  • Updated: Wed, 10 Jan 2018 21:23 GMT

PIM-PSM inconsistent BuiltInEndpoints

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

    Table 8.73 "availableBuiltinEndpoints" describes the PIM's datatype BuiltinEndpointSet_t using 6 constants (note: change text in this table to indicate that each constant denotes a potential member of the Set not the Set itself). The PIM also maps these constants to EntityId_t values in 8.5.4.2.

    The PSM fails to directly reference these constants for BuiltinEndpointSet_t in Table 9.4.

    PIM PSM notes
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_ANNOUNCER needed?
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_DETECTOR needed?
    PUBLICATIONS_WRITER DISC_BUILTIN_ENDPOINT_PUBLICATION_ANNOUNCER clarify mapping
    PUBLICATIONS_READER DISC_BUILTIN_ENDPOINT_PUBLICATION_DETECTOR clarify mapping
    SUBSCRIPTIONS_WRITER DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_ANNOUNCER clarify mapping
    SUBSCRIPTIONS_READER DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_DETECTOR clarify mapping
    TOPIC_WRITER missing add to PSM
    TOPIC_READER missing add to PSM
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_ANNOUNCER remove?
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_DETECTOR remove?
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_ANNOUNCER remove?
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_DETECTOR remove?
    PSM-only BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_WRITER add to PIM?
    PSM-only BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_READER add to PIM?

    To satisfy the PIM, the PSM must also describe how vendors add extensions to this list. Perhaps the best way to do that is to use a separate vendor-specific PID, but that should be described in the PSM to avoid vendors using reserved bits.

    It would be good if the spec was consistent about naming for the PSM constants. Some start with DISC_ while others don't. Some use the brand new terms "announcer" and "detector", others don't.

  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:34 GMT
  • Updated: Wed, 10 Jan 2018 16:08 GMT

resendDataPeriod in StatelessWriter

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

    resendDataPeriod is listed in Figure 8.15, Table 8.49, and pseudocode 8.4.7.2.1
    The issue is that nothing in the definition of StatelessWriter's behavior (8.4.8) describes how resendDataPeriod is used.

  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:08 GMT
  • Updated: Wed, 10 Jan 2018 15:53 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?

    a. 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.

    b. 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: Sat, 23 Dec 2017 22:54 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, 23 Dec 2017 22:54 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 values less than 0x00008000. 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 between 0x00008000 and 0x0000FFFF (inclusive). 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: Sat, 23 Dec 2017 22:54 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 improved 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: Sat, 23 Dec 2017 22:54 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: Sat, 23 Dec 2017 22:54 GMT

Sending a HeartBeat message when there is no data is unspecified

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

    Sending a HeartBeat message when a writer has no data to announce is unspecified.

  • Reported: DDSI-RTPS 2.2 — Sun, 10 Dec 2017 23:47 GMT
  • Updated: Sat, 23 Dec 2017 22:54 GMT

Deprecate PID_PARTICIPANT_BUILTIN_ENDPOINTS

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

    It seems as though implementations are using PID_BUILTIN_ENDPOINT_SET instead of PID_PARTICIPANT_BUILTIN_ENDPOINTS for the ParticipantProxy::availableBuiltinEndpoints.

    Some implementations accept both, but from the information we have so far, all implementations are sending PID_BUILTIN_ENDPOINT_SET.

    We can add this PID to Table 9.17 as described in DDSIRTP23-48.

  • Reported: DDSI-RTPS 2.2 — Fri, 15 Dec 2017 19:09 GMT
  • Updated: Sat, 23 Dec 2017 22:54 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: Thu, 21 Dec 2017 22:12 GMT

Include the padded bits into the Encapsulation options

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

    Per the resolution of http://issues.omg.org/browse/DDSXTY12-10 the lower 2 bits of the encapsulation options shall be use to encode how many padding bits were added.

    This informations should be added to section 10.2.1.2 and an issue should be added to XTYPES 1.3 to remove it from there.

    Furthermore to avoid confusion/ambiguities we should be explicit about the endianess used to encode the "ushort options".

    Unless this would cause problems to existing implementations I would suggest we either state that the "ushort options" is always serialized using BigEndian or equivalently we change the type to octet[2] instead of "ushort".

    The reason is that the alternative interpretation, namely use the endianness implied by EncapsulationIdentifier is not well defined in all cases. Not all EncapsulationIdentifier kinds explicitly select an Endianness. The ones referenced in RTPS: CDR_BE, CDR_LE, PL_CDR_BE, and PL_CDR_LE that are defined in do. But others, including the "XML" defined in XTYPES do not. So RTPS could not make a general statement about the encoding of the "ushort options" unless the statement is to fix the endianess independent of the EncapsulationIdentifier.

  • Reported: DDSI-RTPS 2.2 — Fri, 15 Dec 2017 10:23 GMT
  • Updated: Wed, 20 Dec 2017 23:57 GMT

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: Wed, 20 Dec 2017 23:44 GMT

Normative references for IDL and CDR

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

    The previous RTF (2.2) had an issue (#7) that cleaned up IDL syntax. A note in the resolution of that issue indicated that RTPS should have a normative for this. Back then, that reference was to formal/11-11-01, a chapter of CORBA. Today we can use IDL 4.1 formal/17-05-07.

    Similarly, the spec is not implementable without knowledge of the CDR encoding. This is defined in formal/12-11-14, chapter 9.

  • Reported: DDSI-RTPS 2.2 — Tue, 12 Dec 2017 16:53 GMT
  • Updated: Wed, 20 Dec 2017 19:13 GMT

PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO need further description

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

    Table 9.14 introduces PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO but they are not described in the subsequent sections.

  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:51 GMT
  • Updated: Mon, 18 Dec 2017 17:51 GMT

Table 9.13 "reserved for future use" rows

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

    The presence of the final three rows of the table with "Reserved for future use" is confusing, why is it in the specification if all (non-vendor-specific) PIDs are effectively reserved?

  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:48 GMT
  • Updated: Mon, 18 Dec 2017 17:48 GMT