DDS Interoperability Wire Protocol Avatar
  1. OMG Specification

DDS Interoperability Wire Protocol — All Issues

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

Issues Descriptions

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

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

    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 (Count): 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': HeaderExtension 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. 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. 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. Change in state of Receiver
    None. 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 'SubmessageId', add RTPS_HE to the enum SubmessageKind and update the definition to use new IDL syntax:

    enum SubmessageKind {
        RTPS_HE,    /* RTPSHeaderExtension */
        PAD, /* Pad */            
        ACKNACK, /* AckNack */        
        HEARTBEAT, /* Heartbeat */      
        GAP, /* Gap */            
        INFO_TS, /* InfoTimestamp */  
        INFO_SRC, /* InfoSource */     
        INFO_REPLY_IP4, /* InfoReplyIp4 */   
        INFO_DST, /* InfoDestination */
        INFO_REPLY, /* InfoReply */      
        NACK_FRAG, /* NackFrag */       
        HEARTBEAT_FRAG, /* HeartbeatFrag */  
        DATA, /* Data */           
        DATA_FRAG /* DataFrag */

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

    |    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

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

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

  • Legacy Issue Number: 19237
  • Status: closed  
  • Source: ( 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, PhD.)
  • 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 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