880 lines
45 KiB
Plaintext
880 lines
45 KiB
Plaintext
RULES 8.3.4.1 (Message Receiver)
|
||
================================
|
||
* If the full Submessage header cannot be read, the rest of the Message is considered invalid.
|
||
* If submessageLength field is invalid, the rest of the Message is invalid.
|
||
* A Submessage with an unknown SubmessageId must be ignored and parsing must continue with the next Submessage.
|
||
* The receiver of a Submessage should ignore unknown flags.
|
||
* A valid submessageLength field must always be used to find the next Submessage.
|
||
* A known but invalid Submessage invalidates the rest of the Message.
|
||
|
||
RULES 8.4.2
|
||
===========
|
||
|
||
GENERAL
|
||
-------
|
||
* All communications must take place using RTPS Messages
|
||
* All implementations must implement the RTPS Message Receiver
|
||
* The timing characteristics of all implementations must be tunable
|
||
* Implementations must implement the Simple Participant and Endpoint Discovery Protocols
|
||
|
||
WRITER
|
||
------
|
||
* Writers must not send data out-of-order
|
||
* Writers must include in-line QoS values if requested by a Reader
|
||
* Writers must send periodic HEARTBEAT Messages (reliable only)
|
||
* Writers must eventually respond to a negative acknowledgment (reliable only)
|
||
* Sending Heartbeats and Gaps with Writer Group Information (Writer belonging to a Group)
|
||
|
||
READER
|
||
------
|
||
A best-effort Reader is completely passive as it only receives data and does not send messages itself.
|
||
Therefore, the requirements below only apply to reliable Readers.
|
||
* Readers must respond eventually after receiving a HEARTBEAT with final flag not set
|
||
* Readers must respond eventually after receiving a HEARTBEAT that indicates a sample is missing
|
||
* Once acknowledged, always acknowledged
|
||
* Readers can only send an ACKNACK Message in response to a HEARTBEAT Message
|
||
|
||
RELIABILITY
|
||
===========
|
||
* Best Effort Writer can only be matched with Best Effort Reader
|
||
* Stateless Reader can only be Best Effort (maintains absolutely no state, does not handle duplicate and out-of-order changes)
|
||
|
||
STATELESS WRITER
|
||
================
|
||
Note that the processing of this message uses the reply locators in the RTPS Receiver.
|
||
This is the only source of information for the StatelessWriter to determine where to send the reply to.
|
||
Proper functioning of the protocol requires that the RTPS Reader inserts an InfoReply Submessage ahead of the AckNack such that these fields are properly set.
|
||
|
||
Writer Liveliness Protocol
|
||
==========================
|
||
ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER
|
||
ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER
|
||
|
||
OPTIONAL 8.4.14
|
||
===============
|
||
Optional features may not be supported by all RTPS implementations.
|
||
|
||
* LARGE DATA (Fragmented Data)
|
||
|
||
--------------------------------------------
|
||
|
||
ENTITYID_UKNOWN also for Built-In?
|
||
Ignore Participant/Topic/Publication/Subscription (handle argument of Sampleinfo)
|
||
|
||
ENDIANNESS
|
||
==========
|
||
You have to see what datatypes PSM maps to each element.
|
||
If the datatype is bigger than a byte, byte swaping has to occur.
|
||
The elements of an array are in order (but the elements themselves may need to be swapped if bigger than a Byte)
|
||
|
||
RTPS IN/OUT FORMAT
|
||
==================
|
||
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
| SRC_IPv4_ADDR |
|
||
+-------------------------------------------------------------+
|
||
| DEST_IPv4_ADDR |
|
||
+-----------------------------+-------------------------------+
|
||
| SRC_UDP_PORT | DEST_UDP_PORT |
|
||
+-----------------------------+-------------------------------+
|
||
| PACKET_LENGTH |
|
||
+-------------------------------------------------------------+
|
||
| |
|
||
~ PACKET ~
|
||
| |
|
||
+-------------------------------------------------------------+
|
||
|
||
ENDPOINT PACKET FORMAT
|
||
======================
|
||
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------+---------------+-------------------------------+
|
||
| OPCODE | FLAGS | SRC_UDP_PORT |
|
||
+-------------+---------------+-------------------------------+
|
||
| SRC_IPv4_ADDR |
|
||
+-------------------------------------------------------------+
|
||
| |
|
||
+ +
|
||
| SRC_GUIDPREFIX |
|
||
+ +
|
||
| |
|
||
+-------------------------------------------------------------+
|
||
| SRC_ENTITYID |
|
||
+-------------------------------------------------------------+
|
||
| DEST_ENTITYID [only for Builtin Destinations] |
|
||
+-------------------------------------------------------------+
|
||
| |
|
||
+ Sequence Number [only for DATA Submessage] +
|
||
| |
|
||
+-------------------------------------------------------------+
|
||
| |
|
||
+ Timestamp +
|
||
| [only for DATA Submessage and User Destinations] |
|
||
+-------------------------------------------------------------+
|
||
| |
|
||
~ PAYLOAD (SUBMESSAGE CONTENT) ~
|
||
| |
|
||
+-------------------------------------------------------------+
|
||
|
||
HEARTBEAT PAYLOAD
|
||
-----------------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
| |
|
||
+ FirstSN +
|
||
| |
|
||
+-------------------------------------------------------------+
|
||
| |
|
||
+ LastSN +
|
||
| |
|
||
+-------------------------------------------------------------+
|
||
| Count |
|
||
+-------------------------------------------------------------+
|
||
|
||
ACKNACK PAYLOAD
|
||
---------------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
| |
|
||
+ ReaderSNState.BASE +
|
||
| |
|
||
+-------------------------------------------------------------+
|
||
| ReaderSNState.NumBits |
|
||
+-------------------------------------------------------------+
|
||
| [ReaderSNState.Bitmap] x 0-8 |
|
||
+-------------------------------------------------------------+
|
||
| Count |
|
||
+-------------------------------------------------------------+
|
||
|
||
GAP PAYLOAD
|
||
-----------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
| |
|
||
+ GapStart +
|
||
| |
|
||
+-------------------------------------------------------------+
|
||
| |
|
||
+ GapList.BASE +
|
||
| |
|
||
+-------------------------------------------------------------+
|
||
| GapList.NumBits |
|
||
+-------------------------------------------------------------+
|
||
| [GapList.Bitmap] x 0-8 |
|
||
+-------------------------------------------------------------+
|
||
| UNUSED |
|
||
+-------------------------------------------------------------+
|
||
|
||
ENDPOINT_ID
|
||
===========
|
||
|
||
0...MAX_ENDPOINTS
|
||
READERS...WRITERS
|
||
|
||
BUILT-IN ENDPOINTS
|
||
==================
|
||
|
||
2.2.5 Built-In Topics
|
||
The QoS of the built-in Subscriber and DataReader objects is given by the following table:
|
||
HISTORY: kind = KEEP_LAST, depth = 1
|
||
|
||
PARTICICPANT DATA
|
||
=================
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| |
|
||
+ +
|
||
01| GUIDPREFIX |
|
||
+ +
|
||
02| |
|
||
+-------------------------------------------------------------+
|
||
03| META_IPv4_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
04| DEFAULT_IPv4_ADDRESS |
|
||
+-----------------------------+-------------------------------+
|
||
05| META_UDP_PORT | DEFAULT_UDP_PORT |
|
||
+-----------------------------+-------------------------------+
|
||
06| |
|
||
+ SPDP_SEQ_NR +
|
||
07| |
|
||
+-------------------------------------------------------------+
|
||
08| |
|
||
+ LEASE_DURATION +
|
||
09| |
|
||
+-------------------------------------------------------------+
|
||
10| |
|
||
+ LEASE_DEADLINE +
|
||
11| |
|
||
+-----------------------------------------------------+-+-+-+-+
|
||
12| UNUSED |P|S|M|Q|
|
||
+-----------------------------------------------------+-+-+-+-+
|
||
13| |
|
||
+ ACKNACK_RES_TIME +
|
||
14| |
|
||
+-------------------------------------------------------------+
|
||
15| |
|
||
+ HEARTBEAT_RES_TIME +
|
||
16| |
|
||
+-------------------------------------------------------------+
|
||
17| |
|
||
+ PUBLICATION_SEQ_NR +
|
||
18| |
|
||
+-------------------------------------------------------------+
|
||
19| |
|
||
+ SUBSCRIPTION_SEQ_NR +
|
||
20| |
|
||
+-------------------------------------------------------------+
|
||
21| |
|
||
+ MESSAGE_SEQ_NR +
|
||
22| |
|
||
+-------------------------------------------------------------+
|
||
|
||
Q...Reader expects in-line QoS
|
||
M...Send Message Data (Liveliness Update)
|
||
S...Send Subriber Data
|
||
P...Send Publisher Data
|
||
|
||
|
||
ENDPOINT MATCH FRAME
|
||
====================
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| OPCODE |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ +
|
||
02| GUIDPREFIX |
|
||
+ +
|
||
03| |
|
||
+-------------------------------------------------------------+
|
||
04| ENTITYID |
|
||
+-------------------------------------------------------------+
|
||
05| IPv4_ADDRESS |
|
||
+-----------------------------+-------------------------------+
|
||
06| UDP_PORT | READER_FLAGS |
|
||
+-----------------------------+-------------------------------+
|
||
|
||
READER_FLAGS
|
||
------------
|
||
16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------+-+-+-+
|
||
| UNUSED |B|H|Q|
|
||
+-------------------------+-+-+-+
|
||
Q...Reader expects in-line QoS
|
||
H...Reader expects Historical Data
|
||
B...Reader has RELIABILITY BEST_EFFORT
|
||
|
||
ENDPOINT UNMATCH FRAME
|
||
======================
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| OPCODE |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ +
|
||
02| GUIDPREFIX |
|
||
+ +
|
||
03| |
|
||
+-------------------------------------------------------------+
|
||
04| ENTITYID |
|
||
+-------------------------------------------------------------+
|
||
|
||
PARTICIPANT UNMATCH FRAME
|
||
=========================
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| OPCODE |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ +
|
||
02| GUIDPREFIX |
|
||
+ +
|
||
03| |
|
||
+-------------------------------------------------------------+
|
||
|
||
ENDPOINT LIVELINESS UPDATE
|
||
==========================
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| OPCODE |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ +
|
||
02| GUIDPREFIX |
|
||
+ +
|
||
03| |
|
||
+-------------------------------------------------------------+
|
||
|
||
LOCAL ENDPOINT BUFFER
|
||
=====================
|
||
|
||
READER
|
||
------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| ENTITYID |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ +
|
||
02| GUIDPREFIX |
|
||
+ +
|
||
03| |
|
||
+-------------------------------------------------------------+
|
||
04| IPv4_ADDRESS | [Reliable Only]
|
||
+-----------------------------+-------------------------------+
|
||
05| UDP_PORT | UNUSED | [Reliable Only]
|
||
+-----------------------------+-------------------------------+
|
||
06| |
|
||
+ NEXT_SEQ_NR +
|
||
07| |
|
||
+-------------------------------------------------------------+
|
||
08| |
|
||
+ LEASE_DEADLINE +
|
||
09| |
|
||
+-------------------------------------------------------------+
|
||
10| |
|
||
+ RES_TIME + [Reliable Only]
|
||
11| |
|
||
+-------------------------------------------------------------+
|
||
|
||
WRITER
|
||
------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| ENTITYID |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ +
|
||
02| GUIDPREFIX |
|
||
+ +
|
||
03| |
|
||
+-------------------------------------------------------------+
|
||
04| IPv4_ADDRESS |
|
||
+-----------------------------+-------------------------------+
|
||
05| UDP_PORT | READER_FLAGS |
|
||
+-----------------------------+-------------------------------+
|
||
06| |
|
||
+ LEASE_DEADLINE + [Reliable Only]
|
||
07| |
|
||
+-------------------------------------------------------------+
|
||
08| |
|
||
+ RES_TIME + [Reliable Only]
|
||
09| |
|
||
+-------------------------------------------------------------+
|
||
10| |
|
||
+ ACK_SEQ_NR_BASE + [Reliable Only]
|
||
11| |
|
||
+-------------------------------------------------------------+
|
||
12| |
|
||
+ REQ_SEQ_NR_BASE + [Reliable Only]
|
||
13| |
|
||
+-------------------------------------------------------------+
|
||
14| REQ_BITMAP | [Reliable Only]
|
||
+-------------------------------------------------------------+
|
||
|
||
READER_FLAGS
|
||
------------
|
||
16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------+-+-+-+
|
||
| UNUSED |B|H|Q|
|
||
+-------------------------+-+-+-+
|
||
Q...Reader expects in-line QoS
|
||
H...Reader expects Historical Data
|
||
B...Reader has RELIABILITY BEST_EFFORT
|
||
|
||
HISTORY CACHE
|
||
=============
|
||
|
||
READER
|
||
------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| STATUS_INFO |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ TIMESTAMP +
|
||
02| |
|
||
+-------------------------------------------------------------+
|
||
03| |
|
||
+ LIFESPAN_DEADLINE +
|
||
04| |
|
||
+-------------------------------------------------------------+
|
||
05| PAYLOAD_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
06| INSTANCE_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
07| DISPOSED_GENERATION_COUNT |
|
||
+-------------------------------------------------------------+
|
||
08| NO_WRITERS_GENERATION_COUNT |
|
||
+-------------------------------------------------------------+
|
||
09| PREV_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
10| NEXT_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
|
||
STATUS INFO
|
||
-----------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-+-+-+-+-----------------------------------------------+-+-+-+
|
||
|R|P|A|K| UNUSED |F|U|D|
|
||
+-+-+-+-+-----------------------------------------------+-+-+-+
|
||
|
||
R...Sample has been Read
|
||
P...Sample has associated Payload
|
||
A...Associated Payload is aligned (Payload does extend until end of last Palyload Slot)
|
||
K...Key Hash available
|
||
F...FilteredFlag (1:1 PID_STATUS_INFO Mapping)
|
||
U...UnregisteredFlag (1:1 PID_STATUS_INFO Mapping)
|
||
D...DisposedFlag (1:1 PID_STATUS_INFO Mapping)
|
||
|
||
NOTE: The Key Hash Flag is actually only needed during the ADD_CACHE_CHANGE process.
|
||
Later on it is obsolete, since we always calculate the Key Hash.
|
||
|
||
WRITER
|
||
------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| STATUS_INFO |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ SEQ_NR +
|
||
02| |
|
||
+-------------------------------------------------------------+
|
||
03| |
|
||
+ TIMESTAMP +
|
||
04| |
|
||
+-------------------------------------------------------------+
|
||
05| |
|
||
+ LIFESPAN_DEADLINE + [only if LIFESPAN /= INFINITE]
|
||
06| |
|
||
+-------------------------------------------------------------+
|
||
07| PAYLOAD_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
08| INSTANCE_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
09| PREV_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
10| NEXT_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
|
||
STATUS INFO
|
||
-----------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-+-+-+-------------------------------------------------+-+-+-+
|
||
|R|P|A| UNUSED |F|U|D|
|
||
+-+-+-+-------------------------------------------------+-+-+-+
|
||
|
||
R...Sample has been ACKed
|
||
P...Sample has associated Payload
|
||
A...Associated Payload is aligned (Payload does extend until end of last Palyload Slot)
|
||
F...FilteredFlag (1:1 PID_STATUS_INFO Mapping)
|
||
U...UnregisteredFlag (1:1 PID_STATUS_INFO Mapping)
|
||
D...DisposedFlag (1:1 PID_STATUS_INFO Mapping)
|
||
|
||
|
||
PAYLOAD MEMORY
|
||
==============
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| NEXT_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
~ PAYLOAD ~
|
||
**| |
|
||
+-------------------------------------------------------------+
|
||
|
||
DDS ENTITY INPUT
|
||
================
|
||
READER
|
||
------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| STATUS_INFO |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ TIMESTAMP +
|
||
02| |
|
||
+-------------------------------------------------------------+
|
||
03| |
|
||
+ LIFESPAN_DEADLINE +
|
||
04| |
|
||
+-------------------------------------------------------------+
|
||
05| |
|
||
+ +
|
||
06| |
|
||
+ KEY_HASH + [only if K Flag set]
|
||
07| |
|
||
+ +
|
||
08| |
|
||
+-------------------------------------------------------------+
|
||
09| ENDPOINT_POSITION |
|
||
+-------------------------------------------------------------+
|
||
10| |
|
||
~ PAYLOAD ~
|
||
**| |
|
||
+-------------------------------------------------------------+
|
||
|
||
STATUS INFO
|
||
-----------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-+-+-+-+-----------------------------------------------+-+-+-+
|
||
| |P| |K| UNUSED |F|U|D|
|
||
+-+-+-+-+-----------------------------------------------+-+-+-+
|
||
|
||
P...Sample has associated Payload
|
||
K...Key Hash available
|
||
F...FilteredFlag (1:1 PID_STATUS_INFO Mapping)
|
||
U...UnregisteredFlag (1:1 PID_STATUS_INFO Mapping)
|
||
D...DisposedFlag (1:1 PID_STATUS_INFO Mapping)
|
||
|
||
INSTANCE MEMORY
|
||
===============
|
||
|
||
READER
|
||
------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| NEXT_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ +
|
||
02| |
|
||
+ KEY_HASH +
|
||
03| |
|
||
+ +
|
||
04| |
|
||
+-------------------------------------------------------------+
|
||
05| STATUS_INFO |
|
||
+-------------------------------------------------------------+
|
||
06| SAMPLE_COUNT |
|
||
+-------------------------------------------------------------+
|
||
07| DISPOSED_GENERATION_COUNT |
|
||
+-------------------------------------------------------------+
|
||
08| NO_WRITERS_GENERATION_COUNT |
|
||
+-------------------------------------------------------------+
|
||
09| |
|
||
+ IGNORE_DEADLINE + [only TIME_BASED_FILTER]
|
||
10| |
|
||
+-------------------------------------------------------------+
|
||
11| |
|
||
~ WRITER_BITMAP ~
|
||
**| |
|
||
+-------------------------------------------------------------+
|
||
|
||
STATUS INFO
|
||
-----------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+---------------------------------------------------+-+-+-+-+-+
|
||
| UNUSED |M|V|L|W|D|
|
||
+---------------------------------------------------+-+-+-+-+-+
|
||
|
||
D...NOT_ALIVE_DISPOSED
|
||
W...NOT_ALIVE_NO_WRITERS
|
||
L...LIVELINESS FLAG
|
||
V...VIEW STATE
|
||
M...MARK
|
||
|
||
WRITER
|
||
------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------------+
|
||
00| NEXT_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
01| |
|
||
+ +
|
||
02| |
|
||
+ KEY_HASH +
|
||
03| |
|
||
+ +
|
||
04| |
|
||
+-------------------------------------------------------------+
|
||
05| STATUS_INFO |
|
||
+-------------------------------------------------------------+
|
||
06| SAMPLE_COUNT |
|
||
+-------------------------------------------------------------+
|
||
07| ACK_COUNT |
|
||
+-------------------------------------------------------------+
|
||
|
||
|
||
STATUS INFO
|
||
-----------
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
+-------------------------------------------------------+-+-+-+
|
||
| UNUSED |L|U|D|
|
||
+-------------------------------------------------------+-+-+-+
|
||
|
||
D...DISPOSED
|
||
W...UNREGISTERED
|
||
L...LIVELINESS FLAG
|
||
|
||
OUTPUT DATA
|
||
===========
|
||
31............24..............16..............8...............0
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
00| SRC_IPv4_ADDRESS |
|
||
+-------------------------------------------------------------+
|
||
01| DEST_IPv4_ADDRESS |
|
||
+-----------------------------+-------------------------------+
|
||
02| SRC_UDP_PORT | DEST_UDP_PORT |
|
||
+-----------------------------+-------------------------------+
|
||
03| |
|
||
~ RTPS_MESSAGE ~
|
||
**| |
|
||
+-------------------------------------------------------------+
|
||
|
||
|
||
TOPIC KEYS
|
||
==========
|
||
Nominally the key is part of the serialized data of a data submessage.
|
||
Using the key hash benefits implementations by providing a faster alternative than deserializing the full key from the received data-object.
|
||
|
||
MISC
|
||
====
|
||
|
||
8.2.9 Relation to DDS Entities (DDSI-RTPS)
|
||
How exactly a DDS Entity interacts with the HistoryCache however, is implementation specific and not
|
||
formally modeled by the RTPS protocol. Instead, the Behavior Module of the RTPS protocol only specifies how
|
||
CacheChange changes are transferred from the HistoryCache of the RTPS Writer to the HistoryCache of
|
||
each matching RTPS Reader.
|
||
|
||
8.2.9.1 (DDSI-RTPS)
|
||
When using strict reliable communication, a change can
|
||
only be removed when it has been acknowledged by all readers the change was sent to and which are still
|
||
active and alive.
|
||
|
||
8.2.9.2 (DDSI-RTPS)
|
||
Each matching Writer will attempt to transfer all relevant samples from its HistoryCache to the HistoryCache
|
||
of the Reader.
|
||
|
||
8.4.3 (DDSI-RTPS)
|
||
It is also not able to drop out-of-order samples on the Reader side as this
|
||
requires keeping track of the largest sequence number received from each remote Writer.
|
||
|
||
8.5.4.2 (DDSI-RTPS)
|
||
For the purpose of interoperability, it is sufficient that an implementation provides the required built-in
|
||
Endpoints and reliable communication that satisfies the general requirements listed in 8.4.2.
|
||
|
||
8.5.4.4 (DDSI-RTPS)
|
||
An implementation of the protocol need not necessarily send all information contained in the DataTypes.
|
||
If any information is not present, the implementation can assume the default values, as defined by the PSM.
|
||
|
||
8.7.2.2.6 (DDSI-RTPS)
|
||
In order to implement the DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS policy,
|
||
implementations must include an InfoTimestamp Submessage with every update from a Writer.
|
||
|
||
9.4.2.11 (DDSI-RTPS)
|
||
The ParameterList may contain multiple Parameters with the same value for the parameterId.
|
||
This is used to provide a collection of values for that kind of Parameter.
|
||
|
||
DDS_Advanced_Tutorial_2006_00-T1-2_Pardo.pdf
|
||
P.16
|
||
|
||
OpenDDS Developer's Guide
|
||
It should be noted that if multiple data writers write to the same instance, care should be taken to ensure
|
||
that clocks are synchronized to prevent incorrect ordering on the data reader.
|
||
|
||
https://community.rti.com/forum-topic/dropping-out-order-messages
|
||
Messages from a single DataWriter always presserve their order when put into the DataReader cache. The
|
||
middlware would drop a message rather than accept it out of order.
|
||
If you call the regular read/take APIs then you will get them in the same order as they are in the cache
|
||
which wil preserve the writer order. But if you start taking them using QueryConditions or read by insance
|
||
etc. Then you will could be skipping some messages that are in the DataReader cache and access them later
|
||
out of order.
|
||
In "Best efforts" there is a little bit of effort to ensure there are no duplicates or our-of-order samples.
|
||
Basically the DataReader keeps the higuest accepted sequence number from each DataWriter. If a sample arrives
|
||
with sequence number less or equal to that higuest accepted sequence number it will be dropped. This avoids
|
||
both duplicates and out of order samples.
|
||
|
||
https://community.rti.com/forum-topic/strict-reliability-and-destination-order-qos
|
||
The samples written by each DataWriter are guaranteed to have timestamps that are monotonically increasing
|
||
(each equal or greater than the previous) and this the DataReader will not reject them based on source
|
||
timestamp. The fact that a sample may be dropped on the wire and the reliable protocol may repair it does
|
||
not affect this fact. The out-of-order sample will be staged in the "reliability queue" of the DataReader
|
||
until the repair comes and by the time they are pushed to the DataReader cache they will be pushed in the
|
||
correct order and the source timestamps will not cause a problem.
|
||
|
||
https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/Content/UsersManual/The_SampleInfo_Structure.htm
|
||
In reliable communication, if DDS data samples are received out received of order, Connext DDS will not
|
||
deliver them until all the previous DDS data samples have been received. For example, if DDS sample 2 arrives
|
||
before DDS sample 1, DDS sample 2 cannot be delivered until DDS sample 1 is received. The reception_timestamp
|
||
is the time when all previous DDS samples has been received—the time at which the DDS sample is committed.
|
||
If DDS samples are all received in order, the committed time will be same as reception time. However, if DDS
|
||
samples are lost on the wire, then the committed time will be later than the initial reception time.
|
||
|
||
2.2.3.16 LIFESPAN (DDS)
|
||
This QoS relies on the sender and receiving applications having their clocks sufficiently synchronized. If
|
||
this is not the case and the Service can detect it, the DataReader is allowed to use the reception timestamp
|
||
instead of the source timestamp in its computation of the ‘expiration time.’
|
||
|
||
8.4.15.6 Reclaiming Finite Resources from Unresponsive Readers (DDSI-RTPS)
|
||
For a Writer, reclaiming queue resources should happen when all Readers have acknowledged a sample in the
|
||
queue and resources 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 Writer should determine the inactivity of a Reader by using a
|
||
mechanism based on the rate and number of ACKNACKs received.
|
||
|
||
https://community.rti.com/content/forum-topic/instance-resources-dispose-and-unregister
|
||
Note that this means that with the default QoS settings RTI Connext DDS DataWriters do not release resources
|
||
of instances that have been "disposed" but are still registered. The reason is that there are various
|
||
scenarios under which "forgetting diposed instances" could lead to inconsistent or erroneous outcomes.
|
||
For example:
|
||
Scenario 1: With OWNERSHIP Qos Policy EXCLUSIVE and DURABILITY Qos Policy TRANSIENT_LOCAL, removing all
|
||
the DataWriter state associated with disposed (but still registered) instances would prevent the
|
||
DataWriter from maintaining Ownership of the instance in the presence of late-joining DataReaders.
|
||
Scenario 2: With OWNERSHIP Qos Policy SHARED, DURABILITY Qos Policy TRANSIENT_LOCAL, and DESTINATION_ORDER
|
||
Qos Policy BT_SOURCE_TIMESTAMP, removing all the DataWriter state associated with disposed (but still
|
||
registered) instances could lead to situations in which a late-joiner DataReader does not get notified
|
||
about the most recent state of an existing instance.
|
||
|
||
https://community.rti.com/content/forum-topic/instance-resources-dispose-and-unregister
|
||
The reason RTI DDS DataReaders do not release resources of instances in the NOT_ALIVE_DISPOSED state is
|
||
that there various scenarios under which this could lead to inconsistent or erroneous outcomes.
|
||
For example:
|
||
Scenario 1: With EXCLUSIVE ownership, removing the resources associated with the instance would forget
|
||
which DataWriter "owns" the instance and if a new DataWriter which lower strength wrote the instance the
|
||
update would be incorrectly accepted.
|
||
Scenario 2: With SHARED ownership and destination order by SOURCE timestamp, removing the resources
|
||
associated with the instance would forget the source timestamp when the deletion occurs and if a different
|
||
DataWriter where to write the instance with an earlier timestamp the update would be incorrectly accepted.
|
||
|
||
2.2.2.5.3.8 read (DDS)
|
||
Samples that contain no data do not count towards the limits imposed by the RESOURCE_LIMITS QoS policy.
|
||
|
||
2.2.2.5.3.8 read (DDS)
|
||
The act of reading a sample sets its sample_state to READ. If the sample belongs to the most recent
|
||
generation of the instance, it will also set the view_state of the instance to NOT_NEW. It will not
|
||
affect the instance_state of the instance.
|
||
|
||
https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/Content/UsersManual/DESTINATION_ORDER_QosPolicy.htm#sending_2410472787_644578
|
||
Data will be delivered by a DataReader in the order in which it was sent. If data arrives on the network
|
||
with a source timestamp earlier than the source timestamp of the last data delivered, the new data will
|
||
be dropped. This ordering therefore works best when system clocks are relatively synchronized among
|
||
writing machines.
|
||
|
||
2.2.2.4.2.22 assert_liveliness (DDS)
|
||
NOTE: Writing data via the write operation on a DataWriter asserts liveliness on the DataWriter itself
|
||
and its DomainParticipant. Consequently the use of assert_liveliness is only needed if the application
|
||
is not writing data regularly.
|
||
|
||
INVALIDATION
|
||
============
|
||
|
||
RTPS HEADER (8.3.6.3)
|
||
-----------
|
||
* The Message has less than the required number of octets to contain a full Header
|
||
* Its protocol value does not match the value of PROTOCOL_RTPS
|
||
* The major protocol version is larger than the major protocol version supported by the implementation
|
||
|
||
ACKNACK (8.3.7.1.3)
|
||
-------
|
||
* submessageLength in the Submessage header is too small
|
||
* readerSNState is invalid
|
||
|
||
DATA (8.3.7.2.3)
|
||
----
|
||
* submessageLength in the Submessage header is too small
|
||
* writerSN.value is not strictly positive (1, 2, ...) or is SEQUENCENUMBER_UNKNOWN
|
||
* inlineQos is invalid
|
||
|
||
DATA FRAG (8.3.7.3.3)
|
||
---------
|
||
* submessageLength in the Submessage header is too small
|
||
* writerSN.value is not strictly positive (1, 2, ...) or is SEQUENCENUMBER_UNKNOWN
|
||
* fragmentStartingNum.value is not strictly positive (1, 2, ...) or exceeds the total number of fragments
|
||
* fragmentSize exceeds dataSize
|
||
* The size of serializedData exceeds (fragmentsInSubmessage * fragmentSize)
|
||
* inlineQos is invalid
|
||
|
||
GAP (8.3.7.4.3)
|
||
---
|
||
* submessageLength in the Submessage header is too small
|
||
* gapStart is zero or negative
|
||
* gapList is invalid
|
||
* (If GroupInfoFlag is set) gapStartGSN.value is zero or negative
|
||
* (If GroupInfoFlag is set) gapEndGSN.value is zero or negative
|
||
* (If GroupInfoFlag is set) gapEndGSN.value < gapStartGSN.value-1
|
||
|
||
HEARTBEAT (8.3.7.5.3)
|
||
---------
|
||
* submessageLength in the Submessage header is too small
|
||
* firstSN.value is zero or negative
|
||
* lastSN.value is negative
|
||
* lastSN.value < firstSN.value - 1
|
||
* (If GroupInfoFlag is set) currentGSN.value is zero or negative
|
||
* (If GroupInfoFlag is set) firstGSN.value is zero or negative
|
||
* (If GroupInfoFlag is set) lastGSN.value is negative
|
||
* (If GroupInfoFlag is set) lastGSN.value < firstGSN.value - 1
|
||
* (If GroupInfoFlag is set) currentGSN.value < firstGSN.value
|
||
* (If GroupInfoFlag is set) currentGSN.value < lastGSN.value
|
||
|
||
HEARTBEAT FRAG (8.3.7.6.3)
|
||
--------------
|
||
* submessageLength in the Submessage header is too small
|
||
* writerSN.value is zero or negative
|
||
* lastFragmentNum.value is zero or negative
|
||
|
||
INFO DESTINATION (8.3.7.7.3)
|
||
----------------
|
||
* submessageLength in the Submessage header is too small
|
||
|
||
INFO REPLY (8.3.7.8.3)
|
||
----------
|
||
* submessageLength in the Submessage header is too small
|
||
|
||
INFO SOURCE (8.3.7.9.3)
|
||
-----------
|
||
* submessageLength in the Submessage header is too small
|
||
|
||
INFO TIMESTAMP (8.3.7.10.3)
|
||
--------------
|
||
* submessageLength in the Submessage header is too small
|
||
|
||
NACK FRAG (8.3.7.11.3)
|
||
---------
|
||
* submessageLength in the Submessage header is too small
|
||
* writerSN.value is zero or negative
|
||
* fragmentNumberState is invalid
|
||
|
||
PAD (8.3.7.12.3)
|
||
---
|
||
ALWAYS VALID
|
||
|
||
NumberSet (9.4.2.6)
|
||
---------
|
||
* bitmapBase <= 0
|
||
* numBits < 0 or numBits > 256
|
||
* M/=(numBits+31)/32 longs in Submessage
|
||
|
||
Parameter List (8.3.5.9)
|
||
--------------
|
||
* There shall be no more than 2^16 possible values of the ParameterId_t parameterId
|
||
* A range of 2^15 values is reserved for protocol-defined parameters
|
||
* A range of 2^15 values is reserved for vendor-defined parameters
|
||
* The maximum length of any parameter is limited to 2^16 octets |