greek64/rtps-fpga
2
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
74af242bcc
rtps-fpga/src/REF.txt
Greek64 74af242bcc code refactoring
2022-04-05 17:20:32 +02:00

1029 lines
54 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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_UNKNOWN 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 Discovery Module] |
+---------------------------------------------------------------+
| |
+ Sequence Number [only for DATA Submessage] +
| |
+---------------------------------------------------------------+
| |
+ Timestamp +
| [only for DATA Submessage and RTPS Endpoints] |
+---------------------------------------------------------------+
| |
~ 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
DISCOVERY MODULE
================
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|
+---------------------------------------------------------+-+-+-+
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| |
+---------------------------------------------------------------+
23| NEXT_ADDRESS |
+---------------------------------------------------------------+
24| PREV_ADDRESS |
+---------------------------------------------------------------+
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 |
+-------------------------------+-------------------------------+
07| |
+ LIFESPAN_DURATION +
08| [only for Reader Endpoints] |
+-------------------------------+-------------------------------+
READER_FLAGS
------------
15............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| |
+---------------------------------------------------------------+
RTPS ENDPOINT
=============
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| |
+ LIFESPAN_DURATION +
11| |
+---------------------------------------------------------------+
12| |
+ RES_TIME + [Reliable Only]
13| |
+---------------------------------------------------------------+
14| WRITER_ID |
+---------------------------------------------------------------+
15| NEXT_ADDR |
+---------------------------------------------------------------+
16| PREV_ADDR |
+---------------------------------------------------------------+
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]
+---------------------------------------------------------------+
15| NEXT_ADDR |
+---------------------------------------------------------------+
16| PREV_ADDR |
+---------------------------------------------------------------+
READER_FLAGS
------------
15............8...............0
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------------------+-+-+-+
| UNUSED |B|H|Q|
+-------------------------+-+-+-+
Q...Reader expects in-line QoS
H...Reader expects Historical Data
B...Reader has RELIABILITY BEST_EFFORT
DDS ENDPOINT
============
READER
------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| STATUS_INFO |
+---------------------------------------------------------------+
01| |
+ TIMESTAMP +
02| |
+---------------------------------------------------------------+
03| |
+ LIFESPAN_DEADLINE +
04| |
+---------------------------------------------------------------+
05| PAYLOAD_ADDRESS |
+---------------------------------------------------------------+
06| INSTANCE_ADDRESS | [only if WITH_KEY]
+---------------------------------------------------------------+
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| UNUSED |F|U|D|
+-+-+-+---------------------------------------------------+-+-+-+
R...Sample has been Read
P...Sample has associated DATA 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)
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 | [only if WITH_KEY]
+---------------------------------------------------------------+
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 DATA 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| WRITER_ID |
+---------------------------------------------------------------+
10| |
~ PAYLOAD ~
**| |
+---------------------------------------------------------------+
STATUS INFO
-----------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-------------------------------------------------+-+-+-+
| |P| |K| UNUSED |F|U|D|
+-+-+-+-+-------------------------------------------------+-+-+-+
P...Sample has associated DATA 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)
NOTE: If P=0 and K=0, the Payload contains the Serialized Key
INSTANCE MEMORY
===============
READER
------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| NEXT_ADDRESS |
+---------------------------------------------------------------+
01| PREV_ADDRESS |
+---------------------------------------------------------------+
02| |
+ +
03| |
+ KEY_HASH +
04| |
+ +
05| |
+---------------------------------------------------------------+
06| STATUS_INFO |
+---------------------------------------------------------------+
07| SAMPLE_COUNT |
+---------------------------------------------------------------+
08| DISPOSED_GENERATION_COUNT |
+---------------------------------------------------------------+
09| NO_WRITERS_GENERATION_COUNT |
+---------------------------------------------------------------+
10| |
+ IGNORE_DEADLINE + [only TIME_BASED_FILTER]
11| |
+---------------------------------------------------------------+
12| |
~ WRITER_BITMAP ~
**| |
+---------------------------------------------------------------+
STATUS INFO
-----------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------+-+-+-+-+-+-+
| UNUSED |G|M|V|L|W|D|
+---------------------------------------------------+-+-+-+-+-+-+
D...NOT_ALIVE_DISPOSED
W...NOT_ALIVE_NO_WRITERS
L...LIVELINESS FLAG
V...VIEW STATE
M...MARK
G...GENERATE SAMPLE
WRITER
------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| NEXT_ADDRESS |
+---------------------------------------------------------------+
01| PREV_ADDRESS |
+---------------------------------------------------------------+
02| |
+ +
03| |
+ KEY_HASH +
04| |
+ +
05| |
+---------------------------------------------------------------+
06| STATUS_INFO |
+---------------------------------------------------------------+
07| SAMPLE_COUNT |
+---------------------------------------------------------------+
08| 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 ~
**| |
+---------------------------------------------------------------+
ACTION SERVER
=============
GOAL
----
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------------------------------------------+---------------+
00| UNUSED | GOAL_STATE |
+-----------------------------------------------+---------------+
01| |
+ +
02| |
+ GOAL_ID +
03| |
+ +
04| |
+---------------------------------------------------------------+
05| |
+ STAMP +
06| |
+---------------------------------------------------------------+
07| |
+ DEADLINE + [only if TIMEOUT_DURATION /= DURATION_INFINITE]
08| |
+---------------------------------------------------------------+
09| RESULT_INDEX |
+---------------------------------------------------------------+
10| NEXT_ADDRESS |
+---------------------------------------------------------------+
11| PREV_ADDRESS |
+---------------------------------------------------------------+
RESULT_REQUEST
--------------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| GOAL_HANDLE |
+---------------------------------------------------------------+
01| |
+ +
02| |
+ +
03| |
+ REQUEST_ID +
04| |
+ +
05| |
+ +
06| |
+---------------------------------------------------------------+
07| NEXT_ADDRESS |
+---------------------------------------------------------------+
08| PREV_ADDRESS |
+---------------------------------------------------------------+
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.
9.4.2.11 (DDSI-RTPS)
For alignment purposes, the CDR stream is logically reset for each parameter value (i.e., no initial padding is
required) after the parameterId and length are serialized.
7.4.3.5.2 Encoding of Optional Members (DDS-XTYPES)
PLAIN_CDR serializes optional members by prepending either a ShortMemberHeader or a 12
byte LongMemberHeader. See Clause 7.4.1.1.5.2. The associated size is set to zero if the
optional member is not present or to the actual serialized size if the member is present. These
headers are serialized at a 4-byte offset relative to the current stream origin (XCDR.origin) and
adjust the alignment origin to zero for the serialization of the member itself.
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.
https://community.rti.com/content/forum-topic/instance-resources-dispose-and-unregister
The instance has no known DataWriters that are writing it. This occurs when all the DataWriters that
were known (by the DataReader) to write the instance have either unregistered the instance or have left
the system (so they are no longer matched with the DataReader). Note that the instance could be on a
NOT_ALIVE_NO_WRITERS instance_state or a NOT_ALIVE_DISPOSED, depending on whether the instance was
disposed prior to losing all the DataWriters.
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.
2.2.2.4.2.11 write (DDS)
If (RESOURCE_LIMITS max_samples < RESOURCE_LIMITS max_instances * HISTORY depth), then in the situation
where the max_samples resource limit is exhausted the Service is allowed to discard samples of some other
instance as long as at least one sample remains for such an instance. If it is still not possible to make
space available to store the modification, the writer is allowed to block.
2.2.2.4.2.7 unregister_instance (DDS)
If after that, the application wants to modify (write or dispose) the instance, it has to register it again,
or else use the special handle value HANDLE_NIL.
2.2.2.5.5 SampleInfo CLass (DDS)
The publication_handle that identifies locally the DataWriter that modified the instance. The publication_handle is the
same InstanceHandle_t that is returned by the operation get_matched_publications on the DataReader and can also
be used as a parameter to the DataReader operation get_matched_publication_data.
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
Reference in New Issue View Git Blame Copy Permalink