DDS Interoperability Wire Protocol Avatar
  1. OMG Specification

DDS Interoperability Wire Protocol — Closed Issues

  • Acronym: DDSI-RTPS
  • Issues Count: 141
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSIRTP25-34 Change the CRC-64 polynomial introduced in issue DDSIRTP25-12 DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-4 Unclear specification on how the Publisher GUID is communicated DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Duplicate or Merged closed
DDSIRTP25-3 Incomplete specification of how a Publisher and Subscriber are identified DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-2 Discriminating the reasons for a GAP DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-12 Address deferred issue: Inclusion of Message Size & CRC as part of DDSI/RTPS Messages DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-17 Editorial corrections DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-25 Revise list of Submessages EntityIDs and PIDs reserved for other specifications DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-28 Apply modifications to Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)" from XTYPES DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-9 Flag GroupInfoFlag and fields gapStartGSN and gapEndGSN unspecified in PSM DDSI-RTPS 2.3 DDSI-RTPS 2.5 Duplicate or Merged closed
DDSIRTP25-1 SEQUENCENUMBER_UNKNOWN missing from PSM DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-27 Support transport-level RTPS message compression DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Deferred closed
DDSIRTP25-24 Add an INFO_AGE submessage DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Duplicate or Merged closed
DDSIRTP25-6 Update Acknowledgemts, Copyright and Statement of Proof DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-11 currentGSN.value < lastGSN.value condition seems wrong DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-10 8.3.7.5 / 9.4.5.6 HeartBeat Submessage DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-7 PSM and PIM description of Gap message not matching DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-13 Interoperability of Transient/Persistent data DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Deferred closed
DDSIRTP23-26 How should interoperable implementations deal with Transient / Persistent data? DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Deferred closed
DDSIRTP23-6 Message Size should be included as part of DDSI/RTPS Messages DDSI-RTPS 2.1 DDSI-RTPS 2.3 Deferred closed
DDSIRTP23-78 PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO need further description DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-29 How should interoperable implementations deal with Group Coherent updates DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-30 RTF needs to agree any change of name and/or URL for specification DDSI-RTPS 2.1 DDSI-RTPS 2.3 Deferred closed
DDSIRTP23-31 GAP lack information on related (instance/key) needed for correct DDS behavior DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-23 Editing issues DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-3 Clarify start of alignment for SerializedPayload DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-119 Make sure all references to the RTPS version are updated to 2.4 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-40 Builtin Interparticipant Channel should have DataReader reliability kind BEST_EFFORTS DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-118 DomainId should propagated in the ParticipantBuiltinTopicData DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-42 Update section 10 (Data Encapsulation) DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-113 Describe how to create a WITH_KEY or NO_KEY RTPS Endpoint from DDS DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-115 Reference the PIDs that are reserved by the XTypes Spec in RTPS DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-96 Update UML figures in the specification DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-110 Data/Frag submessage flag for security DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-76 Unused ParameterIds in Table 9.12 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-108 Update state machine to allow retrieving inline qos from a CacheChange DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-101 Typo in 8.4.13 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-104 Figure 8.29 duplicates 8.28 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-103 Inconsistent definitions of ParticipantMessageData DDSI-RTPS 2.2 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-24 Key attributes and Regular attributes of a topic should be individually de-serializable DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-28 DDSI/RTPS Key MD5 Hash DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-20 Section 8.4.9.1.4: Best-Effort Stateful Writer GAP semantics DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-22 Section 8.4.7.3, Table 8.52: Describe ReaderLocator operations' semantics DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-25 Use the term "Encapsulation" consistently and precisely DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-27 Remove the concept of Topic Kinds (With Key vs. No Key) DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-32 Incorrect/misleading description of KeyHash computation DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-77 Table 9.13 "reserved for future use" rows DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-90 Reorganizing section 9.3.2 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-37 Incorrect definition of SequenceNumberSet DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-36 Semantics of AckNack's Final Flag DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-39 RTPS Minor version should take into consideration DDS-Security DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-38 Reference reserved ParameterIDs for DDS-Security and dependencies DDSI-RTPS 2.2 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-97 Figure 8.1 has extra classes. Figures 8.2 and 8.5 are missing attributes DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-75 Remove/deprecate Property_t, EntityName_t, PID_PROPERTY_LIST DDSI-RTPS 2.2 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-74 PIM-PSM inconsistent BuiltInEndpoints DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-73 resendDataPeriod in StatelessWriter DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-72 Deprecate PID_PARTICIPANT_BUILTIN_ENDPOINTS DDSI-RTPS 2.2 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-71 Include the padded bits into the Encapsulation options DDSI-RTPS 2.2 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-70 InfoTimestamp dates past 2038 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-69 Normative references for IDL and CDR DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-100 BestEffort StatefulReader behavior does not handle GAP DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-19 Section 8.4.14.1.1, Bullet 3: Put precise bounds on the fragment size DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-21 Section 8.4.8.1.4: When does Best-Effort Stateless Writer send a GAP DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-5 Referencing current version of DDS spec (was: Clarification of link comment) DDSI-RTPS 2.1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-7 The Writer Liveliness Protocol should be removed DDSI-RTPS 2.1 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-8 Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for RTPS fields DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-9 Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for DDS fields DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-10 Section: 9.6.2.2.2, Table 9.12: Duration_t not defined by PSM DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-11 Section 9.6.2.2.2, Table 9.12: Specify IPv4Address_t and Port_t DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-15 Section 9.6.2.2: What is the "key" parameter? DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-12 Section 9.6.2.2: Describe key-only encoding of built-in data types DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-14 Section 9.6.2.2: Duration_t used in IDL, not defined DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-16 Section 8.7.6: RTPS support for semantics not present in DDS DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-13 Section 8.5.3.2, Table 8.73: Make defaultUnicastLocatorList optional DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-17 Section: 8.5.3.2, Figure 8.27 and Table 8.73 DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Closed; Out Of Scope closed
DDSIRTP23-18 Section 8.4.15.7: Scope of the count fields of Heartbeat and AckNack/NackFrag DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-2 Locator_t kind needs a reserved range and a range for vendor extensions DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-4 Some constants specified in PSM table 9.4 conflict with the ones used in wireshark DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-66 Sending a HeartBeat message when there is no data is unspecified DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-41 Link to RTPS VendorId web page is broken DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-1 Rename BuiltinEndpointKind and add description DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP21-12 The specification does not state how to generate unique GUIDs DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-9 Update protocol version to 2.1 DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-8 Change StatusInfo from SubmessageElement to Parameter DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-11 Computation of KeyHash is unspecified DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-10 Properly assign vendor IDs DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-6 Some submessage kinds are logically redundant and not extensible DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-7 Change KeyHash from SubmessageElement to Parameter DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-5 Clarify when a Payload is present in a submessage DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-4 Include key in serialized ParticipantMessageData DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-3 Add implementation note on not serializing redundant info in builtin topic DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-2 Clarify usage of KeyHash DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP2-28 Add Parameter ID for Original Writer Info DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-27 Add Max Sample Size Serialized Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-5 Clarify Writer liveliness mechanism DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-4 Change structure of (Nokey)DataFrag DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-7 Add SerializedDataFragment as Submessage Element DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-6 Version number should be 2.0 DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-3 Remove length field in encapsulation chapter DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-2 Provide default timing parameters DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-25 DDS DURABILITY Persistent QoS DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-24 ChangeKind Has DDS Relationship DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-23 Clarify GAP usage DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-26 TOPICNAME parameter appears in PSM but not in PIM DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-22 Elaborate on Necessity and Usage of In-line QoS DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-21 Clarify Data Encapsulation Schemes DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-12 Clarify implementing Count submessage element DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-11 Reclaiming finite resources from inactive readers DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-17 Supporting Inline QoS by Stateful Readers DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-16 Add Directed Write Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-9 Clarify interoperability requirement 8.4.2.3.3 DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-8 Clarify interoperability requirement 8.4.2.3.4 DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-15 Interpreting Liveliness Heartbeats DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-14 Clarify Writer Response to ACKNACK DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-20 Add Max Sample Size Serialized Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-19 Add Property List Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-10 Define default multicast Reader behavior DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-13 Reader-side Heartbeat response suppression DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-18 Add Entity Name Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP22-24 Section: 10.1.1.2, 10.1.1.3 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-17 Section: 9.3.2, Table 9.4 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-16 Section: 9.3.1.3, Table 9.2 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-19 Section: 9.4.5.1.3, Paragraph 3 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-18 Section: 9.4.2.6 and 9.4.2.8 (last lines of each section) DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-20 Section: 9.6.3.3 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-13 Section: 8.7.7 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-12 Section: 8.4.1.1, Item 16 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-22 Section: 10.1.1.1 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-21 Section: 10.1 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-14 Section: 8.7.8 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-23 Section: 10.1.1.1 and 10.1.1.2 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-11 Section: 8.4.1.1, Figure 8.14 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-15 Section: 9.3.1.2 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-7 Use compliant OMG IDL syntax DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-6 Typographical errors DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-5 Add Entity Name Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-4 Interpreting Liveliness Heartbeats DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-3 Reader-side Heartbeat response suppression DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-2 Clarify interoperability requirement 8.4.2.3.3 DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-10 Section: 8.3.7.3.5 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-9 Section: 8.3.5.8 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-8 Section: 8.2.1.2, Table 8.2, Locator_t row DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed

Issues Descriptions

Change the CRC-64 polynomial introduced in issue DDSIRTP25-12

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

    The CRC-64 polynomial selected in DDSIRTP25-12 (a.k.a. CRC-64-iso) has issues that make it inadequate for this specification:

    • The "only" formal reference is ISO 3309 which has been "withdrawn". The ISO 3309 page (https://www.iso.org/standard/8561.html) says it has been revised by ISO/IEC 13239:2002. However ISO/IEC 13239 does not mention CRC 64 at all. Moreover the later versions of the (withdrawn) ISO 3309, for example ISO-IEC-3309:1993 only mention CRC-32 polynomials, no CRC-64 polynomials.
    • It seems to have fallen out of use: The two references that Wikipedia says use this polynomial (Swiss-Prot/TrEMBL) and HDCL seems to no longer use the CRC64-ISO polynomial:
      1. Swiss-Prot/TrEMBL has changed to a different CRC-64 polynomial (see https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.368.2736&rep=rep1&type=pdf).

    2. HDLC is defined in the ISO/IEC 13239 and it does not define CRC 64 bit polynomials.

    Because of this the polynomial should be changes to the so called CRC-64-ECMA which as a specification that is not deprecated https://www.ecma-international.org/publications/standards/Ecma-182.htm. This polynomial is used in other relates specifications such as AUTOSAR: AUTOSAR 4.3 added CRC-64 with the ECMA polynomial (https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_CRCLibrary.pdf).

    Moreover specifying the polynomial coefficients is not enough to fully specify the checksum. Instead there are additional rules about padding etc. For this reason the specification should be amended to include all the additional information.

  • Reported: DDSI-RTPS 2.3b1 — Tue, 9 Feb 2021 13:38 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Replace the CRC-64 polynomial with the CRC-64/XZ checksum polynomial

    Amend the resolution of DDSIRTP25-12 replacing the CRC-64 checksum polynomial and description with one that used the so called CRC-64/XZ checksum as utilized in AUTOSAR Classic Platform release R20-11, Specification of CRC Routines.

    Expand the description of the CRC-32 and CRC-64 algorithms to define all the parameters needed to uniquely compute and validate the checksum, including the polynomial coefficients, whether the input data and output data are reflected, the initial value and the final XOR value.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Unclear specification on how the Publisher GUID is communicated

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

    The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

    It seems that this is related to PID_GROUP_GUID.
    But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

    The relationship between this should be clarified.
    Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

    Minimally we should say that:

    A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

    The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:57 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.5
  • Disposition Summary:

    Duplicates DDSIRTP25-3

    Duplicates DDSIRTP25-3

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Incomplete specification of how a Publisher and Subscriber are identified

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

    The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

    It seems that this is related to PID_GROUP_GUID.
    But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

    The relationship between this should be clarified.
    Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

    Minimally we should say that:

    A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

    The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:56 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add information on the identification of Publisher and Subscriber

    Indicate that the Publisher and Subscriber are identified by a GUID and that the GUID is propagated via the Publication and Subscription builtin Topic data.

  • Updated: Tue, 29 Jun 2021 12:54 GMT
  • Attachments:

Discriminating the reasons for a GAP

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

    The GAP message indicates a gap in sequence numbers that is "not available" to the DataReader. It may be caused by filters (time, content), history keep last, or lifespan.

    In some cases the reason behind the gap is important to the receiving application. For example a missing sequence number caused by a writer-side content filter does not invalidate a coherent change. However if the gap is caused by keep-last history the coherent change must be discarded by the subscriber/reader.

    Currently there is no way for the receiving application to tell the difference.

    There may be also other situations where it may be desirable to account for the different reasons that cause a gap. For example if the reader maintains a "sample lost count" it needs some way to distinguish sample loss from things it it chose to not receive.

    The RTF should address this issue and provide the means to discriminate these cases. A possible approach would be include the information in the flags of the GAP message.

  • Reported: DDSI-RTPS 2.3b1 — Thu, 28 Feb 2019 02:41 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Extend GAP submesage to provide information about the reasons for the samples gapped

    Extend the GAP message with optional counters to indicate the numbers of samples that are gapped that fall into one of 3 categories:

    • Non-relevant Samples
    • Relevant Samples
    • Unclassified Samples

    Non-relevant samples are those that are intentionally not sent to the DataReader because they do not match some reader-specified criteria. These include samples filtered dues to a content-filtered topic, samples filtered due to a time-based filter, samples directed to other data readers, etc.
    Non-relevant samples are not considered “lost” and do not invalidate coherent changes.

    Relevant samples are those that should have been received by the DataReader but are not received due to various reasons. They include samples that are lost by the transport when using BEST_EFFORT datawriters, samples replaced in the DataWriter cache due to a HISTORY kind KEEP_LAST, samples removed from the DataWriter cache due to LIFESPAN, etc.
    Relevant samples are considered “lost”. They are counted as such and invalidate coherent changes.

    Unclassified samples are those that are not accounted for by the above two categories. This may be because the DataWriter cannot determine or does not keep track of the reason some sequence numbers are missing for a DataReader.
    Unclassified samples are treated the same way we treat the samples missing dues to GAPs or HEARTBEATs in previous versions of the specification. That way the behavior is backwards compatible.

    The updated GAP message would should like this:

    0...2...........7...............15.............23...............31
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   GAP      	|X|X|X|X|N|R|G|E| 	octetsToNextHeader      |
    +---------------+---------------+---------------+---------------+
    |        EntityId          	readerId                        |
    +---------------+---------------+---------------+---------------+
    |        EntityId          	writerId                        |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    +        SequenceNumber    	gapStart                        +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~        SequenceNumberSet	gapList                         ~
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    +        SequenceNumber    	gapStartGSN  [ only if G==1 ]   +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~        SequenceNumber    	gapEndGSN    [ only if G==1 ]   ~
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    +        ChangeCount             relevantCount      [if R==1]   +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    +        ChangeCount             nonRelevantCount   [if N==1]   +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    

    Where the 'R' and 'N' are new flags and the added SequenceNumberCount sub-message elements are 64 bit counter encoded the same way as a sequence number:

    +---------------+---------------+---------------+---------------+
    |                      int32      low                           |
    +   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   +
    |                      int32      high                          |
    +---------------+---------------+---------------+---------------+
    

    If R==0, relevantCount shall be set to zero.
    If N==0, nonRelevantCont shall be set to zero.

    The number or unclassified samples shall be set by the formula:

    
    unclassifiedCount  = (gapList.bitmapBase - gapStart) + gapList.numBits
                      -(relevantCount + nonRelevantCount)
    

    In other words, any samples that appear as part of the GAP but are not covered by the relevant count and the irrelevant count.

  • Updated: Tue, 29 Jun 2021 12:54 GMT
  • Attachments:

Address deferred issue: Inclusion of Message Size & CRC as part of DDSI/RTPS Messages

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

    The following issue https://issues.omg.org/browse/DDSIRTP23-6 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.

    For details on the previous discussion and what was proposed as a resolution see DDSIRTP23-6.

    Overall Approach
    -----------------------
    Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

    • messageLength

    The messageLength indicates the length of the RTPS message
    The rtpsSendTimestamp indicates the time when the message was sent
    The messageChecksum

    Mechanisms to add additional information in future revisions.

    The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header

    The DDS Security specification will leave this RTPSHeaderExtension following the RTPS Header and before the SecureRTPSPrefixSubMsg. The length will be updated to the new length after processing by the security plugins.

  • Reported: DDSI-RTPS 2.3b1 — Fri, 20 Mar 2020 20:07 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add CRC support via a HeaderExtension submessage

    Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

    • rtpsMsgLength (indicates the length of the RTPS message)
    • rtpsPort (destination port for submessage)
    • rtpsChecksum (message checksum)

    The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header.

  • Updated: Tue, 29 Jun 2021 12:54 GMT
  • Attachments:

Editorial corrections

  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    7.6 enumerated list 5th bullet

    • The transport will drop m essages if incomplete or corrupted during transfer

    -> messages



    8.2.4

    Table 8.6 - RTPS Entity Attribues

    -> Attributes



    8.2.6

    Table 8.9 - RTPS Endpoint configuration attribues

    -> attributes



    8.3.7.2.5 'Logical Interpretation' enumerated list 1st bullet (8.3.8.2.5 after revisions to the spec)

    • If the DataFlag [...], the serializedPayload element is interpreted as
      the value of the dtat- object.

    -> data-object



    8.3.7.9.2 'Content' (8.3.8.10.2 after revisions) Table 8.42 (8.48 after revisions) 2nd row 3rd column (meaning)

    Indicates the protocol used for subsequent Sudmessages.

    -> Submessages



    8.4.2.3.2 'Readers must respond eventually after receiving a HEARTBEAT that indicates a sample is missing' 1st para 2nd sentence

    This requirement only applies if the Reader
    can accomodate these missing samples in its cache [...]

    -> accommodate



    Replace "bandwith" with "bandwidth" in section 8.4.2, and 8.7.2.2.4 (2 times total).



    8.6.2 enumerated list 3rd bullet

    * The meaning of submessageIds cannot be modfied.

    -> modified



    8.7.2.2.4 1st sentence

    Implementations may optimize bandwith usage by applying a time-based filter on the Writer side.

    -> bandwidth



    8.7.4 4th para 1st sentence

    When RTPS sends a Data Submessge to communicate instance state changes it may include only the Key of

    -> Submessage



    8.7.4 6th para numbered list

    1. If the previous update to the instance passed the filter, [...]
    that either includes the data value, or else indicates the IntanceState is ALIVE_FILTERED.

    -> InstanceState



    8.7.9 3rd para

    The RTPS protocol suports this forwarding of messages by including information of the original writer.

    -> supports



    9.1 enumerated list 4th bullet

    • [...]; this allows multiple RTPS endpoints to
      share a single operat- ing-system UDP resource (socket/port) while

    -> operating system



    9.3.1.2 Mapping of the EntityId_t

    typedef octet OctetArray3[3]; struct {
    OctetArray3 entityKey; octet entityKind;
    };
    

    -->

    typedef octet OctetArray3[3]; 
    struct EntityId_t {
        OctetArray3 entityKey; 
        octet entityKind;
    };
    



    9.4.5.7.1 Flags in the Submessage Header

    Reference to (8.3.6.2).

    -> 8.3.8.6.2



    9.4.5.15.1

    The MulticastFlag is [...]. M=1 means the InfoReplyIp4 also includes a
    multicastRLocator.

    -> multicastLocator



    9.6.2.3 1st sentence

    The port number expresssions use the following parameters:

    -> expressions



    9.6.4.9, 7th para

    The DisposeedFlag is represented with the literal 'D.'

    -> DisposedFlag

  • Reported: DDSI-RTPS 2.3 — Tue, 21 Apr 2020 08:05 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Apply the typo corrections specified in the issue description

    Perform the suggested corrections.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Revise list of Submessages EntityIDs and PIDs reserved for other specifications

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

    It seems that some ranges reserved by other specifications (e.g. XTypes type service) are missing from RTPS. They should be added:

    9.4.5.1.1.1 for SubmessageIDs
    to 9.3.1.3.1 for the EntityIDs
    Table 9.12 for ParameterIDs

    Maybe always list the same set of specs: DDS Security, XTypes, DDS-RPC? and indicate explicitly if a specification does not reserve anything.

    Also figure out whether new builtin endooints show up under the "availableBuiltinEndpoints" see Table 8.73 also the IDL in 9.3.2
    Right now there is a comment in the IDL that says:

    /* Bits 12-15 have been reserved by the DDS-Xtypes 1.2 Specification
    and future revisions thereof.
    Bits 16-27 have been reserved by the DDS-Security 1.1 Specification
    and future revisions thereof.
    */

    Maybe this needs ti be more explicit and get its own section.

  • Reported: DDSI-RTPS 2.3b1 — Wed, 24 Jun 2020 19:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Be more explicit about submessageID, PatameterIDs and EndpointIDs reserved by other DDS specifications

    Create a new subsection to describe the reserved bits in the availableBuiltinEndpoints.

    Add information to section 9.3.1.3.1 'EntityIds Reserved by other Specifications' to include the endpoints reserved by XTYPES

    Add a new subsection under 9.3.2 'Mapping of the Types that Appear Within Submessages or Built-in Topic Data' to fully describe the content of the 9.3.2.12 BuiltinEndpointSet_t

    Create new subsection before 9.6.5 'ParameterIds Deprecated by the Protocol' to define parameter IDs reserved by other specifications.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Apply modifications to Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)" from XTYPES

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

    XTYPE 1.3, section 7.6.8 "Interoperability of Keyed Topics" provided amended text for Clause 9.6.3.8 in the RTPS spec. This text should be applied to the RTPS spec.

  • Reported: DDSI-RTPS 2.3b1 — Tue, 8 Dec 2020 15:52 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Replace the text in 9.6.4.8 'KeyHash (PID_KEY_HASH)'

    Replace the text in 9.6.4.8 KeyHash (PID_KEY_HASH) with the one provides in DDS-XTYPES 1.3, section 7.6.8 "Interoperability of Keyed Topics" p

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Flag GroupInfoFlag and fields gapStartGSN and gapEndGSN unspecified in PSM

  • Status: closed  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the message module, the submessage gap defines the flag GroupInfoFlag and the fields gapStartGSN and gapEndGSN. However, in the PSM, both this flag and the two fileds are not specified further.

  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 12:28 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.5
  • Disposition Summary:

    Duplicates DDSIRTP25-7

    Merged with DDSIRTP25-7

  • Updated: Tue, 29 Jun 2021 12:54 GMT

