Message Size should be included as part of DDSI/RTPS Messages
-
Key: DDSIRTP23-6
-
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:
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.
InFor example, in the case of a packet-oriented transport (like UDP/IP), the length of the message is already provided by the transport encapsulation.AIn contrast, a stream-oriented transport (like TCP) would need toinsert the length ahead of the messageinclude 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 Submessageelement 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