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 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                      | [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|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                      | [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 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)
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|                                                             |
  +                                                             +
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.

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.

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