SEQUENCENUMBER_UNKNOWN missing from PSM

  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    The previous version of the spec (formal/14-09-01) contained the following in Table 9.4
    #define SEQUENCENUMBER_UNKNOWN {-1, 0}
    However, the equivalent definition is missing in the 2018 "Beta" spec.

  • Reported: DDSI-RTPS 2.3b1 — Tue, 22 Jan 2019 18:12 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add SEQUENCENUMBER_UNKNOWN

    Add specification for SEQUENCENUMBER_UNKNOWN with definition matching previous versions of the protocol (high = -1, low = 0)

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Support transport-level RTPS message compression

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

    Some transports have limited bandwidth and may benefit from compressing the RTPS message prior to being sent over the transport.

    This is something that could be added in a reasonably simple manner by considering this part of the transport PSM.

  • Reported: DDSI-RTPS 2.3b1 — Mon, 14 Sep 2020 15:06 GMT
  • Disposition: Deferred — DDSI-RTPS 2.5
  • Disposition Summary:

    Defer to the next RTF.

    Defer to the next RTF.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Add an INFO_AGE submessage

  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Ornulf Staff)
  • Summary:

    The INFO_AGE submessage is semantically similar to INFO_TS, but it contains a Duration_t instead of a Time_t. It assigns a time to subsequent submessages that the service may use for functionality like lifespan and sample ordering.

    Transmitting a sample age gives the receiver an inexact timestamp. There will be an unknown time span between the time the sender calculates the age and the time the receiver transforms it back to a local time. If the receiver does no adjustment based on estimated latency, the calculated time will always be too high. However, the error will in practice be bounded and in many scenarios the receiver will have a time that is within one second of the actual sample time.

    Kongsberg uses a submessage like this today for deployments where no correct time source is available. This might be because the system has to be fully operational before a good time source is ready, or because some systems have requirements that mandate that the system clock must be adjustable. We have found that this is a better solution than attempting to have some form of synchronized "DDS time" on the network, because coming up with a network time that works very quickly at startup and is robust to network fragmentation is challenging.

    The use of the INFO_AGE message is enabled by a vendor specific configuration option to the participant containing the publisher. It may either be sent as an alternative to INFO_TS or in combination with INFO_TS to allow the subscriber to determine which time to use an also for compatibility with systems without support for INFO_AGE.

    INFO_AGE allows two features on systems with no time synchronization:

    • Full support for sample lifespan QoS, as long as lifespan is an order of magnitude larger than network latency
    • Partial support for by source timestamp QoS. It may be used to determine that some samples are clearly older than others, in practical use when the time difference is on the order of seconds. When estimated times are within the uncertainty margin, the subscriber needs to treat them as by destination order QoS to avoid surprising behavior when e.g. a writer publishes several samples in quick succession.

    It should be noted that a system based on INFO_AGE with multiple readers and writers on the same topic will have a non-deterministic sample order on the readers.

  • Reported: DDSI-RTPS 2.3b1 — Mon, 22 Jun 2020 12:27 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.5
  • Disposition Summary:

    Merge with DDSIRTP25-12

    This can be merged with DDSIRTP25-12

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Update Acknowledgemts, Copyright and Statement of Proof

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

    Section 6.3 'Acknowledgments' lists the companies that contributed to the spec. This list needs to be updated to include the companies that contributed to the latests revisions (e.g. as members of the RTF task forces). This includes TwinOaks, Kongsberg, OCI, ADLink, MITRE, NSWC, etc.

    We may also want to list contributor's names as we do for other specs.

    Section 6.4 'Statement of Proof ...' needs to be updated this text has been carried from the original version. Something much stronger can be said today.

    Copyright should be updated to include the companies in the 'Acknowledgments'

  • Reported: DDSI-RTPS 2.3b1 — Tue, 24 Sep 2019 21:23 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Update section 6.3 'Acknowlegments' an copyrights

    As stated in the issue description update the acknowledgments and copyright to include people that participated in the various RTFs

  • Updated: Tue, 29 Jun 2021 12:54 GMT

currentGSN.value < lastGSN.value condition seems wrong

  • Status: closed  
  • Source: N/A ( Frans Schneider)
  • Summary:

    The last condition seems wrong. Shouldn't that be greater than instead of less than?
    If GroupInfoFlag is set and:
    • currentGSN.value is zero or negative
    • firstGSN.value is zero or negative
    • lastGSN.value is negative
    • lastGSN.value < firstGSN.value - 1
    • currentGSN.value < firstGSN.value
    • currentGSN.value < lastGSN.value

  • Reported: DDSI-RTPS 2.3 — Mon, 10 Feb 2020 08:26 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    *Correct section 8.3.7.6.3 'Validity' (Hearbeat) *

    I section 8.3.7.6.3 'Validity' (Hearbeat). Change:
    currentGSN.value < lastGSN.value
    to
    currentGSN.value > lastGSN.value

  • Updated: Tue, 29 Jun 2021 12:54 GMT

8.3.7.5 / 9.4.5.6 HeartBeat Submessage

  • Status: closed  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the message module, the submessage heartbeat defines the flag GroupInfoFlag and the fields currentGSN, firstGSN, lastGSN. writerSet and secureWriterSet. A specification for this flag and the fileds is missing in the PSM.

  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 13:20 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add information on the GroupInfoFlag to 9.4.5.7 'HeartBeat Submessage'

    Add missing information on the GroupInfoFlag and elements currentGSN , firstGSN, and lastGSN to section 9.4.5.7 'HeartBeat Submessage'

  • Updated: Tue, 29 Jun 2021 12:54 GMT

PSM and PIM description of Gap message not matching

  • Status: closed  
  • Source: S2E Systems ( Joao Rebelo)
  • Summary:

    The wire representation of the GAP message given in 9.4.5.5. does not match the logical PIM description given in the sub-clause 8.3.7.4 in the following points:

    • Section 9.4.5.5.1 mentions that "This Submessage has no flags in addition to the EndiannessFlag". Section 8.3.7.4.2 describes "GroupInfoFlag" with the following text "Appears in the Submessage header flags"
    • "gapStartGSN" and "gapEndGSN" sequence numbers do not appear in the wire representation
  • Reported: DDSI-RTPS 2.3 — Mon, 11 Nov 2019 20:45 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add GapInfoFlag information to section 9.4.5.6 'Gap Submessage'

    Add information about the GapInfoFlag, gapStartGSN and gapEndGSN to section 9.4.5.6 'Gap Submessage'.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

Interoperability of Transient/Persistent data

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

    The following issue https://issues.omg.org/browse/DDSIRTP23-26 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.

  • Reported: DDSI-RTPS 2.3b1 — Fri, 20 Mar 2020 20:09 GMT
  • Disposition: Deferred — DDSI-RTPS 2.5
  • Disposition Summary:

    Defer to the next RTF. Until DDS 1.5 is adopted.

    The resolution of this issue depends on some decisions that need to be made on the DDS specification. These issues have been filed against the DDS also modifications to the DDS15 RTF which is still ongoing.

    Therefore the resolution of this issue is deferred to the next DDSI-RTPS RTF, which will be able to take into consideration the result of the DDS15 RTF.

  • Updated: Tue, 29 Jun 2021 12:54 GMT

How should interoperable implementations deal with Transient / Persistent data?

  • Legacy Issue Number: 16099
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    The DDSI-RTPS Specification v2.1 does not currently specify how interoperable implementations should deal with Transient / Persistent data."

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Disposition: Deferred — DDSI-RTPS 2.3
  • Disposition Summary:

    Defer this issue until the next revision

    This issue requires additional time to be resolved. In order not to delay the adoption of the other important issues that are already resolved the RTF recommend it is deferred to the next RTF.

  • Updated: Wed, 24 Jun 2020 18:13 GMT

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

  • Legacy Issue Number: 17286
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    Original Description

    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.

    RTF 2.3 Discussion


    The RTF is recommending this issue is deferred until the transports PSMs that need it (e.g. the RTPS TCP PSM) define the requirements in a more complete way. The point is that these PSMs will need more than just the message length and RTPS should include a mechanism that is sufficiently generic to accommodate it. We are not ready yet to define it.

    The latest proposal we had developed is below. It is left here so future revisions of the specification can leverage these ideas.

    Overall Approach
    -----------------------
    Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

    • rtpsMsgLength

    The rtpsMsgLength indicates the length of the RTPS message

    The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header

    The DDS Security specification will leave this RTPSHeaderExtension following the RTPS Header and before the SecureRTPSPrefixSubMsg. The length will be updated to the new length after processing by the security plugins.

    Another option would be that the RTPSHeaderExtension (therefore not a header extension) would go after the SecureRTPSPrefixSubMsg, but it would be useless there because it can't be used before applying security. The length is no longer serving its purpose, so this is therefore not an option.

    RTF 2.3 Latest Proposed Revised Text

    In section 7.6 'The RTPS Transport Model', update the following bullet point as shown:

    • The transport provides a means to deduce the size of the received message.

    Update Figure 8.8 'Structure of RTPS Messages' to include RTPSHeaderExtension as one if the Submessages.


    In Section 8.3.2 (Type Definitions), Table 8.13 'Types used to define RTPS messages', update the 'Purpose' column for Type SubmessageKind to add RTPS_HE to the list of reserved kinds:
    Enumeration used to identify the kind of Submessage.
    The following values are reserved by this version of the protocol:
    RTPS_HE, DATA, GAP, HEARTBEAT, ACKNACK, PAD, INFO_TS, INFO_REPLY, INFO_DST, INFO_SRC, DATA_FRAG, NACK_FRAG, HEARTBEAT_FRAG


    In section 8.3.2 'Type Definitions' in Table 8.13 add the following row after the row for 'Count_t'

    Checksum_t Type used to hold a checksum. Used to detect message corruption.

    In section 8.3.3 'The Overall Structure of an RTPS Message' update the final paragraph as follows:
    Each message sent by the RTPS protocol has a finite length. This length is not sent explicitly by the RTPS protocol but is part of the underlying transport with which RTPS messages are sent. This length is optionally sent in the RTPS HeaderExtension Submessage.

    The length may also be sent by the underlying transport that carries the RTPS message and, in these cases, may be omitted from the HeaderExtension. In For example, in the case of a packet-oriented transport (like UDP/IP), the length of the message is already provided by the transport encapsulation.

    A In contrast, a stream-oriented transport (like TCP) would need to insert the length ahead of the message include the length in the RTPS HeaderExtension in order to identify the boundary of the RTPS message.


    Add the following subsection following subsection 8.3.5.10 (Count):
    8.3.7.1.2 Checksum
    Checksum is used in the HeaderExtension Submessage and enables the receiver to detect messages corrupted by the transport.

    Table 29 – Structure of the Checksum SubmessageElement

    field type meaning
    value Checksum_t Checksum computed over a set of bytes.

    Add the following subsection as the first subsection in section 8.3.7 'RTPS Submessages':
    8.3.7.1 HeaderExtension
    8.3.7.1.1 Purpose
    The HeaderExtension Submessage is used to convey optional information about the RTPS Message. This submessage, if present, shall appear directly after the RTPS Header.

    8.3.7.1.2 Content
    The elements that form the structure of the HeaderExtension message are described in the table below.
    Table 8.XX - Structure of the HeaderExtension Submessage

    element type meaning
    EndiannessFlag SubmessageFlag Appears in the Submessage header flags. Indicates endianness.
    LenghtFlag SubmessageFlag Appears in the Submessage header flags. Indicates the the rtpsMessageLength field is present.
    ChecksumFlag SubmessageFlag Appears in the Submessage header flags. Indicates the the rtpsMessageChecksum field is present.
    PortFlag SubmessageFlag Appears in the Submessage header flags. Indicates the the destinationPort field is present.
    rtpsMessageLength ulong If present, contains the length of the RTPS Message starting from the beginning of the RTPS Header.
    rtpsMessageChecksum Checksum If present, contains a checksum computed over the content of the RTPS Message, which includes the HeaderExtension submessage. For the purposes of computing the checksum the rtpsMessageChecksum is set to zero.
    destinationPort ulong If present, contains the transport port where the RTPS Message is sent.

    8.3.7.1.3 Validity
    This Submessage is invalid when any of the following is true:

    • submessageLength in the Submessage header is too small to fit the fields that are present as indicated by the submessage flags.
    • rtpsMessageLength is too small.

    8.3.7.1.4 Change in state of Receiver
    None.

    8.3.7.1.5 Logical Interpretation
    The RTPSHeaderExtension may be sent to communicate the length of the RTPS Message. This information may be useful to for managing memory while receiving incoming RTPS Messages.

    The rtpsMsgLength contains the entire length of the RTPS Message starting from the beginning of the RTPS Header.


    In section 9.4.5.1.1 'SubmessageId', add RTPS_HE to the enum SubmessageKind and update the definition to use new IDL syntax:

    enum SubmessageKind {
        @value(0x00)
        RTPS_HE,    /* RTPSHeaderExtension */
        @value(0x01)
        PAD, /* Pad */            
        @value(0x06)
        ACKNACK, /* AckNack */        
        @value(0x07)
        HEARTBEAT, /* Heartbeat */      
        @value(0x08)
        GAP, /* Gap */            
        @value(0x09)
        INFO_TS, /* InfoTimestamp */  
        @value(0x0c)
        INFO_SRC, /* InfoSource */     
        @value(0x0d)
        INFO_REPLY_IP4, /* InfoReplyIp4 */   
        @value(0x0e)
        INFO_DST, /* InfoDestination */
        @value(0x0f)
        INFO_REPLY, /* InfoReply */      
        @value(0x12)
        NACK_FRAG, /* NackFrag */       
        @value(0x13)
        HEARTBEAT_FRAG, /* HeartbeatFrag */  
        @value(0x15)
        DATA, /* Data */           
        @value(0x16)
        DATA_FRAG /* DataFrag */
    };
    

    Add the following subsection as the subsection directly following 9.4.5.1 'Submessage Header' in section 9.4.5 'Mapping of the RTPS Submessages':
    9.4.5.2 RTPSHeaderExtension Submessage
    Sub clause 8.3.7.1 in the PIM defines the logical contents of the RTPSHeaderExtension Submessage. The PSM maps the RTPSHeaderExtension Submessage into the following wire representation:

    0...2...........8...............16..............24..............32
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    RTPS_HE    |X|X|X|X|X|X|X|E|       octetsToNextHeader      |
    +---------------+---------------+---------------+---------------+
    |                          ulong rtpsMsgLength                  |
    +---------------+---------------+---------------+---------------+
    
    

    In section 9.3.2, add the following IDL following the IDL for:
    typedef long Count_t;

    typedef unsigned long Checksum_t;
    
  • Reported: DDSI-RTPS 2.1 — Fri, 30 Mar 2012 04:00 GMT
  • Disposition: Deferred — DDSI-RTPS 2.3
  • Disposition Summary:

    Defer until we have a specification for the RTPS-TCP PSM

    This requirement is mostly driven from the needs of additional transport PSMs (such as the RTPS-TCP) that are currently under development.

    It is unclear whether these PSMs will just need this or also other information beyond the port number which can be addressed at the same time as suggested by some of the discussions and proposed resolutions.

    Therefore the opinion of the RTF is to defer this issue until an additional RTPS Transport PSM is approved to better understand the requirements.

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

PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO need further description

  • Status: closed  
  • Source: Object Computing, Inc. - 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Add description for PID_ORIGINAL_WRITER_INFO and deprecate PID_DIRECTED_WRITE

    A missing description for PID_ORIGINAL_WRITER_INFO has been added and PID_DIRECTED_WRITE type has been updated to match common practice with note to ignore when the format is not known.

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

How should interoperable implementations deal with Group Coherent updates

  • Legacy Issue Number: 16100
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    The DDSI-RTPS Specification v2.1 does not currently specify how interoperable implementations should deal with Group Coherent updates

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Define RTPS Mechanisms for Group Ordered Access and Group Coherent Sets

    In order to support GROUP access scope as defined by the DDS specification, the RTPS spec has added the following elements:

    • New in-line QoS
      • PID_GROUP_SEQ_NUM sent with DATA and (first) DATA_FRAG submessages
      • PID_GROUP_COHERENT_SET in-line QoS sent with DATA and (first) DATA_FRAG submessages
      • PID_WRITER_GROUP_INFO in-line QoS sent with DATA and (first) DATA_FRAG submessages
      • PID_SECURE_WRITER_GROUP_INFO in-line QoS sent with DATA and (first) DATA_FRAG submessages
    • New SubmessageElement: GroupDigest
    • Extended HB message
      • New G flag (group info)
      • New fields when G flag is set:
        • currentGSN : SequenceNumber
        • firstGSN : SequenceNumber
        • lastGSN : SequenceNumber
        • writerSet : GroupDigest
        • secureWriterSet : GroupDigest
    • Extended GAP message
      • New G flag (group info)
      • New fields when G flag is set:
        • gapStartGSN : SequenceNumber
        • gapEndGSN : SequenceNumber
    • New fields WriterProxy::remoteGroupEntityId, ReaderProxy::remoteGroupEntityId
      • Uses previously deprecated PID_GROUP_ENTITYID
  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

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

  • Legacy Issue Number: 15885
  • Status: closed  
  • 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
  • Disposition: Deferred — DDSI-RTPS 2.3
  • Disposition Summary:

    Yes/No vote to decide whether to keep DDSI-RTPS or change to DDS-RTPS

    If we do nothing the name will remain DDSI-RTPS.

    The proposed resolution to this issue is to change the acronym to DDS-RTPS. So if the issue is approved the acronym will change. If it is rejected it will stay the same.

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

GAP lack information on related (instance/key) needed for correct DDS behavior

  • Legacy Issue Number: 11035
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Title: Must send GAP when filtering on writer-side regardless of reliability QoS setting
    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    This issue is not currently in a state to be resolved. What follows are various thoughts on the issue and possible solutions to be discussed. This issue will not be resolved in time for the finalization task force and is included here to be documented for the revision task force.
    Discussion topic: what are DDS semantics for combining filtering with the deadline QoS?
    Should the deadline be triggered when all samples during the deadline period were filtered out?
    That is, does deadline require at least one sample to arrive every deadline period seconds that passed the filter?
    Or is the deadline satisfied when any sample arrives within the period, whether filtered out or not?

    If deadline only applies to samples that pass the filter, RTPS needs no changes, simply use the GAP subMessage to avoid incorrect onDataLost callbacks.
    If not, we run into a problem when using keyed DataWriters and finite deadlines. As the deadline applies on a per instance basis, the Reader expects at least one update for every instance, even when none of the updates for a particular instance pass the filter. A GAP message does not indicate for which instance an update was filtered out, so it cannot be used by the Reader to verify the deadline constraint. Instead, we should consider using an empty DATA message instead, possibly with a flag that states the update did not pass any filter. This would also be useful to add a new instance state NOT_ALIVE_FILTERED or so later on to the DDS spec.
    Another possibility would be to add a list of KeyHashes to the GAP message. SO that a GAP that is caused by a CFT actually encodes the instances that are being gapped. This would not cause incorrect firings of the DEADLINE and as a result would maintain ownership of instances even if they are filtered out…
    There are two ways to do this.
    Either we separate GAPs that correspond to filtered samples from those that correspond to irrelevant samples. So in effect we have two kinds of GAP messages
    Or we list explicitly the sequence number of each filtered message along with its KeyHash.
    Not clear what would be easier implementationwise. The samples that have been filtered are still on the writer so it appears that either implementation would work.
    Option (1) would save putting the sequence number with each KeyHash. This can be 4 or 8 bytes per instance, depending on whether we put the sequence number as is, or we encode it as an increment
    Option (2) would cause additional GAP submessages to be sent which is an overhead of 28 bytes. Not clear what is less costly…
    Also, if we use Option(1), then the messages that represent real GAPs can be sent via multicast; but this is only likely to occur when late joiners appear as normally there would be no "irrelevant" gaps if data is published immediately. Moreover we can in practice still do this and separate the GAP messages that represent real GAPs from the ones that don't. Option 1 does not force us to combine, just provides the means to do so…
    Option (2) has the problem that in certain edge cases the overhead is significant. For example if each we have a irrelevant-sample GAP followed by a filtered sample, followed by an irrelevant sample gap, etc. then we end up sending one GAP message per filtered sample with is 28 bytes of overhead per filtered sample versus a single GAP with 4 bytes of overhead per filtered sample. Also the processing is much more efficient as each GAP message is dispatched separately up the receiver's stack.
    For this reason it appears that Option 1 is more flexible, and the overhead is more stable. Opt
    Proposal(s):
    Always send GAPs for filtered-out messages (both in the BestEffort and in the RELIABLE) cases
    If the type is Keyed, then the GAP also includes at the end a sequence of :
    struct FilteredSampleDesc

    { long gapStartOffset; KeyHashPrefix keyHashPrefix; KeyHashSuffic keyHashSuffix; }

    ;
    The GAP message gets two additional flags:
    KeyHashFlag
    indicates the presence of the KeyHashPrefix
    FilteredSamplesFlag
    Indicates the presence of the sequence< FilteredSampleDesc>
    An issue needs to be filed against the DDS spec to clarify:
    (a) Whether the deadline as specified by a DataReader should apply to the samples that pass the DataReader filter or to the samples sent by any writer?
    (b) Whether a new instance_state ALIVE_FILTERED should be added such that the DataReader can determine that a sample was filtered and potentially take action on that.
    (c) Whether an API or a QoS should be added to the DataReader to allow the DataReader to remove the instance information for instances with state ALIVE_FILTERED after all samples are taken. This allows resources to be conserved in the case where once filtered we expect the instance to remain filtered and also allows a reader to be notified if the instance becomes unfiltered.
    (d) Weather to add a filtered_generation_count that the instance has becomed ALIVE after being in the ALIVE_FILTERED

    Resolution:
    T4 should include code and description that states that when the sample is not relevant, send a GAP…same for the stateful best effort writer.
    Revised Text:

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Introduce a mechanism to inform a Reader that an instance is filtered

    Extend the StatusInfo_t that is sent via inline Qos (PID_STATUS_INFO) such that it can be used to indicate that an instance has been filtered by a reader. This extends the current usage to send DISPOSE and UNREGISTER messages.

    Add an issue to the DDS RTF 1.5 to introduce the concept of ALIVE_FILTERED Instance state to complement the existing ones (ALIVE, NOT_ALIVE_DISPOSED, NOT_ALIVE_NO_WRITERS).

    Define more precisely when a writer that does writer-side content filter should send the DISPOSE, UNREGISTER, and FILTERED messages.

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

Editing issues

  • Legacy Issue Number: 16957
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    1. Section: 8.3.6.3, Bullet 2 and Footnote 2
    Page: 43
    Change: PROTOCOL_RTPS is not defined by PSM

    2. Section: 8.3.7.3.2, Table 8.35
    Page: 50
    Change: KeyFlag is missing from the table

    3. Section: 8.3.7.3.2, Table 8.35
    Page: 51
    Change: Remove the line "Present only if DataFlag is set in the header", as DataFrag has no such flag. Remove the line "Present only if either the DataFlag or the KeyFlag are set in the header", as DataFrag has no DataFlag. In the first bullet point replace "If the DataFlag is set" with "If the KeyFlag is not set".

    4. Section: 8.4.1
    Page: 63
    Change: Section 8.4.13 (Writer Liveliness) is missing from this list.

    5. Section: 8.4.7.2
    Page: 75
    Change: The paragraph above the table should be changed from using Locator_t to ReaderLocator (the table was changed in a previous revision).

    6. Section: 8.4.7.2.2, 8.4.7.2.3
    Page: 76
    Change: Locator_t in these sections should be ReaderLocator

    7. Section: 8.4.7.3, Table 8.51
    Page: 77
    Change: In figure 8.15, type of locator is Locator_t[*] but the [*] is missing from this table (8.51) and the text should reflect the actual cardinality

    8. Section: 8.4.9.2
    Page: 93
    Change: The sentence fragment "Submessages are used..." is nonsensical, it should be removed.

    9. Section: 8.5.3.3, Figure 8.29
    Page: 129
    Change: Remove figure 8.29, it is a duplicate of figure 8.28

    10. Section: 9.4.5.3, block diagram
    Page: 170
    Change: Flag "K" is missing from the flags byte

    11. Section: 9.6.2.1
    Page: 180
    Change: The wire-representation diagram is missing the participantGuidPrefix and kind fields (also see OMG Issue 12501)

    12. Section: 9.6.2.2, Table 9.10
    Page: 182
    Change: remoteWriterGuid belongs to WriterProxy, not ReaderProxy

    13. Section: 9.6.2.2, Table 9.10
    Page: 182
    Change: Table 9.10 caption is incorrect, looks like it was copied from 9.11

    14. Section: 9.6.3.2, Table 9.16
    Page: 190
    Change: KeyHashSuffix does not exist; remove this row from the table. The row for SerializedData should be sufficient to describe the use of PID_COHERENT_SET.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Fix Editorial Issues

    There are a number of minor editorial issues that need to fixed. This issue was created to resolve them.

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

Clarify start of alignment for SerializedPayload

  • Legacy Issue Number: 19660
  • Status: closed  
  • 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify the start alignment for the SerializedPayload SubmessageElement

    The SerializedPayload SubmessageElement has been updated to clearly state that the CDR stream is logically reset after the encapsulation header, similar to what is already described in section 9.4.2.11. Section 9.4.2.11 has also been improved for clarity, with no change to semantics.

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

Make sure all references to the RTPS version are updated to 2.4

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

    DDS Security updated the RTPS version to 2.3. Consequently this revision should update it to 2.4. See also DDSIRTP23-56

  • Reported: DDSI-RTPS 2.2 — Wed, 25 Jul 2018 14:56 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update protocol version from 2.2 to 2.4

    Replace all the version 2.2 with 2.4 in all places except Section 9.3.1.4 '9.3.1.4 Deprecated EntityIds in version 2.2 of the Protocol' and Section 9.6.4 'ParameterIds Deprecated by the Protocol'

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

Builtin Interparticipant Channel should have DataReader reliability kind BEST_EFFORTS

  • Status: closed  
  • 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    *Add Flags to the BuiltinEndpointSet to Facilitate Communication of Configuration Options *

    It is useful to be able to configure the builtin endpoints and then communicate the configurations. A new PID has been defined that will allow communication of these specific configurations. One of the new flags will be used to communicate the Reliability kind of the inter-participant DataReader.

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

DomainId should propagated in the ParticipantBuiltinTopicData

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

    Currently the domainId is not propagated with the ParticipantBuiltinTopicData as a result there could be situations where Participant accidentally discovers another one on a different DomainId as a result of port overlaps.

    This issue requests the domainId to be propagated in the ParticipantBuiltinTopicData so it can be checked independently of port numbers.

  • Reported: DDSI-RTPS 2.2 — Tue, 15 May 2018 16:09 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Propagate DomainId as part of Participant Discovery

    Add domainId as an additional field in ParticipantProxy
    Add PID_DOMAIN_ID with value 0x000f containing a domainId
    Add PID_DOMAIN_TAG with value 0x4014 containing a domainTag

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

Update section 10 (Data Encapsulation)

  • Status: closed  
  • 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update Section 10 (Data Encapsulation)

    Replace Section 10 to more precisely define the Encapsulation Identifiers and and reference the Data Representation formats in DDS-XTYPES section 7.4.

    Include an example for builtin Topic and one for an application-defined Topic.

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

Describe how to create a WITH_KEY or NO_KEY RTPS Endpoint from DDS

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

    Describe how to create a WITH_KEY or NO_KEY RTPS Endpoint from DDS. The RTPS endpoints have a with_key attribute, but it is not clear how this attribute can be set

  • Reported: DDSI-RTPS 2.2 — Sat, 24 Feb 2018 02:44 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Describe how to create a WITH_KEY or NO_KEY RTPS Endpoint from DDS

    The text has been clarified to describe how an RTPS Writer and RTPS Reader can be defined as either WITH_KEY or NO_KEY from DDS.

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

Reference the PIDs that are reserved by the XTypes Spec in RTPS

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

    The Xtypes Specification uses some of the protocol-specific PIDs, we should note that these PIDs are reserved in the RTPS spec.

  • Reported: DDSI-RTPS 2.2 — Mon, 26 Feb 2018 01:15 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Reference the PIDs that are reserved by the XTypes Spec in RTPS

    The Xtypes Spec uses PIDs 0x0072, 0x0073, 0x0074, and 0x0075, we have noted in RTPS that these PIDs are reserved.

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

Update UML figures in the specification


Data/Frag submessage flag for security

  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    See https://issues.omg.org/browse/DDSSEC12-33 for background.
    Since this revision of RTPS will take into account the extensions for DDS-Security, define a flag in Data/Frag submessages to indicate that the SerializedPayload submessage element was modified for security.

  • Reported: DDSI-RTPS 2.2 — Thu, 15 Feb 2018 19:42 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Reserve a flag in DATA and DATA_FRAG Submessages to indicate the SerializedPayload has been transformed

    A flag in DATA and DATA_FRAG Submessages was reserved to indicate that the SerializedPayload has been transformed.

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

