274 lines
14 KiB
Plaintext
274 lines
14 KiB
Plaintext
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 Liveness 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)
|
|
|
|
ENDPOINT FIFO PACKET FORMAT
|
|
===========================
|
|
|
|
32..............24..............16..............8...............0
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| LENTGH |
|
|
+---------------+---------------+---------------+---------------+
|
|
| OPCODE | FLAGS | SRC_UDP_PORT |
|
|
+---------------+---------------+---------------+---------------+
|
|
| SRC_IPv4_ADDR |
|
|
+---------------------------------------------------------------+
|
|
| SRC_ENTITYID |
|
|
+---------------------------------------------------------------+
|
|
| |
|
|
+ +
|
|
| SRC_GUIDPREFIX |
|
|
+ +
|
|
| |
|
|
+---------------------------------------------------------------+
|
|
| DEST_ENTITYID [only for Builtin Destinations] |
|
|
+---------------------------------------------------------------+
|
|
| |
|
|
+ Sequence Number [only for DATA Submessage] +
|
|
| |
|
|
+---------------------------------------------------------------+
|
|
| |
|
|
~ PAYLOAD (SUBMESSAGE CONTENT) ~
|
|
| |
|
|
+---------------------------------------------------------------+
|
|
|
|
ENDPOINT_ID
|
|
===========
|
|
|
|
MSB...........LSB
|
|
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
|
|
|
|
Since the Built-In Endpoints have a history depth of 1, we can safely reduce the processing complexity of ACKNACK and
|
|
HEARTBEAT messages (and even ignore GAP messages).
|
|
|
|
PARTICICPANT DATA
|
|
=================
|
|
32..............24..............16..............8...............0
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+---------------------------------------------------------------+
|
|
01| |
|
|
+ +
|
|
02| GUIDPREFIX |
|
|
+ +
|
|
03| |
|
|
+---------------------------------------------------------------+
|
|
04| META_IPv4_ADDRESS |
|
|
+---------------------------------------------------------------+
|
|
05| DEFAULT_IPv4_ADDRESS |
|
|
+---------------------------------------------------------------+
|
|
06| META_UDP_PORT | DEFAULT_UDP_PORT |
|
|
+---------------------------------------------------------------+
|
|
07| UNUSED | EXTRA_FLAGS |Q|
|
|
+---------------------------------------------------------------+
|
|
08| LEASE_DURATION |
|
|
+ +
|
|
09| |
|
|
+---------------------------------------------------------------+
|
|
10| LEASE_DEADLINE |
|
|
+ +
|
|
11| |
|
|
+---------------------------------------------------------------+
|
|
12| |
|
|
+ SPDP_SEQ_NR +
|
|
13| |
|
|
+---------------------------------------------------------------+
|
|
14| |
|
|
+ PUBLICATION_SEQ_NR +
|
|
15| |
|
|
+---------------------------------------------------------------+
|
|
16| |
|
|
+ SUBSCRIPTION_SEQ_NR +
|
|
17| |
|
|
+---------------------------------------------------------------+
|
|
18| |
|
|
+ MESSAGE_SEQ_NR +
|
|
19| |
|
|
+---------------------------------------------------------------+
|
|
|
|
ENDPOINT DATA
|
|
=============
|
|
32..............24..............16..............8...............0
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+---------------------------------------------------------------+
|
|
01| ENTITYID |
|
|
+---------------------------------------------------------------+
|
|
02| |
|
|
+ +
|
|
03| GUIDPREFIX |
|
|
+ +
|
|
04| |
|
|
+---------------------------------------------------------------+
|
|
05| |
|
|
~ ENDPOINT_BITMASK ~
|
|
**| |
|
|
+---------------------------------------------------------------+
|
|
|
|
ENDPOINT MATCH FRAME
|
|
====================
|
|
32..............24..............16..............8...............0
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+---------------------------------------------------------------+
|
|
01| OPCODE |
|
|
+---------------------------------------------------------------+
|
|
02| |
|
|
+ +
|
|
03| GUIDPREFIX |
|
|
+ +
|
|
04| |
|
|
+---------------------------------------------------------------+
|
|
05| ENTITYID |
|
|
+---------------------------------------------------------------+
|
|
06| IPv4_ADDRESS |
|
|
+---------------------------------------------------------------+
|
|
07| UDP_PORT | EXTRA_FLAGS |Q|
|
|
+---------------------------------------------------------------+
|
|
|
|
ENDPOINT UNMATCH FRAME
|
|
======================
|
|
32..............24..............16..............8...............0
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+---------------------------------------------------------------+
|
|
01| OPCODE |
|
|
+---------------------------------------------------------------+
|
|
02| |
|
|
+ +
|
|
03| GUIDPREFIX |
|
|
+ +
|
|
04| |
|
|
+---------------------------------------------------------------+
|
|
05| ENTITYID |
|
|
+---------------------------------------------------------------+
|
|
|
|
LOCAL ENDPOINT BUFFER
|
|
=====================
|
|
32..............24..............16..............8...............0
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+---------------------------------------------------------------+
|
|
| |
|
|
+ +
|
|
| GUIDPREFIX |
|
|
+ +
|
|
| |
|
|
+---------------------------------------------------------------+
|
|
| ENTITYID |
|
|
+---------------------------------------------------------------+
|
|
| IPv4_ADDRESS |
|
|
+---------------------------------------------------------------+
|
|
| UDP_PORT | EXTRA_FLAGS |
|
|
+---------------------------------------------------------------+
|
|
| LIFESPAN |
|
|
+ +
|
|
| (READER_ONLY) |
|
|
+---------------------------------------------------------------+
|
|
|
|
|
|
|
|
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
|
|
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
|
|
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
|
|
Each matching Writer will attempt to transfer all relevant samples from its HistoryCache to the HistoryCache of the Reader.
|
|
|
|
8.4.3
|
|
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.
|
|
--> Suggests there is multiple writers
|
|
|
|
8.5.4.2
|
|
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
|
|
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
|
|
In order to implement the DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS policy,
|
|
implementations must include an InfoTimestamp Submessage with every update from a Writer.
|
|
|
|
|
|
|
|
DDS_Advanced_Tutorial_2006_00-T1-2_Pardo.pdf (P.16)
|