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