Unused ParameterIds in Table 9.12

  • Status: closed  
  • Source: Object Computing, Inc. - 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Remove ParameterIds incorrectly listed Table 9.12 and Add Missing Usage for PID_TYPE_MAX_SIZE_SERIALIZED

    PID_KEY_HASH and PID_STATUS_INFO are incorrectly listed in Table 9.12 which lists the data for the builtin entities. They are already listed in Table 9.14 'Inline QoS parameters' so they have been removed from Table 9.12. A new optional attribute has been added to WriterProxy for PID_TYPE_MAX_SIZE_SERIALIZED.

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

Update state machine to allow retrieving inline qos from a CacheChange

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

    There are protocol messages that have sample-specific inlineQoS that comes from the higher layers (for example the original writer info) we need to add this to the CacheChange.inlineQos and the virtual machine should be updated that in addition to getting inlineqos from the writer, it should also get it form the cache change itself

  • Reported: DDSI-RTPS 2.2 — Mon, 12 Feb 2018 19:58 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Retrieve inlineQoS from CacheChange

    InlineQos can come from a CacheChange as well as from the writer. CacheChange has been updated to include inlineQos and the virtual machine has been updated to retrieve this inlineQoS as well.

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

Typo in 8.4.13

  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    "All implementations must support the Wirter Liveliness Protocol", Wirter should be Writer

  • Reported: DDSI-RTPS 2.2 — Wed, 7 Feb 2018 16:55 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Fix typo

    Replace "Wirter" with "Writer"

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

Figure 8.29 duplicates 8.28


Inconsistent definitions of ParticipantMessageData

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

    The ParticipantMessageData appears defined in 3 places:

    Figure 8.26 - ParticipantMessageData

    Section 9.6.2.1 (Data Representation for the ParticipantMessageData Built-in Endpoints) in the IDL

    Section 9.6.2.1 In the CDR encoded representation.

    These definitions are not consistent. The IDL definition appears to be the correct one. This should be verified and the others should be adjusted to match it.

  • Reported: DDSI-RTPS 2.2 — Wed, 7 Feb 2018 21:24 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Already covered by DDSIRTP23-23

    Close as duplicate as it is already covered by DDSIRTPS23-23

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

Key attributes and Regular attributes of a topic should be individually de-serializable

  • Legacy Issue Number: 16558
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    Key attributes and Regular attributes of a topic should be individually de-serializable (or at least make the keyhash compulsory)

    [Nature] Architectural
    [Severity] Major

    [Description]
    The "DDS Interoperability Wire Protocol v2.1" defines a a serialization format for topic types in which
    it is not easy, nor efficient, to simply get access to the key of a given topic. This has to do with how CDR
    serializes structs but could be worked around with the new X-Types specification.
    In essence the problem is that some applications such as DDS routers (such as the PrismTech BlendBox)
    require to perform some operations that while requiring a knowledge of the instance do not require the deserialization
    of the data payload.

    [Resolution]
    For DDS implementation compatible with the X-Types ensure that the regular data attributes and the key attributes are serialized
    in different chunks and thus individually accessible in an efficient manner – meaning to access the key I would prefer not to scan all
    the regular attributes.

    For non X-Types compatible DDS implementations make the KeyHash compulsory, meaning require DDS compliant implementation to
    always send a key-hash along with a Data submessage.

  • Reported: DDSI-RTPS 2.0b1 — Mon, 19 Sep 2011 04:00 GMT
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    No immediate need to add individual serialization of keys and regular attributes

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

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

DDSI/RTPS Key MD5 Hash

  • Legacy Issue Number: 15912
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • 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

Section 8.4.9.1.4: Best-Effort Stateful Writer GAP semantics

  • Legacy Issue Number: 16965
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 92
    Change: Figure 8.18 notes that transition T4 can send a GAP, but this section doesn't describe when/how to send a GAP.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Add descriptions of when Best Effort Writers Send GAP messages

    The Best-Effort Stateless and Stateful Writer Behaviors should include logic for when a GAP message is sent, similar to the logic already present for their Reliable counterparts.

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

Section 8.4.7.3, Table 8.52: Describe ReaderLocator operations' semantics

  • Legacy Issue Number: 16963
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 77
    Change: Unlike other tables of operations in this section, none of these operations are described in the text of the section

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Add missing descriptions of the ReaderLocator operations in Table 8.52

    Add missing descriptions of the ReaderLocator operations in Table 8.52, in a similar manner to the other kinds of operations that are defined in this section.

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

Use the term "Encapsulation" consistently and precisely

  • Legacy Issue Number: 16955
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Encapsulation has a precise technical meaning from the CORBA spec (formal/11-11-02 section 9.3.3) and a similar meaning from chapter 10 of RTPS, neither of which matches most of the other uses of “encapsulation” throughout the RTPS spec. In general, encapsulation means adding specific prefix bytes to the on-the-wire representation of data. This prefix can be used by the receiver to understand the format of the following bytes. The majority of uses of “encapsulation” in the specification do not agree with this meaning. This issue seeks to fix that by using the simpler term of “encoding” in place of “encapsulation.”

    Encapsulate
    -----------------

    Section: 8.3.2, Table 8.13, Count_t row
    Page: 30
    Change: replace “'encapsulate'” with “'hold”'

    Section: 8.3.3.2, Table 8.15, flags row
    Page: 34
    Change: replace '“encapsulate”' with “'encode”' in two places

    Section: 8.3.5.1
    Page: 37
    Change: replace “'encapsulate'” with '“contain'”

    Section: 8.3.5.9, Paragraph 1
    Page: 41
    Change: replace “encapsulate” with “'contain'”

    Section: 8.3.7.9.2, Table 8.41, protocolVersion and VendorId rows
    Page: 59
    Change: replace “'to encapsulate subsequent Submessages'” with “"for subsequent Submessages”"
    Change 'vendor that encapsulated subsequent submessages' with “'vendor that originated the subsequent submessages' ”

    Section: 8.4.10.3
    Page: 105
    Change: replace “'encapsulated”' with “'maintained”'

    Section: 8.4.11.1.2
    Page: 110
    Change: replace 'the DATA message encapsulates' with 'the DATA message contains'

    Section: 8.4.12.1.2
    Page: 112
    Change: replace 'the DATA message encapsulates' with 'the DATA message contains'

    Section: 8.5.3.2, Table 8.73, expectesInlineQos row
    Page: 126
    Change: replace '“encapsulated”' with '“included'”

    Section 9.4.2.12
    Page: 166
    Change: replace 'process used to encapsulate' with 'process used to encode'

    Section: 9.6.2.2, Paragraphs 4-5
    Page: 181
    Change: replace “'encapsulates'” with “'contains'”; replace “'encapsulated'” with “'represented'” (twice)

    Section: 9.6.2.2.2
    Page: 182
    Change: replace “'used to encapsulate the data'” with '“used for the data'”

    Section: 9.6.3
    Page: 187
    Change: replace “'are encapsulated'” with “'are contained'”

    Section: 9.6.3.3
    Page: 190
    Change: replace “'any unfilled bits in the KeyHash_t after all the key fields have been encapsulated shall be set to zero' with 'any unfilled bits in the KeyHash_t shall be set to zero”'

    Page: 191
    Change: replace “'encapsulated as' with 'represented as'

    Section: 10
    This is handled on a separate issue.

    Encapsulation
    -------------------

    Section 6.2 change 'data encapsulation' to 'data representation' (twice)

    Section 8.3.3 change 'transport encapsulation' to 'transport headers'

    Section 8.3.5.9 change 'The encapsulation' to 'the representation'

    Section 8.3.5.12 change 'For additional information on data encapsulation see ...' to 'For additional information see ...'
    Section 8.3.5.13 change 'For additional information on data encapsulation see ...' to 'For additional information see ...'

    Table 8.34 change 'contains the encapsulation of the ...' to 'contains the ...' (twice in serializedPayload row).

    Table 8.35 serializedPayload row:
    Change 'Encapsulation of a consecutive ...' with ' A consecutive ...'
    Change 'contains the encapsulation of the ...' to 'contains the ...' (twice in serializedPayload row).

    Section 8.4.11.1.1 and 8.4.11.1.2
    Change 'The encapsulation is described' to 'The representation is described' (once on each section)

    Section: 9.4.2.11, Paragraphs 5, 7, 9
    Page: 165
    Change: “'CDR encapsulation”' with 'CDR representation' and 'ParameterList encapsulation' with 'ParameterList representation'

    Change 'These are two predefined values of the parameterId used for the encapsulation' with 'These are two predefined values of the parameterId:'

    Section 9.5 Change title to "Mapping to UDP/IP Transport Messages"
    Change body to:
    When RTPS is used over UDP/IP, each UDP/IP datagram shall contain exactly one or more complete RTPS Messages.

    Note: This is a change. Currently the requirement is one datagram one RTPS message.

    Section: 9.6.3.3
    Page: 190-191
    Change: replace “'“encapsulation'” with '“representation'” (seven times)

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Replace all uses of any form of 'Encapsulate'

    Encapsulation has a precise technical meaning from the CORBA spec (formal/11-11-02 section 9.3.3) and a similar meaning from chapter 10 of RTPS, neither of which matches most of the other uses of “encapsulation” throughout the RTPS spec. We are therefore replacing all uses of any form of the word 'encapsulate' with a different word.
    Three general rules of thumb were followed:

    1. In cases describing the contents of SubmessageElements or messages, we have replaced encapsulate with 'contain'.
    2. Anywhere that said 'data encapsulation' or 'CDR encapsulation' is replaced with 'data representation'.
    3. We have removed the phrase containing encapsulation all together in places where it was used unnecessarily.

    All other situations were dealt with on a case-by-case basis

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

Remove the concept of Topic Kinds (With Key vs. No Key)

  • Legacy Issue Number: 16954
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    This distinction is important for DDS, but not relevant for RTPS. There are places where RTPS deals with the Key as an independent unit of data (KeyFlag, etc.), but those are not relevant to the TopicKind_t which seems to be an artifact of an older version of the specification. The current protocol as written in this specification works the same way for both With Key and No Key topics. This issue seeks to remove the Topic Kind concept entirely from the specification.
    1. Section: 8.2.1.2, Table 8.2
    Page: 14
    Change: remove the table row for TopicKind_t
    2. Section: 8.2.1.3, Figure 8.2
    Page: 16
    Change: remove the topicKind attribute in Endpoint
    3. Section: 8.2.5, Figure 8.5
    Page: 21
    Change: remove the topicKind attribute in Endpoint
    4. Section: 8.2.6, Table 8.9
    Page: 23
    Change: remove the table row for TopicKind_t
    5. Section: 8.2.9.1, Figure 8.6
    Page: 25
    Change: remove the if() statements for W::topicKind
    6. Section: 8.2.9.1.3-4
    Page: 26-27
    Change: remove the if() statements for the_rtps_writer.topicKind and the paragraphs “This operation has no effect if the topicKind==NO_KEY).”
    7. Section: 8.3.3, Figure 8.8
    Page: 31
    Change: remove NoKeyData and NoKeyDataFrag
    8. Section: 8.3.7, Bullets 1-2,4
    Page: 43
    Change: remove the text “(NO_KEY Reader/Writer or WITH_KEY Reader/Writer)”
    9. Section: 8.3.7.2
    Page: 47
    Change: remove the text “(NO_KEY or WITH_KEY)”
    10. Section: 8.3.7.3
    Page: 49
    Change: remove the text “(NO_KEY or WITH_KEY)”
    11. Section: 8.3.7.2, 3rd Bullet
    Page: 63
    Change: remove the text referring to “keyed topics”
    12. Section: 8.4.4
    Page: 69-70
    Change: remove all references to topicKind, WITH_KEY, NO_KEY, etc.
    13. Section: 8.4.7.1, Figure 8.15
    Page: 72
    Change: remove the topicKind attribute in Endpoint
    14. Section: 8.4.8.1
    Page: 83
    Change: remove “WITH_KEY”
    15. Section: 8.4.8.1, Figure 8.16
    Page: 84
    Change: remove “WITH_KEY”

    16. Section: 8.4.8.2
    Page: 85
    Change: remove “WITH_KEY” and “NO_KEY”
    17. Section: 8.4.8.2, Figure 8.17
    Page: 86
    Change: remove “WITH_KEY”
    18. Section: 8.4.9.1
    Page: 90
    Change: remove “WITH_KEY” and “NO_KEY”
    19. Section: 8.4.9.1, Figure 8.18
    Page: 90
    Change: remove “WITH_KEY”
    20. Section: 8.4.9.2
    Page: 93
    Change: remove “WITH_KEY” and “NO_KEY”
    21. Section: 8.4.9.2, Figure 8.19
    Page: 94
    Change: remove “WITH_KEY”

    22. Section: 8.4.10.1, Figure 8.21
    Page: 102
    Change: remove the topicKind attribute in Endpoint

    23. Section: 8.4.11.1
    Page: 109
    Change: remove “WITH_KEY” and “NO_KEY”
    24. Section: 8.4.11.1, Figure 8.22
    Page: 110
    Change: remove “WITH_KEY”

    25. Section: 8.4.12.1
    Page: 111
    Change: remove “WITH_KEY” and “NO_KEY”
    26. Section: 8.4.12.1, Figure 8.23
    Page: 111
    Change: remove “WITH_KEY”

    27. Section: 8.4.12.2
    Page: 113
    Change: remove “WITH_KEY” and “NO_KEY”

    28. Section: 8.4.12.3, Figure 8.25
    Page: 117
    Change: remove “NOKEYDATA” alternative

    29. Section: 8.5.3.3, Tables 8.74 and 8.75
    Page: 129
    Change: remove topicKind rows from both tables

    30. Section: 9.3.2, Table 9.4
    Page: 155
    Change: remove the “TopicKind_t” row

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Limit the use of TopicKind to the places where it matters

    The protocol works the same whether or not a Topic is keyed; the distinction was therefore unnecessary in many places and was removed.

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

Incorrect/misleading description of KeyHash computation

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

    Section 9.6.3.3 KeyHash (PID_KEY_HASH) says that the KeyHash is either computed as the CDR Big-Endian encapsulation of all the Key fields in sequence, or else as the MD5 of that "CDR Big-Endian encapsulation of all the Key fields in sequence" the decision is based on whether the "CDR Big-Endian encapsulation of all the Key fields in sequence" for that data-type is known to always fit into the 16-byte KeyHash.

    However the text in the first bullet says "If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less than 128 bits, then the KeyHash shall be computed...

    This is misleading as it leave indeterminate the case when the "the maximum size of the sequential CDR encapsulation of all the key fields" is exactly 128 bits. In this case if the sentence is interpreted to mean "strictly less than 128" then an MD5 should be used. If it is interpreted to mean "less or equal" then no MD5 should be applied.

    Unfortunately this situation occurs on the builtin-topic types because the GUIDs are exactly 16 bytes.

    Proposed Resolution:
    In Section 9.6.3.3 KeyHash (PID_KEY_HASH). In the first bullet, replace:
    "If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less than 128 bits,"

    With
    "If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less or equal than 128 bits,"

  • Reported: DDSI-RTPS 2.0b1 — Mon, 2 Mar 2015 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify the KeyHash computation in the case of a CDR encapsulation of exactly 128 bits

    The language describing when to use an MD5 to compute the KeyHash has been clarified to reflect that no MD5 should be used is the serialized length of the key fields is less that or equal to 128 bits, as opposed to strictly less than.

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

Table 9.13 "reserved for future use" rows

  • Status: closed  
  • Source: Object Computing, Inc. - 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Remove PID_GROUP_ENTITYID and PID_PARTICIPANT_ENTITYID

    PID_GROUP_ENTITYID and PID_PARTICIPANT_ENTITYID are not currently used for any purpose and are not being sent by any known implementors. They have therefore been removed from the specification.

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

Reorganizing section 9.3.2

  • Status: closed  
  • Source: Object Computing, Inc. - 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Split Table 9.4

    When current rows of Table 9.4 contain their own tables of constants (beyond just trivial constants that we don't expect to change in future minor versions), make these constants their own tables.

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

Incorrect definition of SequenceNumberSet

  • Status: closed  
  • 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    *Update SequenceNumberSet definition to explicitly allow 0-bits *

    The current definition of the SequenceNumberSet requires at least 1 bit in the bitset but there are use cases where 0 bits are needed so the definition will be updated.

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

Semantics of AckNack's Final Flag

  • Status: closed  
  • Source: Object Computing, Inc. - 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify the meaning of the ACKNACK Final Flag

    The description of the ACKNACK final flag is not clear as to what is the expected behavior. The description needs to be updated to make clear that the absence of the Final Flag requires that the Writer send a HB and the presence of the flag leaves the decision up to the Writer.

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

RTPS Minor version should take into consideration DDS-Security

  • Status: closed  
  • 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Incorporate changes made by the DDS-Security specification to RTPS into the RTPS spec

    The DDS-Security specification reserves new ParameterIds and submessageIds which need to be included as reserved in the RTPS spec. Also, due to these changes, the DDS-Security Spec updated the RTPS minor version to 3, therefore the newest version of the RTPS spec shall be 2.4.

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

Reference reserved ParameterIDs for DDS-Security and dependencies

  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Duplicates DDSIRTP23-39

    The proposal for issue DDSIRTP23-39 covers all changes required by the next version of the RTPS specification as a result of the most recent DDS-Security spec.

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

Figure 8.1 has extra classes. Figures 8.2 and 8.5 are missing attributes

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

    Figure 8.1 shows a DataReader and DataWriter but these classes are not explained in Table 8.1 as all other are.

    These classes seem unnecessary to the explanations on section 8.2.1 so they should be removed from the figure. They are already explained in Figure 7.3.

    In addition the explanation of the attributes in Table 8.2 mentions GUID_t, GuidPrefix_t, EntityId_t, Locator_t, VendorId_t, and ProtocolVersion_t which are not shown in the figure.

    Figure 8.1 should be updated to show were those attributes are used.

    Figures 8.2 and 8.5 are missing the Participant attribute guidPrefix and the Endpoint attribute endpointId

  • Reported: DDSI-RTPS 2.2 — Sat, 27 Jan 2018 02:20 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update figure 8.1, 8.2, and 8.5

    Update figure 8.1. Remove DataWriter and DataReader and adding the missing attributes as described in the issue.
    Update figures 8.2 and 8.5 adding the missing attributes

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

Remove/deprecate Property_t, EntityName_t, PID_PROPERTY_LIST

  • Status: closed  
  • Source: Object Computing, Inc. - 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
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    Do not remove Property_t and EntityName_t

    There are open issues to add EntityName_t and Property_t to the DDS specification and Property_t is already being used in the DDS-Security Spec. These two types and PIDs have therefore not been removed from RTPS as they will be used once they have been added to the DDS specification.

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

PIM-PSM inconsistent BuiltInEndpoints

  • Status: closed  
  • Source: Object Computing, Inc. - 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify the PIM-PSM mapping for BuiltinEndpoints

    There are some inconsistencies between the PIM and PSM with regards to the builtin endpoints which have bits reserved in the availableBuiltinEndpoints. Some possible values are missing from the PIM that are referenced in the PSM and vice versa. Because the PIM and PSM use different names, the mapping between the constants that are defined in the PIM and their corresponding constants in the PSM has also been clarified.

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

resendDataPeriod in StatelessWriter

  • Status: closed  
  • Source: Object Computing, Inc. - 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Remove resendDataPeriod from the StatelessWriter reference implemenation

    The member resendDataPeriod of the StatelessWriter is not referenced in the described StatelessWriter's behavior and seems unnecessary. It will therefore be removed.

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

Deprecate PID_PARTICIPANT_BUILTIN_ENDPOINTS

  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Merged with resolution of DDSIRTP23-11

    The resolution of DDSIRTP23-11 was to deprecate a number of PIDs, the resolution of this issue was therefore added to that proposal by adding the deprecated PID_PARTICIPANT_BUILTIN_ENDPOINTS to the table described in DDSIRTP23-48.

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

Include the padded bits into the Encapsulation options

  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Merged with resolution of DDSIRTP23-42

    The resolution of this issue has been merged with the resolution of DDSIRTP23-42

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

InfoTimestamp dates past 2038

  • Status: closed  
  • Source: Object Computing, Inc. - 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update Time_t to have an unsigned seconds field

    To support time stamps past the year 2038. the type of the seconds member in Time_t has been updated from a signed integer to unsigned. This will not rollover until the year 2106.

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

Normative references for IDL and CDR

  • Status: closed  
  • Source: Object Computing, Inc. - 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Add missing normative references

    There are some missing normative references which should be added in section 3. They are:

    • IDL 4.1
    • CDR
    • IETF RFC 1305 (NTP Time)
    • IETF RFC 1321 (MD5)
  • Updated: Wed, 19 Dec 2018 16:38 GMT

BestEffort StatefulReader behavior does not handle GAP

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

    In section 8.4.12.1 Best-Effort StatefulReader Behavior the state machine does not handle the GAP message.

    Best-Effort readers also process GAP messages so this should be reflected in the state machine.

  • Reported: DDSI-RTPS 2.2 — Wed, 7 Feb 2018 03:40 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Add transition for when Best Effort Readers Receive GAP messages

    The Best-Effort Stateful Reader Behavior should include logic for when a GAP message is received, similar to the logic already present for its Reliable counterpart.

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

Section 8.4.14.1.1, Bullet 3: Put precise bounds on the fragment size

  • Legacy Issue Number: 16966
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 120
    Change: Fragment size should be allowed to be equal to (instead of strictly greater than) 1KB, also define KB as 1024 bytes to avoid the KB/KiB issue (1000 vs. 1024).

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Remove the lower bound for fragment sizes

    We see no need to specify the lower bound for fragment sizes so we will remove that requirement.

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

Section 8.4.8.1.4: When does Best-Effort Stateless Writer send a GAP

  • Legacy Issue Number: 16964
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 85
    Change: Figure 8.16 notes that transition T4 can send a GAP, but this section doesn't describe when/how to send a GAP.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    This issue is resolved as part of DDSIRTP23-20

    This issue is resolved as part of DDSIRTP23-20

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

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

  • Legacy Issue Number: 19237
  • Status: closed  
  • 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update references to the DDS Spec with the current 1.4 version

    Replace references to DDS version 1.2 with the most current version, 1.4

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

The Writer Liveliness Protocol should be removed

  • Legacy Issue Number: 17285
  • Status: closed  
  • Source: ZettaScale Technology ( 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
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    No Need to remove the Writer Liveliness Protocol

    The RTF does not see a need to remove the Writer Liveliness Protocol from the specification.

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

Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for RTPS fields

  • Legacy Issue Number: 16984
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 184-187
    Change: The following RTPS fields lack a mapping: ParticipantProxy::guidPrefix, ReaderProxy::remoteReaderGuid, WriterProxy::remoteWriterGuid. Table 9.10 indicates that they are optional, but they are not possible to encode without a mapping. Also, DiscoveredReaderData::contentFilterProperty (AKA DiscoveredReaderData::contentFilter in the PIM: these should be consistent) is lacking a mapping

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Cleanup up missing and unused ParameterId mappings

    Add a missing PID_ENDPOINT_GUID and map SubscriptionBuiltinTopicData::key and PublicationBuiltinTopicData::key to it.

    Add missing mapping of DiscoveredReaderData::contentFilterProperty, TopicBuiltinTopicData::topic_data, SubscriptionBuiltinTopicData::durability, PublicationBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::presentation

    Remove the mapping of SubscriptionBuiltinTopicData::lifespan, which is not present in DDS

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

Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for DDS fields

  • Legacy Issue Number: 16983
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 185
    Change: The following DDS fields lack a mapping: TopicBuiltinTopicData::topic_data, SubscriptionBuiltinTopicData::durability, PublicationBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::presentation, and the "key" field in Publication, Subscription, and Topic. Also, the mapped DDS field SubscriptionBuiltinTopicData::lifespan does not exist in DDS

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Duplicates DDSIRTP23-8

    The resolution of DDSIRTP23-8 covers the resolutions of the missing/unnecessary mappings described in DDSIRTP23-9

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

Section: 9.6.2.2.2, Table 9.12: Duration_t not defined by PSM

  • Legacy Issue Number: 16982
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 184
    Change: Duration_t (used for PID_PARTICIPANT_LEASE_DURATION) is not defined in the PSM. Use Time_t instead?

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Define a PSM Mapping for Duration_t

    A PSM mapping of Duration_t has been defined in Table 9.4, specifying that the representation on the wire should be NTP.

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

Section 9.6.2.2.2, Table 9.12: Specify IPv4Address_t and Port_t

  • Legacy Issue Number: 16981
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 183-184
    Change: IPv4Address_t and Port_t are not defined anywhere in the specification

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    *Deprecate PIDs *

    There are a number of PIDs for address and port fields that are no longer necessary or used since the information that they identify is sent in the form of a Locator, we are therefore deprecating these PIDs:
    PID_MULTICAST_IPADDRESS
    PID_DEFAULT_UNICAST_IPADDRESS
    PID_DEFAULT_UNICAST_PORT
    PID_METATRAFFIC_UNICAST_IPADDRESS
    PID_METATRAFFIC_UNICAST_PORT
    PID_METATRAFFIC_MULTICAST_IPADDRESS
    PID_METATRAFFIC_MULTICAST_PORT

    PID_PARTICIPANT_BUILTIN_ENDPOINTS is also not used and will be deprecated. Implementations are using PID_BUILTIN_ENDPOINT_SET instead.

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

Section 9.6.2.2: What is the "key" parameter?

  • Legacy Issue Number: 16980
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 182
    Change: This section refers to a non-existent "key parameter" in the Data submessage.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify what the "key" parameter in section 9.6.2.2 is referring to

    In section 9.6.2.2 the phrase '"key" parameter' is referring to the parameters listed in table 9.10, the language used to indicate this should be clarified.

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

Section 9.6.2.2: Describe key-only encoding of built-in data types

  • Legacy Issue Number: 16979
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 181
    Change: This section under-specifies the key fields for all four data types. The "inherited" DDS structures do not provide a key field that is useful for RTPS because it is vendor-specific. This section should describe what a "key only" (KeyFlag==1) Data Submessage should contain as its payload for both SPDP and for all 3 types of SEDP. Table 9.13 indicates that Built-In Topic Keys can be encoded as a GUID, which has no correspondence to the actual definition of Built-In Topic Keys.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Describe the contents of the key-only Data Submessage for each of the Builtin Topic Types

    Descriptions have been added to clarify that a key-only submessage for each of the Built-in Topic types requires:
    PID_PARTICIPANT_GUID (for SPDP)
    PID_ENDPOINT_GUID (for SEDP)

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

Section 9.6.2.2: Duration_t used in IDL, not defined

  • Legacy Issue Number: 16978
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 181
    Change: Duration_t (used for leaseDuration) is not defined in the PSM. Use Time_t instead?

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Duplicates DDSIRTP23-10

    Merged with DDSIRTP23-10

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

Section 8.7.6: RTPS support for semantics not present in DDS

  • Legacy Issue Number: 16970
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 147
    Change: There is no such "directed" or "peer-to-peer" function described by the DDS spec, therefore none is available to the user. If such a function should be used by RTPS to implement DDS communication, its use by RTPS must be described here. Otherwise remove this section.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Remove explicit dependency on DDS api

    Accept suggested approach of editing section 8.7 to remove explicit dependency on DDS APIs

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

Section 8.5.3.2, Table 8.73: Make defaultUnicastLocatorList optional

  • Legacy Issue Number: 16969
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 127
    Change: In the row for defaultUnicastLocatorList, "at least one Locator must be present" constrains implementations unnecessarily. As long as each Endpoint has a locator, there is no need for the participant to have a default locator

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    Do not make the defaultUnicastLocatorList optional

    As the proposed change breaks backwards compatibility, the decision has been made to defer this issue to a major revision of the protocol. The label RTPS3 has been added to indicate this and to aid in future searches of issues like this one.

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

Section: 8.5.3.2, Figure 8.27 and Table 8.73

  • Legacy Issue Number: 16968
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 126-127
    Change: In the figure and the table, BuiltinEndpointSet_t is already a "set" so it should not also be an array with "[*]"

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Closed; Out Of Scope — DDSI-RTPS 2.3
  • Disposition Summary:

    Already fixed in 2.2

    Already fixed in 2.2

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

Section 8.4.15.7: Scope of the count fields of Heartbeat and AckNack/NackFrag

  • Legacy Issue Number: 16967
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 123
    Change: Scope of counts is underspecified: is a Heartbeat count scoped to one Writer; is an AckNack/NackFrag count scoped to a Reader itself or to a Reader's conversation with a given Writer?

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify the scope of the HeartBeat and AckNack Submessage Count fields and how to deal with overflow in the count fields

    The scope of the count fields of the HeartBeat and AckNack have been clarified to make it clear that it is up to the implementation if it keeps track of each endpoint separately or reuses the epoch across endpoints as long as the epoch changes from the previous one sent to an endpoint.

    Clarification as to how overflow in these fields should be handled by an implementation has also been added.

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

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

  • Legacy Issue Number: 19694
  • Status: closed  
  • 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Reserve protocol and vendor specific ranges for the Locator_t kind

    To avoid future conflicts with vendor-specific Locator_t kinds, ranges have been reserved for the protocol, for vendors, and for users.
    0x00000003 - 0x000001f are reserved for vendors
    0x00000020 - 0x00007ffff for future use by the spec.
    0x00008000-0x01FFFFFF (inclusive) for use by vendors.
    0x02000000 and greater are reserved for third-party add-ons

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

Some constants specified in PSM table 9.4 conflict with the ones used in wireshark

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

    In table 9.4 the the PSM RTPS define ReliabilityKind_t defines RELIABLE as having the value 3. However the Wireshark packet dissector defines ReliabilityKind_t RELIABLE as having the value 2.

    In table 9.4 the PSM RTPS specification defines LOCATOR_KIND_UDPv6 having the value 2. However the Wireshark packet dissector defines LOCATOR_KIND_UDPv6 as having the value 8.

    The vendors interoperate and used Wireshark to fine-tune their discovery therefore they are actually using the Wireshark-defined values rather than the ones in table 9.4

    Proposed resolution:

    Modify Table 9.4 entry for ReliabilityKind_t from:
    #define RELIABLE 3

    to
    #define RELIABLE 2

    Modify Table 9.4 entry for Locator_t from:
    #define LOCATOR_KIND_UDPv6 2

    to
    #define LOCATOR_KIND_UDPv6 8

  • Reported: DDSI-RTPS 2.0b1 — Thu, 3 Jul 2014 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    *Change the value of RELIABLE_RELIABILITY and add a description of how it is marshalled *

    RELIABLE_RELIABILITY is currently defined with the value 3, however in practice all implementations are using 2, so the value has been changed in the spec.

    It was also noted that the values in the RTPS spec differ from the API-level values defined in the DDS spec. Therefore, a description of how to marshal the DDS-defined ReliabilityQosPolicy on the wire.

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

Sending a HeartBeat message when there is no data is unspecified

  • Status: closed  
  • 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
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update the definition of the HeartBeat Submessage to allow situations in which the Writer has no data to announce

    The HeartBeat submessage has been updated to better handle the situation in which a Writer has no data in its cache to announce.

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

Link to RTPS VendorId web page is broken

  • Status: closed  
  • Source: MORSE-Corp ( Eddy Scott)
  • Summary:

    The web link pointed to by the specification: http://www.omgwiki.org/dds/content/page/dds-rtps-vendor-andproduct-ids results in a page not found returned from the server. A brief search of the internet for the list of VendorIds results in nothing found.

  • Reported: DDSI-RTPS 2.2 — Tue, 29 Aug 2017 14:29 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    *Update URL for assigned vendor ids *

    The URL for the assigned vendor and product IDs has been updated to point to a valid location with that information.

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

Rename BuiltinEndpointKind and add description

  • Legacy Issue Number: 11034
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    This type is actually a set of boolean flags and so should be renamed to reflect its actual intention. Additionally, the description for this type is missing from Table 9.4.

    Proposed Resolution:
    Rename the type from BuiltinEndpointKind to BuiltinEndpointSet_t. Provide an entry in Table 9.4 to describe the type.

    Revised Text:
    In Table 8.77, the third row from the end (the cell in the first column reads "availableBuiltinEndpoints"), replace "BuiltinEndpointKind" with "BuiltinEndpointSet_t."

    Replace Figure 8.26 with:

    In Table 9.4, add the following row to the end of the table:

    BuiltinEndpointSet_t Mapping of the type
    typedef unsigned long BuiltinEndpointSet_t;
    where
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_ANNOUNCER 0x00000001 << 0;
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_DETECTOR 0x00000001 << 1;
    #define DISC_BUILTIN_ENDPOINT_PUBLICATION_ANNOUNCER 0x00000001 << 2;
    #define DISC_BUILTIN_ENDPOINT_PUBLICATION_DETECTOR 0x00000001 << 3;
    #define DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_ANNOUNCER 0x00000001 << 4;
    #define DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_DETECTOR 0x00000001 << 5;
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_ANNOUNCER 0x00000001 << 6;
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_DETECTOR 0x00000001 << 7;
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_ANNOUNCER 0x00000001 << 8;
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_DETECTOR 0x00000001 << 9;
    #define BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_WRITER 0x00000001 << 10;
    #define BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_READER 0x00000001 << 11;

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    This issue was already resolved

    This issue was already resolved as part of the first FTF. It must have been incorrectly imported when tranitioning to Jira

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

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 ( Ken 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 ( Ken 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 ( Ken 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 ( Ken 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 ( Ken 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 ( Ken 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 ( Ken 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 ( Ken 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 ( Ken 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

Add Parameter ID for Original Writer Info

  • Legacy Issue Number: 11075
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    In order to implement the DDS DURABILITY Persistent QoS, a persistence-service needs to send the data that has been received and stored on behalf of the persistent writer.

    The service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    Resolution:
    Introduce a new parameter Id, ORIGINAL_WRITER_INFO, that can appear in parameter lists.

    Revised Text:

    Add to table 9.4:

    Type PSM Mapping
    OriginalWriterInfo_t struct

    { GUID_t originalWriterGUID; SequenceNumber_t originalWriterSN; ParameterList originalWriterQos;}

    OriginalWriterInfo;

    Append to table 9.13:
    Name ID Type
    PID_ORIGINAL_WRITER_INFO 0x0061 OriginalWriterInfo_t

    Add new section:

    8.7.6 Original Writer Info

    A service supporting the Persistent level of DDS Durability QoS needs to send the data that has been received and stored on behalf of the persistent writer.

    This service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    The RTPS protocol supports this forwarding of messages by including information of the original writer.

    OriginalWriterInfo_t
    attribute type value
    originalWriterGUID GUID_t the GUID of the RTPS Writer that first generated the message
    originalWriterSN SequenceNumber_t the Sequence Number of the CacheChange as sent from the original writer
    originalWriterQos ParameterList the list of inline parameters that should apply to the CacheChange as sent by the RTPS Writer that first generated the sample

    When a RTPS reader receives this information it will treat it as a normal CacheChange, but once the CacheChange is ready to be commited to the DDS DataReader, it will not commit it. Instead, it will hand it off to the HistoryCache of the RTPSReader that is communicating with the RTPSWriter indicated in the ORIGINAL_WRITER_INFO inline-Qos and treat it as having the sequence number which appears there and the ParameterList also included in the ORIGINAL_WRITER_INFO.

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    No Data Available

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

Add Max Sample Size Serialized Parameter Id

  • Legacy Issue Number: 11074
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A type's maximum serialized size may be included in a parameter list. A new parameter Id should be added.

    Resolution:
    Add parameter Id for Type Max Sample Size Serialized

    Revised Text:

    Append to Table 9.11:
    Name ID Type
    PID_TYPE_MAX_SIZE_SERIALIZED 0x0060 long

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    No Data Available

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

Clarify Writer liveliness mechanism

  • Key: DDSIRTP2-5
  • Legacy Issue Number: 11031
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The current Writer liveliness mechanism piggybacks on SPDP messaging. As RTPS should also be able to support other discovery protocols beyond SPDP, including a static configuration, this is not the best approach.
    It is true that all implementations must support at least SPDP, but if a customer wants to disable it (e.g. no need to interoperate with a different vendor so it possible to use a different protocol exclusively), this should not affect the DW liveliness mechanism. To some extent, it does not, but sending SPDPDiscoveredParticipantData to maintain a DWs liveliness is wasteful, especially if SPDP is not even used.
    Resolution:
    Update the Writer liveliness protocol to be independent of Discovery.
    Revised Text:
    Since this change is lengthy, the editorial instructions appear in a blue font to help the reader distinguish them from document content.

    · Section 8.7.2.2.3, first paragraph, first bulleted item, replace:

    DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the SPDPbuiltinParticipantWriter. For a given Participant, in order to maintain the liveliness of its Writer Entities with LIVELINESS QoS set to AUTOMATIC, implementations must refresh the Participant's liveliness (i.e., send the SPDPDiscoveredParticipantData) at a rate faster than the smallest lease duration among the Writers.

    with:

    DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. For a given Participant, in order to maintain the liveliness of its Writer Entities with LIVELINESS QoS set to AUTOMATIC, implementations must refresh the Participant's liveliness (i.e., send the ParticipantMessageData, see Section 8.4.13.5 for details) at a rate faster than the smallest lease duration among the Writers.

    · Section 8.7.2.2.3, first paragraph, first bulleted item, replace:

    DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS : liveliness is maintained through the SPDPbuiltinParticipantWriter. If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant's liveliness (i.e send the SPDPDiscoveredParticipantData) and add the PID_PARTICIPANT_MANUAL_LIVELINESS_COUNT in-line QoS, where the value of the in-line QoS is incremented each time.

    with:

    DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant's liveliness (i.e send the ParticipantMessageData, see Section 8.4.13.5 for details).

    · Section 8.5.2, change the title from "RTPS built-in Endpoints" to "RTPS built-in Discovery Endpoints"
    · Add the following row to the end of Table 8.50:

    ParticipantMessageData Type used to hold data exchanged between Participants. The most notable use of this type is for the Writer Liveliness Protocol.

    · Insert new Section following 8.4.12 (so a new 8.4.13) with the following content:

    8.4.13 Writer Liveliness Protocol
    The DDS specification requires the presence of a liveliness mechanism. RTPS realizes this requirement with the Writer Liveliness Protocol. The Writer Liveliness Protocol defines the required information exchange between two Participants in order to assert the liveliness of Writers contained by the Participant.

    All implementations must support the Writer Liveliness Protocol in order to be interoperable.

    8.4.13.1 General Approach
    The Writer Liveliness Protocol uses pre-defined built-in Endpoints. The use of built-in Endpoints means that once a Participant knows of the presence of another Participant, it can assume the presence of the built-in Endpoints made available by the remote participant and establish the association with the locally-matching built-in Endpoints.

    The protocol used to communicate between built-in Endpoints is the same as used for application-defined Endpoints.

    8.4.13.2 Built-in Endpoints required by the Writer Liveliness Protocol
    The built-in Endpoints required by the Writer Liveliness Protocol are the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. The names of these Endpoints reflect the fact that they are general-purpose. These Endpoints are used for liveliness but can also be used for other data in the future.

    The RTPS Protocol reserves the following values of the EntityId_t for these built-in Endpoints:
    ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER
    ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER

    The actual value for each of these EntityId_t instances is defined by each PSM.

    8.4.13.3 BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader QoS
    For interoperability, both the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader use the following QoS values:
    · reliability.kind = RELIABLE_RELIABILITY_QOS
    · durability.kind = TRANSIENT_LOCAL_DURABILITY_QOS
    · history.kind = KEEP_LAST_HISTORY_QOS
    · history.depth = 1

    8.4.13.4 Data Types associated with the built-in Endpoints used by the Writer Liveliness Protocol

    Each RTPS Endpoint has a HistoryCache that stores changes to the data-objects associated with the Endpoint. This is also true for the RTPS built-in Endpoints. Therefore, each RTPS built-in Endpoint depends on some DataType that represents the logical contents of the data written into its HistoryCache.

    Figure X defines the ParticipantMessageData DataType associated with the RTPS built-in Endpoints for the "DCPSParticipantMessage" Topic.

    Figure X The ParticipantMessageData structure.

    8.4.13.5 Implementing the Writer Liveliness Protocol using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader

    The liveliness of a subset of Writers belonging to a Participant is asserted by writing a sample to the BuiltinParticipantMessageWriter. If the Participant contains one or more Writers with a liveliness of AUTOMATIC_LIVELINESS_QOS then one sample is written at a rate faster than the smallest lease duration among the Writers sharing this QoS. Similarly, a separate sample is written if the Participant contains one or more Writers with a liveliness of MANUAL_BY_PARTICIPANT_LIVELINESS_QOS at a rate faster than the smallest lease duration among these Writers. The two instances are orthogonal in purpose so that if a Participant contains Writers of each of the two liveliness kinds described, two separate instances must be periodically written. The instances are distinguished using their DDS key which is comprised of the participantGuidPrefix and the kind fields. Each of the two types of liveliness QoS handled through this protocol will result in a unique kind field and therefore form two distinct instances in the HistoryCache.

    In both liveliness cases the participantGuidPrefix field contains the GuidPrefix_t of the Participant that is writing the data (and therefore asserting the liveliness of its Writers).

    The DDS liveliness kind MANUAL_BY_TOPIC_LIVELINESS_QOS is not implemented using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. It is discussed in Section 8.7.2.2.3.

    · Add the following entries to Table 9.2

    BuiltinParticipantMessageWriter ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER =

    {00,02,00,C2}

    BuiltinParticipantMessageReader ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER =

    {00,02,00,C7}

    · Insert a new Section 9.6.2.1 with the following content:

    9.6.2.1 Data representation for the ParticipantMessageData built-in Endpoints
    The Behavior Module within the PIM (Section 8.4) defines the DataType ParticipantMessageData. This type is the logical content of the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader built-in Endpoints.

    The PSM maps the ParticipantMessageData type into the following IDL:

    struct ParticipantMessageData

    { KeyHashPrefix_t participantGuidPrefix; KeyHashSuffix_t kind; sequence<octet> data; }

    ;

    The DDS key consists of the both the participantGuidPrefix and the kind fields. On the wire, the participantGuidPrefix and the kind are not serialized as part of the ParticipantMessageData because they are already explicitly serialized as part of the Data Submessage (see Section 8.3.7.2).

    The following values for the kind field are reserved by RTPS:

    #define PARTICIPANT_MESSAGE_DATA_KIND_UNKNOWN

    {0x00,0x00,0x00,0x00}

    #define PARTICIPANT_MESSAGE_DATA_KIND_AUTOMATIC_LIVELINESS_UPDATE

    {0x00,0x00,0x00,0x01}

    #define PARTICIPANT_MESSAGE_DATA_KIND_MANUAL_LIVELINESS_UPDATE

    {0x00,0x00,0x00,0x02}

    RTPS also reserves for future use all values of the kind field where the most significant bit is not set. Therefore:

    kind.value[0] & 0x80 == 0 // reserved by RTPS
    kind.value[0] & 0x80 == 1 // vendor specific kind

    Implementations can decide the upper length of the data field but must be able to support at least 128 bytes.

    Following the CDR encoding, the wire representation of the ParticipantMessageData structure is:

    0...2...........8...............16.............24...............31
    ------------------------------------------------------+

    unsigned long data.length

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

     

    ~ octet[] data.value ~

     

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

    · Insert a new Section called 9.6.2.2
    Use the contents of Section 9.6.2 from the start until the beginning of Section 9.6.2.1

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change structure of (Nokey)DataFrag

  • Key: DDSIRTP2-4
  • Legacy Issue Number: 11030
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    (NOKEY_)DATA_FRAG PSM submessage definition should be modified to place inlineQos AFTER fragmentation related parameters to simplify an implementation based on gather send.
    Resolution:
    Reposition the inlineQos field to be consistent with other messages, implementation simplicity, and higher performance.
    Revised Text:
    · Section 9.4.5.4, change
    0...2...........8...............16..............24..............32
    +

    NOKEY_DATA_FRAG X X X X X X Q E octetsToNextHeader

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

    EntityId readerId

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

    EntityId writerId

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

     

    + SequenceNumber writerSN +

     

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

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

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

    FragmentNumber fragmentStartingNum

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

    ushort fragmentsInSubmessage ushort fragmentSize

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

    unsigned long sampleSize

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

     

    ~ SerializedData serializedData ~

     

    ------------------------------------------------------+
    to
    0...2...........8...............16..............24..............32
    +

    NOKEY_DATA_FRAG X X X X X X Q E octetsToNextHeader

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

    EntityId readerId

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

    EntityId writerId

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

     

    + SequenceNumber writerSN +

     

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

    FragmentNumber fragmentStartingNum

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

    ushort fragmentsInSubmessage ushort fragmentSize

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

    unsigned long sampleSize

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

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

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

     

    ~ SerializedData serializedData ~

     

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

    · Section 9.4.5.6, change
    0...2...........8...............16..............24..............32
    +

    DATA_FRAG X X X X X H Q E octetsToNextHeader

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

    EntityId readerId

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

    EntityId writerId

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

     

    + SequenceNumber writerSN +

     

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

     

    + +

    KeyHashPrefix keyHashPrefix [only if H==1]

    + +

     

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

    KeyHashSuffix keyHashSuffix

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

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

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

    FragmentNumber fragmentStartingNum

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

    ushort fragmentsInSubmessage ushort fragmentSize

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

    unsigned long sampleSize

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

     

    ~ SerializedData serializedData ~

     

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

    to

    0...2...........8...............16..............24..............32
    +

    DATA_FRAG X X X X X H Q E octetsToNextHeader

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

    EntityId readerId

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

    EntityId writerId

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

     

    + SequenceNumber writerSN +

     

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

     

    + +

    KeyHashPrefix keyHashPrefix [only if H==1]

    + +

     

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

    KeyHashSuffix keyHashSuffix

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

    FragmentNumber fragmentStartingNum

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

    ushort fragmentsInSubmessage ushort fragmentSize

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

    unsigned long sampleSize

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

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

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

     

    ~ SerializedData serializedData ~

     

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

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add SerializedDataFragment as Submessage Element

  • Key: DDSIRTP2-7
  • Legacy Issue Number: 11033
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Encapsulation of serialized data should be the responsibility of the plug-in. Even though the protocol does not need to interpret the data stream, in the case of fragmented data, the data encapsulation header need only be pre-pended to the first fragment. Further fragments don't need the encapsulation header.
    Resolution:
    Add a new SubmessageElement subclass called SerializedDataFragment.

    Revised Text:

    Renumber 8.3.5.15 (StatusInfo) to 8.3.5.16, and add new section 8.3.5.15

    8.3.5.15 SerializedDataFragment

    SerializedDataFragment contains the serialized representation of a the value of a data-object that has been fragmented. Like for unfragmented SerializedData, the RTPS protocol does not interpret the fragmented serialized data-stream. Therefore, it is represented as opaque data. For additional information on data encapsulation, see Chapter 10.

    Add table 8.32 - Structure of the SerializedDataFragment SubmessageElement
    field type meaning
    value octet[*] Serialized data-stream fragment

    Replace Figure 8.12 with :

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    for updated figure see page 27 of ptc/2007-06-02

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Version number should be 2.0

  • Key: DDSIRTP2-6
  • Legacy Issue Number: 11032
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The extensions made to the protocol break backwards compatibility and therefore the major version should be changed not the minor version.
    Resolution:
    Change the version number from 1.2 to 2.0.
    Revised Text:
    Change "1.2" to "2.0" in the following locations:
    · Table 8.13, 5th row (first cell reads "SubmessageKind"), the cell in the second column
    · Section 8.3.3.1.2, first paragraph, first sentence.
    · Section 8.3.4.1, numbered item 3, second sentence

    {note: two occurrences in this sentence}

    · Section 8.3.4.1, numbered item 4, third sentence.
    · Section 8.3.5, first paragraph, second sentence
    · Section 8.3.5.3, second paragraph (right after Table 8.20), first sentence
    · Section 8.3.5.9, within the bulleted items following the second paragraph
    o the second sentence in the second bulleted item
    o the second sentence in the third bulleted item
    · Section 8.3.7, first paragraph, first sentence
    · Section 8.6, first paragraph, first sentence
    · Section 9.3.1.2, last paragraph (right before Table 9.1), second sentence
    · Section 9.3.1.4, the title
    · Section 9.3.1.4, first paragraph, first and second sentences
    · Table 9.3, the caption
    · Section 9.4.2.11, last paragraph, first (and only) sentence
    · Section 9.4.5.1.1, first paragraph, last sentence
    · Section 9.4.5.1.2, last paragraph, first and second sentences
    · Section 9.6.4, the title
    · Section 9.6.4, first paragraph, first and second sentences

    Other changes:
    · Table 8.2, 6th row (cell in first column reads "ProtocolVersion_t"), the cell in the second column, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
    o NOTE: there are two instances of this change in this cell.
    · Table 8.16, 2nd row (cell in first column reads "sourceVersion"), the cell in the second column, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
    · Section 8.3.3.1.2, change "(major = 1, minor = 2)" to "(major = 2, minor = 0)"
    · Section 8.3.5.3, second paragraph, within the list of special values, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
    · Section 8.6, first paragraph, first sentence, change "(1)" to "(2)"
    · Section 9.3.1.2, last paragraph (right before Table 9.1), third sentence, change "(1)" to "(2)"
    · Table 9.4, 5th row (first cell contains "ProtocolVersion_t")
    change:

    #define PROTOCOLVERSION_1_2

    {1,2}
    #define PROTOCOLVERSION {1,2}

    to:

    #define PROTOCOLVERSION_2_0

    {2,0}
    #define PROTOCOLVERSION {2,0}

    also, in the last sentence, change "version 1.2 (major = 1, minor = 2)" to "version 2.0 (major = 2, minor = 0)"
    · Section 8.3.3.1, last paragraph, first (and only) sentence, change "(1)" to "(2)"
    · Section 8.3.3.2, last paragraph (following Table 8.15), first (and only) sentence, change "(1)" to "(2)"
    · Section 8.3.3.2.1, second paragraph, first sentence, change "(1)" to "(2)"
    · Section 9.3.1.3, second paragraph, third sentence, change "(1)" to "(2)"
    · Section 9.4.4, second paragraph, change "(1)" to "(2)"
    · Section 9.4.5.1, second to last paragraph, first (and only) sentence, change "(1)" to "(2)"
    · Section 9.4.5.1.1, second paragraph, first sentence, change "(1)" to "(2)"

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove length field in encapsulation chapter

  • Key: DDSIRTP2-3
  • Legacy Issue Number: 11029
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The protocol should clarify the sequence number of a writer's first sample. Currently, this is not specified in 8.3.5.4. Rather, it is implied by 8.3.5.5 which states that a sequence number set contains sequence numbers >= 1. The same issue applies for a fragment number.
    Resolution:
    Explicitly state that the sequence number of a writer's first sample or fragment is 1.
    Revised Text:
    · Section 8.3.5.4, first paragraph, append text

    Sequence numbers begin at 1.

    · Section 8.3.5.6, first paragraph, append text

    Fragment numbers begin at 1.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide default timing parameters

  • Key: DDSIRTP2-2
  • Legacy Issue Number: 11028
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    For out-of-the-box interoperability, we should provide default timing parameters for the reliability protocol.
    Resolution:
    Provide default timing parameters for the reliability protocol.
    Revised Text:
    · Add a new Section 8.4.7.1.1 titled "Default Timing-RelatedValues" with the following content:

    The following timing-related values are used as the defaults in order to facilitate 'out-of-the-box' interoperability between implementations.
    nackResponseDelay.sec = 0;
    nackResponseDelay.nanosec = 200 * 1000 * 1000; // 200 milliseconds
    nackSuppressionDuration.sec = 0;
    nackSuppressionDuration.nanosec = 0;

    · Add a new Section 8.4.10.1.1 title "Default Timing-Related Values" with the following content (NOTE: heartbeatSuppressionDuration does not currently exist in RTPS but is added through issue R#7) :

    The following timing-related values are used as the defaults in order to facilitate 'out-of-the-box' interoperability between implementations.
    heartbeatResponseDelay.sec = 0;
    heartbeatResponseDelay.nanosec = 500 * 1000 * 1000; // 500 milliseconds
    heartbeatSuppressionDuration.sec = 0;
    heartbeatSuppressionDuration.nanosec = 0;

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS DURABILITY Persistent QoS

  • Legacy Issue Number: 11053
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    In order to implement the DDS DURABILITY Persistent QoS, a persistence-service needs to send the data that has been received and stored on behalf of the persistent writer.

    The service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    Resolution:
    Introduce a new parameter Id, ORIGINAL_WRITER_INFO, that can appear in parameter lists.

    Revised Text:

    Add to table 9.4:

    Type PSM Mapping
    OriginalWriterInfo_t struct

    { GUID_t originalWriterGUID; SequenceNumber_t originalWriterSN; ParameterList originalWriterQos;}

    OriginalWriterInfo;

    Append to table 9.13:
    Name ID Type
    PID_ORIGINAL_WRITER_INFO 0x0061 OriginalWriterInfo_t

    Add new section:

    8.7.6 Original Writer Info

    A service supporting the Persistent level of DDS Durability QoS needs to send the data that has been received and stored on behalf of the persistent writer.

    This service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    The RTPS protocol supports this forwarding of messages by including information of the original writer.

    OriginalWriterInfo_t
    attribute type value
    originalWriterGUID GUID_t the GUID of the RTPS Writer that first generated the message
    originalWriterSN SequenceNumber_t the Sequence Number of the CacheChange as sent from the original writer
    originalWriterQos ParameterList the list of inline parameters that should apply to the CacheChange as sent by the RTPS Writer that first generated the sample

    When a RTPS reader receives this information it will treat it as a normal CacheChange, but once the CacheChange is ready to be commited to the DDS DataReader, it will not commit it. Instead, it will hand it off to the HistoryCache of the RTPSReader that is communicating with the RTPSWriter indicated in the ORIGINAL_WRITER_INFO inline-Qos and treat it as having the sequence number which appears there and the ParameterList also included in the ORIGINAL_WRITER_INFO.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ChangeKind Has DDS Relationship

  • Legacy Issue Number: 11052
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Table 8.5 incorrectly shows a ChangeKind_t as having no applicable relation to DDS. Rather, the instance state kind of being disposed and unregistered are related to ChangeKind_t.

    Resolution:
    Revise table 8.5 to show the relationship between CacheChange kind and DDS instance state kind.

    Revised Text:
    Revise table 8.5:
    Attribute Type Meaning Relation to DDS
    kind ChangeKind_t Identifies the kind of change. See Table 8.2 DDS instance state kind

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify GAP usage

  • Legacy Issue Number: 11051
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Clarify that GAPs should be used only when a sample is not meaningful and not sent in the first place (e.g. filtered out).
    Resolution:
    Clarify GAP usage.

    Revised Text:
    Revise 8.3.7.4.5:

    The RTPS Writer sends the Gap message to the RTPS Reader to communicate that certain sequence numbers are no longer relevant. This is typically caused by the KEEP_LAST setting of the History QoS on the corresponding DDS DataWriter. This is typically caused by Writer-side filtering of the sample (content-filtered topics, time-based filtering). In this scenario, new data-values may replace the old values of the data-objects that were represented by the sequence numbers that appear as irrelevant in the GAP.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TOPICNAME parameter appears in PSM but not in PIM

  • Legacy Issue Number: 11065
  • Status: closed  
  • Source: Real-Time Innovations ( Reinier Torenbeek)
  • Summary:

    Summary:
    Table 9.13 in section 9.6.3 contains a parameter called PID_TOPIC_NAME as one of the in-line QoS settings. This parameter is not mentioned in the PIM.
    Resolution:
    First extend section 8.7.1 explaining the rationale behind in-line QoS data. This is addressed in OMG issue #11050 already. Then add the TOPICNAME parameter in section 8.7.2.1.
    Revised Text:
    · Section 8.7.2.1, add the following sentence :
    In-line parameters are added to data sub-messages to make them self-describing. In order to achieve self-describing sub-messages, not only the parameters defined in table 8.7.2.1 have to be sent with the sub-message, but also a parameter TOPICNAME. This parameter contains the name of the topic that the sub-message belongs to.

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Elaborate on Necessity and Usage of In-line QoS

  • Legacy Issue Number: 11050
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The RTPS specification state which QoS can appear in-line but does not offer background information to justify their usage. The specification should elaborate on how in-line QoS are required for stateless implementations.

    Resolution:
    Elaborate on necessities and justifications for having in-line QoS to support stateless implementations.

    Revised Text:
    Revise 8.7.1, insert starting as third paragraph:

    A stateless Reader's need for receiving in-line QoS to get information on remote Writers is the justification for requiring a writer to send in-line QoS if the reader requests them (section 8.4.2.2.2).

    For immutable QoS, all RxO QoS are sent in-line to allow a stateless reader to reject samples in case of incompatible QoS. Mutable QoS relevant to the reader are sent in-line so they may take effect immediately, regardless of the amount of state kept on the reader. Note that a stateful reader has the option of relying on its cached information of remote writers rather than received in-line QoS.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify Data Encapsulation Schemes

  • Legacy Issue Number: 11049
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Data encapsulation for Serialized Data Fragments needs differentiation from data encapsulation of serialized data. Fragmentation should be done after encapsulation of large serialized data. Rather than having an encapsulation header for each fragment, only a single encapsulation header is needed, as this is used after the sample has been reconstituted from its fragments. The specification of data encapsulation schemes should describe this.

    Also, in Sections 10.1.1-2, the length field of the data encapsulation schemes shown in the submessage diagrams are unnecessary, because the serialized data and fragments already contain sufficient information to determine the length of data. Instead, the field should be designated for data encapsulation scheme-specific options.
    Resolution:
    Replace the length field of the standard data encapsulation schemes with a scheme-specific option field.

    Define fragmentation as happening after encapsulation of a large data sample.

    Revised Text:
    · Section 10.1.1.2
    WAS
    0...2...........8...............16..............24..............32
    +

    CDR_BE ushort length

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

     

    ~ Serialized Data (CDR Big Endian) ~

     

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

    0...2...........8...............16..............24..............32
    +

    CDR_LE ushort length

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

     

    ~ Serialized Data (CDR Little Endian) ~

     

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

    NOW:
    0...2...........8...............16..............24..............32
    +

    CDR_BE ushort options

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

     

    ~ Serialized Data (CDR Big Endian) ~

     

    ------------------------------------------------------+
    Fragmentation is done after encapsulation of large serialized data.

    0...2...........8...............16..............24..............32
    +

    CDR_LE ushort options

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

     

    ~ Serialized Data (CDR Little Endian) ~

     

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

    · Section 10.1.1.3
    WAS:
    0...2...........8...............16..............24..............32
    +

    PL_CDR_BE ushort length

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

     

    ~ Serialized Data (ParameterList CDR Big Endian) ~

     

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

    0...2...........8...............16..............24..............32
    +

    PL_CDR_LE ushort length

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

     

    ~ Serialized Data (ParameterList CDR Little Endian) ~

     

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

    NOW:
    0...2...........8...............16..............24..............32
    +

    PL_CDR_BE ushort options

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

     

    ~ Serialized Data (ParameterList CDR Big Endian) ~

     

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

    0...2...........8...............16..............24..............32
    +

    PL_CDR_LE ushort options

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

     

    ~ Serialized Data (ParameterList CDR Little Endian) ~

     

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

    Fragmentation is done after encapsulation of large serialized data, so a SerializedDataFragment may contain the encapsulation header of its larger opaque SerializedData sample.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify implementing Count submessage element

  • Legacy Issue Number: 11040
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The use of the count submessage element is not fully explained.

    For heartbeats, the Count element differentiates logical heartbeats, so heartbeats with the same count as a previously received heartbeat can be ignored to prevent triggering duplicate repair sessions. Also, old heartbeats with count less than previously received counts should also be ignored. So, same logical heartbeats must not have the same count, and new heartbeats must have greater counts than older heartbeats.

    The same logic applies to counts of ACKNACKs.

    Resolution:
    Explain proper usage of the count element of Heartbeats and ACKNACKs.

    Revised Text:
    Add new section:

    8.4.14.6 Setting Count of Heartbeats and ACKNACKs
    The count element of Heartbeats differentiates logical heartbeats. A received heartbeat with the same count as a previously received heartbeat can be ignored to prevent triggering a duplicate repair seesion. So, an implementation should ensure same logical heartbeats are tagged with the same count.

    Also, new heartbeats should have counts greater than all older heartbeats. Then, received heartbeats with counts less than or equal to any previously received can be ignored.

    The same logic applies for counts of ACKNACKs: each logical ACKNACK

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reclaiming finite resources from inactive readers

  • Legacy Issue Number: 11039
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The specification should describe how finite resources impact reliable communications.

    Writer queue resources should be reclaimed when no remote reader needs the corresponding sample. This means at least samples that have been fully acknowledged may be reclaimed. However they may exist unresponsive readers that are alive but for some reason never acknowledge the writer. To enable a writer to reclaim resources in this case, we define the notion of inactive Readers. If a reader is detected to be unresponsive through some mechanism (for example, when not responding to successive Heartbeats), the reader is deemed inactive. Then, samples that have been fully acknowledged by all active readers may be reclaimed. The writer should continue sending new samples and Heartbeats to inactive readers, but the writer need not hold onto old samples that were not acknowledged by inactive readers. The specification must note that strict reliability is no longer guaranteed when a reader becomes inactive.

    Resolution:
    Explain reliability in the presence of finite resources. Introduce and describe "isActive" reader attribute.

    Revised Text:
    Add new section
    8.4.14.6 Reclaiming Finite Resources from Unresponsive Readers

    An implementation likely has finite resources to work with. For a writer, reclaiming queue resources should happen when all readers have acknowledged a sample in the queue and resource limits dictate that the old sample entry is to be used for a new sample.

    There may be scenarios where an alive reader becomes unresponsive and will never acknowledge the writer. Instead of blocking on the unresponsive reader, the writer should be allowed to deem the reader as 'Inactive' and proceed in updating its queue. The state of a reader is either Active or Inactive. Active readers have sent ACKNACKs that have been recently received. The writer should determine the inactivity of a reader by using a mechanism based on the rate and number of ACKNACKs received. Then samples that have been acknowledged by all active readers can be freed, and the writer can reclaim those resources if necessary. Note that strict reliability is not guaranteed when a reader becomes inactive.

    Add to table 8.59 - RTPS ReaderProxy Attributes
    Attribute Type Meaning Relation to DDS
    isActive bool Specifies whether the remote reader is responsive to the writer. N/A

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Supporting Inline QoS by Stateful Readers

  • Legacy Issue Number: 11045
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Stateful readers should be allowed to rely on cached information propagated by discovery of remote writers. Thus, support for receiving and parsing inline QoS should be optional for stateful readers.

    In the case of mutable QoS, a tradeoff happens, where not parsing these inline QoS may delay the point in time when a new QoS takes effect, as it first must be propagated through discovery. A stateful implementation may expose this tradeoff to the user: minimize bandwidth usage by not sending mutated inline QoS or avoid this delayed effect of certain mutable QoS for guaranteed semantics.

    Resolution:
    Allow stateful implementations the choice of whether or not to parse inline QoS.

    Revised Text:
    Add as last paragraph of 8.7.1:

    Stateful implementations can ignore inline QoS and rely solely on cached values obtained through discovery in order to improve performance. Note that not parsing inline QoS may delay the point in time when a new QoS takes effect, as it first must be propagated through discovery

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Directed Write Parameter Id

  • Legacy Issue Number: 11044
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A directed write feature for tagging a sample with the GUID of the sample's single intended recipient must be supported with a new parameter Id to allow the GUID to be serialized as an inline parameter.

    Resolution:
    Add a new standard parameter Id, PID_DIRECTED_WRITE, with ID of 0x0057 and type of a sequence of GUIDs.

    Revised Text:
    Add following section:

    8.7.6 Directed Write
    Direct peer-to-peer communications may be enabled within the publish-subscribe framework of DDS by tagging samples with the handles of the intended recipient(s).

    RTPS supports directed writes by using the inline QoS parameter extension mechanism. The serialized information denotes the GUIDs of the targeted readers.

    When a writer sends such a directed sample, only the recipients with the matching parsed GUIDs accept the sample; all others acknowledge but absorb the sample, as if it was a GAP indicating a filtered sample.

    Append to Table 9.13:
    Name ID Type
    PID_DIRECTED_WRITE 0x0057 sequence<GUID_t>

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify interoperability requirement 8.4.2.3.3

  • Key: DDSIRTP2-9
  • Legacy Issue Number: 11037
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The requirement contained in Section 8.4.2.3.3 is too restrictive and doesn't specify when resources can be reclaimed. If all Readers have acknowledged a sample, the Writer should be allowed to reclaim that sample's resources. Also, if a Reader NACKs a sample it has already ACKed, and the Writer is still able to provide a repair, it should.
    Resolution:
    Allow Writer to reclaim resources and send repairs if possible.
    Revised Text:
    Add the paragraph to the end of Section 8.4.2.3.3:

    Once a Writer has received positive acknowledgement from all Readers, the Writer can reclaim any associated resources. However, if a Writer receives a negative acknowledgement to a previously positively acknowledged sample, and the Writer can still service the request, the Writer should send the sample.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify interoperability requirement 8.4.2.3.4

  • Key: DDSIRTP2-8
  • Legacy Issue Number: 11036
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Requirement 8.4.2.3.4 currently states "Readers can only send an ACKNACK Message in response to a HEARTBEAT message." This implies a reader may not poll for samples by unilaterally NACKing. This is true in general: the frequency and bandwidth of NACKs and associated repair messages is well maintained if controlled only by the writer. However, in the case when a Reader first finds out about a remote writer, before it receives any heartbeats, it may optionally send an ACKNACK to notify the writer. This can expedite communications between the new writer/reader pair, as the arrival time of the first heartbeat may be indeterminate.

    The rationale of writer-only control of NACK and associated repair messages should be incThis optimization should be noted within an implementation note.

    Resolution:
    Clarify requirement 8.4.2.3.4 to include the special case of a Reader first discovering a Writer.
    Revised Text:
    · Change the text of Section 8.4.2.3.4 to:

    In steady state, an ACKNACK Message can only be sent as a response to a HEARTBEAT Message from a Writer. ACKNACK Messages can be sent from a Reader when it first discovers a Writer as an optimization. Writers are not required to respond to these pre-emptive ACKNACK Messages.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interpreting Liveliness Heartbeats

  • Legacy Issue Number: 11043
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    For better performance and simpler reliability, a liveliness heartbeat should be allowed to be a liveliness-only message without heartbeat semantics. As subclassed from a heartbeat, a liveliness heartbeat may trigger an ACKNACK response; to be a liveliness-only message, no ACKNACKs should be triggered. To enable this, setting the final flag should not trigger ACKNACKs.

    Resolution:
    A liveliness heartbeat with final-flag set must not trigger any ACKNACKs.

    Revised Text:
    Append to 8.4.2.3.2:

    The response is not required when a liveliness HEARTBEAT has both liveliness and final flags set to indicate it is a liveliness-only message.

    Revise statechart 8.24:

    Revise Table 8.76 with revised transition:

    Transition state event next state
    T2 waiting HEARTBEAT message is received if (HB.FinalFlag==NOT_SET)then must_send_ackelse if (HB.LivelinessFlag == NOT_SET)then may_send_ackelse waiting

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify Writer Response to ACKNACK

  • Legacy Issue Number: 11042
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Requirement 8.4.2.2.4 should be clarified: a writer does not only respond with data or a GAP as stated. Rather, since a writer may have KEEP_LAST semantics and so may not offer the requested sample anymore, it may also respond with a new HB indicating the requested sample is no longer available. This is the mechanism to trigger a reader's onDataLost callback.

    Resolution:
    Clarify 8.4.2.2.4 to include a Writer's response of a HB to an ACKNACK requesting a sample that the writer does not have available.

    Revised Text:
    Revise first paragraph of 8.4.2.2.4:
    When receiving an ACKNACK Message indicating a Reader is missing some data samples, the Writer must respond by either sending the missing data samples, sending a GAP when the sample is not relevant, or sending a Heartbeat when the sample is no longer available.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Max Sample Size Serialized Parameter Id

  • Legacy Issue Number: 11048
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A type's maximum serialized size may be included in a parameter list. A new parameter Id should be added.

    Resolution:
    Add parameter Id for Type Max Sample Size Serialized

    Revised Text:

    Append to Table 9.11:
    Name ID Type
    PID_TYPE_MAX_SIZE_SERIALIZED 0x0060 long

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Property List Parameter Id

  • Legacy Issue Number: 11047
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    User definable name-value pairs can serve as a generic and extensible framework for DDS properties. These properties may be serialized in parameter lists and thus need a corresponding unique parameter Id.
    Resolution:
    Add parameter Id for Property List.
    Revised Text:
    Add section:

    8.7.5 Property Lists

    Property lists are lists of user-definable properties applied to a DDS Entity. An entry in the list is a generic name-value pair. A user defines a pair to be a property for a DDS Participant, DataWriter, or DataReader. This extensible list enables non-DDS specified properties to be applied.

    The RTPS protocol supports Property lists as inline parameters. Properties can then be propagated during discovery or as inline QoS.

    Append to Table 9.4:

    Type PSM Mapping
    Property_t struct

    { string name; string value;}

    Property_t

    Append to Table 9.11
    Name ID Type
    PID_PROPERTY_LIST 0x0059 sequence<Property_t>

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Define default multicast Reader behavior

  • Legacy Issue Number: 11038
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Currently, the specification does not state whether a multicast DataReader must also have a unicast locator or not.
    Resolution:
    A unicast locator should be supplied for multicast DataReaders so that repair sessions can be sent over unicast. If one is not provided directly, then the Participant's locator can be assumed.

    Revised Text:
    Revise following entry in Table 8.77 - RTPS SPDPdiscoveredParticipantData attributes:

    attribute type meaning
    defaultUnicastLocatorList Locator_t[1..*] Default list of unicast locators (transport, address, port combinations) that can be used to send messages to the user-defined Endpoints contained in the Participant.These are the unicast locators that will be used in case the Endpoint does not specify its own set of Locators, so at least one Locator must be present.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reader-side Heartbeat response suppression

  • Legacy Issue Number: 11041
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The specification does not prevent multiple Heartbeats from arriving in rapid succession. For example, the piggyback heartbeat of a repair message may immediately be followed by a periodic wildcard heartbeat. In order to prevent duplicate repair sessions, the specification should define heartbeat suppression on the reader's side. This heartbeat response suppression should be handled by a reader attribute that controls the duration for which duplicate heartbeats would be ignored.

    Resolution:
    Add reader attribute, heartbeatSuppressionDuration, that defines the duration in which received heartbeats are suppressed from triggering duplicate ACKNACKs.

    Revised Text:
    Revised figure 8.21:

    Revised table 8.66

    Attribute Type Meaning Relation to DDS
    heartbeatSuppressionDuration Duration_t Protocol tuning parameter that allows the RTPS Reader to ignore heartbeats that arrive 'too soon' after a previous heartbeat was received. N/A

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Entity Name Parameter Id

  • Legacy Issue Number: 11046
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A DDS entity name could be serialized within a parameter list, so a corresponding unique parameter Id should be assigned.
    Resolution:
    Add parameter Id for Entity Name.
    Revised Text:

    Type PSM Mapping
    EntityName_t struct

    { string name;}

    EntityName_t

    Append to Table 9.11:
    Name ID Type
    PID_ENTITY_NAME 0x0058 EntityName_t

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1.1.2, 10.1.1.3

  • Legacy Issue Number: 16989
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 194-195
    Change: Remove the paragraphs starting "In addition to, …" since its only purpose is to describe a non-existent length field.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Do as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.2, Table 9.4

  • Legacy Issue Number: 16975
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 153
    Change: In NTP, TIME_ZERO represents a point in time in 1900. If this was followed by RTPS with its 31-bit field for positive seconds, the maximum point in time would be in 1968, long before RTPS was invented. Therefore the meaning of TIME_ZERO must be specified here. Additionally, leaving only 31 bits for positive seconds and assuming 1970 is used as TIME_ZERO, RTPS times are only valid through 2038. Is there a need for a sign bit in “seconds”?

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The format used is similar to NTP in that is uses seconds and fractions of a second
    (to make arithmetic simple) rather than seconds and nanoseconds. However it uses
    a signed seconds such that signed arithmetic can be applied.
    For these reasons and to facilitate conversion to operating system times (timeval and
    timespec) the time origin TIME_ZERO is defined to be the Unix prime epoch 0h, 1
    January 1970

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.1.3, Table 9.2

  • Legacy Issue Number: 16974
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 151-152
    Change: All EntityId_t values should be shown with braces for the embedded array (see previous note)

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Change as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.4.5.1.3, Paragraph 3

  • Legacy Issue Number: 16977
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 169
    Change: This section refers to submessages larger than 64KB, which is impossible with UDP/IP.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    No change: It is true that this is not needed for the UDP/IP PSM, but it is something
    that would be useful in other PSMs. By leaving it here it becomes possible to have
    the other PSMs refer to this section verbatim without having to add or modify the text.
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.4.2.6 and 9.4.2.8 (last lines of each section)

  • Legacy Issue Number: 16976
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 163
    Change: The phase "does not follow strict CDR encoding" depends on an unspecified notion of "strict" vs. "nonstrict" CDR encoding where in actuality there is no such distinction. Remove the word "strict" to note that the wire representation is not following CDR rules. (This applies to both 9.4.2.6 and 9.4.2.8.)

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    see revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.6.3.3

  • Legacy Issue Number: 16985
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 192
    Change: The "register" Lifecycle operation is not discussed, should it be indicated with a zero value for StatusInfo_t? This should be explicit in the spec.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The ‘register” operation is currently described as a local operation on the writer side
    and there is nothing in the specification requiring or preventing it from being
    propagated. From the reader perspective the registration will occur automatically the
    first time data is received for a particular instance.
    Most implementations do not propagate registrations, but in case some
    implementation chooses to do that we should clarify what the StatusInfo_t flags that
    would be associated with the submessage.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.7.7

  • Legacy Issue Number: 16971
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 146
    Change: There is no such "property list" feature in the DDS spec, this section should be removed.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    There is an issue filed against the DDS spec to add these lists so once it is resolved
    this will no longer be an issue
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.4.1.1, Item 16

  • Legacy Issue Number: 16962
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 65
    Change: DDS has no "finish" operation on DataReader

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The operation should be called “return_loan”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1.1.1

  • Legacy Issue Number: 16987
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 193
    Change: This section should define the "options" field which is subsequently referenced.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This is resolved as part of resolving 16989
    Revised Text:
    Disposition: NoChange (Merged)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1

  • Legacy Issue Number: 16986
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 193
    Change: Delete the last sentence of paragraph 2, the concept of a DDS "type-plugin" is not defined.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This was already addressed as part of Issue 16955
    Revised Text:
    Disposition: NoChange (Merged)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.7.8

  • Legacy Issue Number: 16972
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 146
    Change: Change "Persistent" level of DDS Durability to "Transient or Persistent levels" since due to DDS (v1.2 section 7.1.3.4) they both behave the same for the purpose of Original Writer Info.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Accept suggested change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1.1.1 and 10.1.1.2

  • Legacy Issue Number: 16988
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 194-196
    Change: In Table 10.1 and all examples, all Identifiers should be shown as

    {0x00, 0x0?}

    to indicate that they are two-element arrays. Showing it as a single two-byte value could lead to confusion about endianness.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    replace as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.4.1.1, Figure 8.14

  • Legacy Issue Number: 16961
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 64
    Change: DDS has no "finish" operation on DataReader

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The operation should be called “return_loan”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.1.2

  • Legacy Issue Number: 16973
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 150
    Change: ENTITYID_UNKNOWN is missing a level of braces to represent the embedded array inside the struct: {

    {0, 0, 0}

    , 0 }

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    change as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use compliant OMG IDL syntax

  • Legacy Issue Number: 16956
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    IDL is defined by OMG’s own document formal/2011-11-01 in section 7. As another OMG specification (and most importantly, for clarity and precision), the current pseudo-IDL throughout the RTPS document must be changed to be actual compliant IDL. Compliant IDL does not use anonymous types: newly-constructed types appear in their own typedefs.
    Section: 9.2.2
    Page: 149
    Change: replace IDL with
    typedef octet OctetArray3[3];
    struct EntityId_t

    { OctetArray3 entityKey; octet entityKind; };

    Section: 9.3.1.1
    Page: 150
    Change: replace IDL with
    typedef octet GuidPrefix_t[12];

    Section: 9.3.1.2
    Page: 150
    Change: replace IDL with
    typedef octet OctetArray3[3];
    struct EntityId_t { OctetArray3 entityKey; octet entityKind; }

    ;

    Section: 9.3.1.5
    Page: 153
    Change: replace IDL with
    struct GUID_t

    { GuidPrefix_t guidPrefix; EntityId_t entityId; }

    ;

    Section: 9.3.2, Table 9.4 row “Time_t”
    Page: 153
    Change: replace IDL with
    struct Time_t

    { long seconds; unsigned long fraction; }

    ;

    Section: 9.3.2, Table 9.4 row “VendorId_t”
    Page: 153
    Change: replace IDL with
    typedef octet OctetArray2[2];
    struct VendorId_t

    { OctetArray2 vendorId; }

    ;

    Section: 9.3.2, Tables 9.4 and 9.5
    Page: 154-159
    Change: For ALL table entries with a struct move struct's identifier to directly follow the keyword "struct" (SequenceNumber_t, FragmentNumber_t, Locator_t, Count_t, ProtocolVersion_t, KeyHash_t, StatusInfo_t, ParameterId_t, ContentFilterProperty_t, ContentFilterInfo_t, OriginalWriterInfo_t, LocatorUDPv4_t) and in cases where "typedef" is used to introduce a struct, remove it (ProtocolVersion_t, ContentFilterProperty_t, ContentFilterInfo_t)
    Section: 9.3.2, Table 9.4
    Page: 155-157
    Change: Use of anonymous types is deprecated (applies to Locator_t::address, KeyHash_t::value, StatusInfo_t::value, all fields in ContentFilterProperty_t except for filterExpression). Replace the anonymous type with a typedef.
    Section: 9.3.2, Table 9.4
    Page: 157
    Change: Array bounds for FilterSignature_t must be at the end of the typedef
    Section: 9.4.2.6
    Page: 161
    Change: IDL syntax error due to use of anonymous types and the struct’s identifier must directly follow the keyword “struct”; also use unsigned long for bitmap
    Section: 9.4.2.8
    Page: 163
    Change: IDL syntax error due to use of anonymous types and the struct’s identifier must directly follow the keyword “struct”; also use unsigned long for bitmap
    Section: 9.4.2.11
    Page: 165
    Change: Use an unsigned short for “length” and mark this as "pseudo" IDL as there is no way to represent a sequence with a 2-byte length field or an array with runtime-determined bounds
    Section: 9.4.5.1
    Page: 168
    Change: struct’s identifier must directly follow the keyword “struct”
    Section: 9.6.2.1
    Page: 180
    Change: IDL syntax error due to use of anonymous types
    Section: 9.6.2.2
    Page: 181
    Change: IDL syntax error, the keyword "struct" is not used to identify types of fields. Also, IDL does not allow differences only in case so "WriterProxy writerProxy;" is ill-formed.
    Section: 10.1.1.1
    Page: 193
    Change: IDL syntax error, array bounds for Identifier must be at the end of the typedef, and the typedef keyword is missing.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    In addition to making the IDL compliant, the reference to formal/2011-11-01 should
    added to the normative section.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical errors

  • Legacy Issue Number: 16953
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Section: 8.3.7.6.5
    Page: 56
    Change: In the expressions for reader and writer GUID, replace Heartbeat with HeartbeatFrag

    Section: 8.3.7.9.6
    Page: 59
    Change: InfoTimestamp should be section 8.3.7.10, not 8.3.7.9.6 which makes it a part of the InfoSource submessage
    Section: 8.4.7.5.1
    Page: 81
    Change: pseudocode line "IF ( DDS_FILTER"… is missing a ")" before "THEN"

    Section: 8.4.13.2, Pgh 1, line 2
    Page: 118
    Change: "Endpoinst" should be "Endpoints"

    Section: 8.4.13.5
    Page: 119
    Change: "ome" should be "one"

    Section: 8.4.14.1.4, last bullet
    Page: 121
    Change: "of" should be "or"

    Section: 8.4.15.7
    Page: 123
    Change: "sample logical" should be "same logical"

    Section: 8.7.1
    Page: 140
    Change: "WoS" should be "QoS"

    Section: 8.7.4
    Page: 145
    Change: "Submessges" should be "Submessages", "PIM" should be "PSM", "teh" should be "the", "Data_Object" should be "Data-Object"
    Section: 9.4.2.6
    Page: 162
    Change: A stray digit "1" appears to the left of expression that starts "(bitmap[deltaN/32]...". Also, parentheses are unbalanced in this expression: there must be one additional ")" before the "=="
    Section: 9.4.5.3.3, Paragraph 3
    Page: 171
    Change: Replace "skip any submessage headers" with "skip any submessage elements". Replace "fule" with "rule". Replace "the received will" with "the receiver will".
    Section: 9.6.2.1
    Page: 180
    Change: replace "tpe" with "type"

    Section: 9.6.2.2, Paragraph 6
    Page: 181
    Change: replace "teh" with "the"

    Section: 9.6.2.2.2, Table 9.12
    Page: 183
    Change: for consistency replace "0x001A" with "0x001a"

    Section: 9.6.3.3
    Page: 191
    Change: the paragraph that starts with "\Note" has a stray backslash

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Correction of the typographical errors

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Entity Name Parameter Id

  • Legacy Issue Number: 11073
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A DDS entity name could be serialized within a parameter list, so a corresponding unique parameter Id should be assigned.
    Resolution:
    Add parameter Id for Entity Name.
    Revised Text:

    Type PSM Mapping
    EntityName_t struct

    { string name;}

    EntityName_t

    Append to Table 9.11:
    Name ID Type
    PID_ENTITY_NAME 0x0062 EntityName_t

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved the suggested changes are already in the spec.
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interpreting Liveliness Heartbeats

  • Legacy Issue Number: 11072
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    For better performance and simpler reliability, a liveliness heartbeat should be allowed to be a liveliness-only message without heartbeat semantics. As subclassed from a heartbeat, a liveliness heartbeat may trigger an ACKNACK response; to be a liveliness-only message, no ACKNACKs should be triggered. To enable this, setting the final flag should not trigger ACKNACKs.

    Resolution:
    A liveliness heartbeat with final-flag set must not trigger any ACKNACKs.

    Revised Text:
    Append to 8.4.2.3.2:

    The response is not required when a liveliness HEARTBEAT has both liveliness and final flags set to indicate it is a liveliness-only message.

    Revise statechart 8.24:

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved as part of the FTF, in that report it is labeled as
    issue 11043. It appears that a typographical mistake was made in the report (or else
    something changed in the database) so that the issue was not closed in the OMG
    database.
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reader-side Heartbeat response suppression

  • Legacy Issue Number: 11071
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The specification does not prevent multiple Heartbeats from arriving in rapid succession. For example, the piggyback heartbeat of a repair message may immediately be followed by a periodic wildcard heartbeat. In order to prevent duplicate repair sessions, the specification should define heartbeat suppression on the reader's side. This heartbeat response suppression should be handled by a reader attribute that controls the duration for which duplicate heartbeats would be ignored.

    Resolution:
    Add reader attribute, heartbeatSuppressionDuration, that defines the duration in which received heartbeats are suppressed from triggering duplicate ACKNACKs.

    Revised Text:
    Revised figure 8.21:

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved as part of the FTF, in that report it is labeled as
    issue 11041. It appears that a typographical mistake was made in the report (or else
    something changed in the database) so that the issue was not closed in the OMG
    database.
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify interoperability requirement 8.4.2.3.3

  • Legacy Issue Number: 11070
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The requirement contained in Section 8.4.2.3.3 is too restrictive and doesn't specify when resources can be reclaimed. If all Readers have acknowledged a sample, the Writer should be allowed to reclaim that sample's resources. Also, if a Reader NACKs a sample it has already ACKed, and the Writer is still able to provide a repair, it should.
    Resolution:
    Allow Writer to reclaim resources and send repairs if possible.
    Revised Text:
    Add the paragraph to the end of Section 8.4.2.3.3:

    Once a Writer has received positive acknowledgement from all Readers, the Writer can reclaim any associated resources. However, if a Writer receives a negative acknowledgement to a previously positively acknowledged sample, and the Writer can still service the request, the Writer should send the sample.

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved as part of the FTF, in that report it is labeled as
    issue 11037. It appears that a typographical mistake was made in the report (or else
    something changed in the database) so that the issue was not closed in the OMG
    database.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.7.3.5

  • Legacy Issue Number: 16960
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 52
    Change: Add parentheses around the subexpression: "(dataSize % fragmentSize) ? 1 : 0"

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Accept suggested change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.5.8

  • Legacy Issue Number: 16959
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 40
    Change: Time_t is underspecified. What real-world time does 0 represent?

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    No Change for this issue. Resolve as part of resolving 16975
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2.1.2, Table 8.2, Locator_t row

  • Legacy Issue Number: 16958
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Page: 14
    Change: discriminator and port number using 4 octets each (insert the word “each”)

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Accept as submitted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT