DDSI-RTPS 2.5 — Spec Coverage

Source: internal/standards/cache/omg/ddsi-rtps-2.5.pdf (206 pages, OMG formal/2022-04-01) — OMG DDSI-RTPS 2.5

Item-by-item audit against the PDF following internal/spec-coverage/PROCESS.md. Page numbers are PDF pages (PDF page = printed page + 6). Every row of a normative table is an item of its own. done stands only where code and a test cover the requirement; a test citation names the test function as file::module::name.

Context: The DDSI-RTPS 2.5 stack is spread over:

crates/rtps/ · docs.rs — header, submessages, HeaderExtension, ParameterList, inline QoS, receiver state, writer and reader state machines with their proxies, HistoryCache, fragmentation, discovery data types.
crates/discovery/ · docs.rs — SPDP, SEDP, TypeLookup, the secure builtin endpoints.
crates/transport/ · docs.rs, crates/transport-udp/ — the transport interface and the UDP/IP PSM (§9.5).
crates/dcps/ · docs.rs — the DDS side (§8.2.10), the Writer Liveliness Protocol, KeyHash, the encapsulation header (§10).
crates/qos/ · docs.rs — the QoS policies and their wire format.

Repo: crates/rtps/src/submessages.rs (DataFragSubmessage::serialized_payload)

Tests: crates/rtps/src/datagram.rs::tests::decode_data_frag_preserves_flags_and_payload

Status: done

Spec: §8.3.7.5, p. 52 — “It shall be computed over the entire RTPS Message. For the purpose of computing the checksum, the value of the messageChecksum field in the RTPS HeaderExtension shall be set to zero.”

Status: done — message_checksum computes over the whole message with the field zeroed.

§8.3.7.5 uExtension4, wExtension8, parameters without meaning

Spec: §8.3.7.5, p. 52 — “The uExtension4 and wExtension8 may be useful to communicate additional data on the header in a future version … This version of the specification does not define any parameters in the HeaderExtension.”

Repo: —

Tests: —

Status: n/a (informative) — no requirement on this version.

§8.3.8 Entity and interpreter submessages

Spec: §8.3.8, pp. 52–53, Table 8.39 — division into entity submessages (Data, DataFrag, Heartbeat, HeartbeatFrag, Gap, AckNack, NackFrag) and interpreter submessages (HeaderExtension, InfoSource, InfoDestination, InfoReply, InfoTimestamp, Pad); outline of every description.

Repo: —

Tests: —

Status: n/a (informative) — overview; the submessages are listed one by one under §8.3.8.1–§8.3.8.13.

§8.3.8.1 AckNack: Purpose

Spec: §8.3.8.1, p. 54 — “This Submessage is used to communicate the state of a Reader to a Writer. … This Submessage can be used to do both positive and negative acknowledgments.”

Repo: —

Tests: —

Status: n/a (informative) — statement of purpose; the contents follow.

§8.3.8.1 Table 8.40 AckNack EndiannessFlag

Spec: §8.3.8.1, p. 54, Table 8.40 — “EndiannessFlag … Indicates endianness.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::write_body, AckNackSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::tests::acknack_submessage_roundtrip_le, crates/rtps/tests/vendor_frames.rs::fastdds_datagrams_re_encode_byte_for_byte

Status: done

§8.3.8.1 Table 8.40 AckNack FinalFlag

Spec: §8.3.8.1, p. 54, Table 8.40 — “FinalFlag … Indicates to the Writer whether a response is mandatory.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::final_flag, ACKNACK_FLAG_FINAL); crates/rtps/src/reliable_reader.rs (build_acknack_datagram)

Tests: crates/rtps/src/submessages.rs::tests::acknack_submessage_with_final_flag, crates/rtps/src/datagram.rs::tests::decode_acknack_preserves_final_flag

Status: done — the writer’s duty to respond is listed under §9.4.5.3.

§8.3.8.1 Table 8.40 AckNack readerId

Spec: §8.3.8.1, p. 54, Table 8.40 — “readerId: EntityId — Identifies the Reader entity that acknowledges receipt of certain sequence numbers and/or requests to receive certain sequence numbers.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::reader_id)

Tests: crates/rtps/src/submessages.rs::tests::acknack_submessage_roundtrip_le

Status: done

§8.3.8.1 Table 8.40 AckNack writerId

Spec: §8.3.8.1, p. 54, Table 8.40 — “writerId: EntityId — Identifies the Writer entity that is the target of the AckNack message.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::writer_id); crates/dcps/src/runtime.rs (handle_user_datagram_from: rt.writer_slot(ack.writer_id))

Tests: crates/rtps/src/submessages.rs::tests::acknack_submessage_roundtrip_le, crates/rtps/src/reliable_writer.rs::tests::acknack_dispatches_to_matching_proxy_only

Status: done

§8.3.8.1 Table 8.40 AckNack readerSNState

Spec: §8.3.8.1, p. 54, Table 8.40 — “All sequence numbers up to the one prior to readerSNState.base are confirmed as received by the reader. The sequence numbers that appear in the set indicate missing sequence numbers on the reader side.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::reader_sn_state); crates/rtps/src/reliable_writer.rs (handle_acknack_set_at)

Tests: crates/rtps/src/reliable_writer.rs::tests::handle_acknack_updates_proxy_state, crates/rtps/src/reliable_writer.rs::tests::handle_acknack_with_lower_base_leaves_requested

Status: done

§8.3.8.1 Table 8.40 AckNack count

Spec: §8.3.8.1, p. 54, Table 8.40 — “count: Count — A counter that is incremented each time a new AckNack message is sent.”

Repo: crates/rtps/src/reliable_reader.rs (build_acknack_datagram)

Tests: crates/rtps/src/reliable_reader.rs::tests::the_counts_of_acknack_and_nack_frag_rise_with_each_message

Status: done — successive ACKNACKs carry the counts 1, 2, 3.

§8.3.8.1 AckNack invalid: submessageLength too small

Spec: §8.3.8.1, p. 54 — “submessageLength in the Submessage header is too small.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::read_body)

Status: done

Repo: —

Status: done

§8.3.8.4 Table 8.43 Gap gapEndGSN

Spec: §8.3.8.4, p. 60, Table 8.43 — “gapEndGSN: SequenceNumber — Present only if the GroupInfoFlag is set in the header. … It shall be greater than or equal to the group sequence number corresponding to the sample identified by gapList.bitmapBase.”

Repo: —

Status: done

§8.3.8.4 Table 8.43 Gap filteredCount

Spec: §8.3.8.4, p. 60, Table 8.43 — “filteredCount: ChangeCount — Present only if the FilteredCountFlag is set in the header. Indicates the number of changes corresponding to the set of sequence numbers in the Gap that are still present in the Writer cache but are being filtered for the RTPS Reader.”

Repo: crates/rtps/src/submessages.rs (GapSubmessage::filtered_count)

Tests: crates/rtps/src/submessages.rs::tests::gap_filtered_count_is_eight_octets_high_then_low, crates/rtps/src/submessages.rs::tests::gap_with_filtered_count_roundtrip_le

Status: done

Spec: §8.3.8.6, p. 62, Table 8.44 — “currentGSN … Identifies the last (highest) group sequence number written by any DataWriter in the Writer’s Group at the time that the HeartBeat was sent.”

Repo: —

Status: done

§8.3.8.6 Table 8.44 Heartbeat firstGSN

Spec: §8.3.8.6, p. 62, Table 8.44 — “firstGSN … Identifies the group sequence number corresponding to the sample identified by sequence number firstSN.”

Repo: —

Status: done

§8.3.8.6 Table 8.44 Heartbeat lastGSN

Spec: §8.3.8.6, p. 62, Table 8.44 — “lastGSN … Identifies the group sequence number corresponding to the sample identified by sequence number lastSN.”

Repo: —

Status: done

§8.3.8.6 Table 8.44 Heartbeat writerSet

Spec: §8.3.8.6, p. 62, Table 8.44 — “writerSet: GroupDigest … Identifies the subset of Writers that belong to the Writer’s Group at the time the sample with currentGSN was written.”

Repo: crates/rtps/src/submessages.rs (HeartbeatGroupInfo, HeartbeatSubmessage::write_body, read_body); crates/rtps/src/dialect.rs (HeartbeatGroupDigests); crates/rtps/src/reliable_writer.rs (heartbeat_group_info); crates/dcps/src/group_order.rs; wire.omit_heartbeat_group_digests

Tests: crates/rtps/src/submessages.rs::tests::the_group_digests_follow_last_gsn_and_are_optional_on_read, crates/rtps/src/reliable_writer.rs::tests::a_group_writers_heartbeat_carries_the_writer_sets_unless_the_peer_omits_them, crates/dcps/src/group_order.rs::tests::a_heartbeat_whose_writer_sets_are_not_the_discovered_ones_keeps_the_number_open, crates/dcps/tests/runtime_config_layering.rs::the_heartbeat_digest_and_keyless_lifecycle_settings_are_read_from_yaml

Status: done — with G=1 the writer sends writerSet after lastGSN as a GroupDigest (four octets, §9.4.2.19; the first four octets of the MD5 over the EntityIdSet_t, sorted, §9.3.2.5; empty group: zero). The reader reads both when the submessageLength leaves room and accepts their absence (figure of §9.4.5.7); the commit rule of §8.7.5 compares them with the discovered writers. wire.omit_heartbeat_group_digests leaves them out on send. Contradiction PIM/PSM: see “Contradictions within the spec”.

§8.3.8.6 Table 8.44 Heartbeat secureWriterSet

Spec: §8.3.8.6, p. 62, Table 8.44 — “secureWriterSet: GroupDigest … Reserved for use by the DDS-Security Specification.”

Status: done — with G=1 the writer sends secureWriterSet after lastGSN as a GroupDigest (four octets, §9.4.2.19; the first four octets of the MD5 over the EntityIdSet_t, sorted, §9.3.2.5; empty group: zero; secureWriterSet is reserved for DDS-Security and is sent as zero). The reader reads both when the submessageLength leaves room and accepts their absence (figure of §9.4.5.7); the commit rule of §8.7.5 compares them with the discovered writers. wire.omit_heartbeat_group_digests leaves them out on send. Contradiction PIM/PSM: see “Contradictions within the spec”.

§8.3.8.6 Heartbeat example 1: never written

Spec: §8.3.8.6, p. 63 — “A Writer that has never written any samples before sending a Heartbeat will send a Heartbeat with firstSN.value = 1, lastSN.value = 0.”

Repo: crates/rtps/src/reliable_writer.rs (append_heartbeat)

Tests: crates/rtps/src/reliable_writer.rs::tests::an_empty_writer_heartbeats_a_reader_until_it_answers

Status: done

§8.3.8.6 Heartbeat example 2: one sample in the cache

Spec: §8.3.8.6, p. 63 — “A Writer that has only one sample in its cache with sequence number SN will send a Heartbeat with firstSN.value = lastSN.value = SN.”

Repo: crates/rtps/src/reliable_writer.rs (append_heartbeat)

Tests: crates/rtps/src/reliable_writer.rs::tests::heartbeat_carries_cache_range

Status: done

§8.3.8.6 Heartbeat example 3: part of the history in the cache

Spec: §8.3.8.6, p. 63 — “A Writer that has written 10 samples and still has the last 5 samples in its cache will send a Heartbeat with firstSN.value = 6, lastSN.value = 10.”

Repo: crates/rtps/src/reliable_writer.rs (append_heartbeat)

Tests: crates/rtps/src/reliable_writer.rs::tests::keep_last_evicts_oldest_on_overflow

Status: done

§8.3.8.6 Heartbeat example 4: cache empty after writing

Spec: §8.3.8.6, p. 63 — “A Writer that has written 10 samples before sending a Heartbeat but does not have any samples available at the time of the Heartbeat will send a Heartbeat with firstSN.value = 11, lastSN.value = 10.”

Repo: crates/rtps/src/reliable_writer.rs (append_heartbeat: first_sn.min(last + 1))

Tests: crates/rtps/src/reliable_writer.rs::tests::a_heartbeat_after_the_cache_emptied_announces_the_last_sn_written

Status: done

§8.3.8.6 Heartbeat invalid: submessageLength too small

Spec: §8.3.8.6, p. 63 — “submessageLength in the Submessage header is too small”.

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::read_body)

Status: done — the shortening is recognised; the submessage is invalid and the rest of the message with it, the submessages before it stand (ParsedDatagram::invalid_rest, counted).

§8.3.8.6 Heartbeat invalid: firstSN ≤ 0

Spec: §8.3.8.6, p. 63 — “firstSN.value is zero or negative”.

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::heartbeat_validity_rules

Status: done — a firstSN below 1 is refused.

§8.3.8.6 Heartbeat invalid: lastSN < 0

Spec: §8.3.8.6, p. 63 — “lastSN.value is negative”.

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::heartbeat_validity_rules

Status: done — a negative lastSN is refused.

§8.3.8.6 Heartbeat invalid: lastSN < firstSN − 1

Spec: §8.3.8.6, p. 63 — “lastSN.value < firstSN.value - 1”.

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::heartbeat_validity_rules

Status: done — lastSN < firstSN - 1 is refused; lastSN = firstSN - 1 (empty history) is valid.

§8.3.8.6 Heartbeat invalid: group fields

Spec: §8.3.8.6, p. 63 — six conditions for currentGSN, firstGSN and lastGSN when the GroupInfoFlag is set.

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::tests::heartbeat_decode_rejects_invalid_group_sequence_numbers, crates/rtps/src/submessages.rs::tests::a_current_gsn_past_the_writers_last_is_accepted, crates/rtps/src/submessages.rs::tests::heartbeat_decode_rejects_truncated_group_info

Status: done — five of the six conditions are checked. The sixth, currentGSN > lastGSN, contradicts the definition of currentGSN (pp. 62–63: the number of the sample written last, which lastGSN may not include yet) and is not applied; the test a_current_gsn_past_the_writers_last_is_accepted holds that. The reading chosen is under “Contradictions within the spec”. Cyclone DDS, Fast DDS and OpenDDS send no group HEARTBEATs; expected: no effect.

§8.3.8.6 Heartbeat: report availability

Spec: §8.3.8.6, p. 63 — “It informs the Reader of the sequence numbers that are available in the writer’s HistoryCache so that the Reader may request (using an AckNack) any that it has missed.”

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat: update_from_heartbeat); crates/rtps/src/writer_proxy.rs

Tests: crates/rtps/src/writer_proxy.rs::tests::heartbeat_sets_available_range, crates/rtps/src/reliable_reader.rs::tests::heartbeat_with_missing_triggers_acknack_after_delay

Status: done

§8.3.8.6 Heartbeat without FinalFlag requires an AckNack

Spec: §8.3.8.6, p. 63 — “if the FinalFlag is not set, then the Reader must send an AckNack message indicating which CacheChange changes it has received, even if the AckNack indicates it has received all CacheChange changes in the writer’s HistoryCache.”

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat, tick_outbound)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_heartbeat_without_the_final_flag_is_answered_when_everything_is_received

Status: done — a HEARTBEAT without the FinalFlag triggers an ACKNACK even when everything is received (bitmapBase behind the last number, nothing missing), with and without the LivelinessFlag.

§8.3.8.6 Heartbeat LivelinessFlag renews the manual lease

Spec: §8.3.8.6, p. 63 — “The RTPS Reader should therefore renew the manual liveliness lease of the corresponding remote DDS DataWriter.”

Repo: crates/dcps/src/runtime.rs (handle_user_datagram_from: liveliness.writer_asserted on h.liveliness_flag)

Tests: crates/dcps/tests/liveliness_qos.rs::linux::assert_liveliness_keeps_a_manual_writer_alive_at_a_remote_reader

Status: done

§8.3.8.6 Heartbeat: content of the GroupInfoFlag

Repo: crates/rtps/src/submessages.rs (HeartbeatFragSubmessage::read_body)

Status: done — the shortening is recognised; the submessage is invalid and the rest of the message with it, the submessages before it stand (ParsedDatagram::invalid_rest, counted).

§8.3.8.7 HeartbeatFrag invalid: writerSN ≤ 0

Spec: §8.3.8.7, p. 64 — “writerSN.value is zero or negative”.

Repo: crates/rtps/src/submessages.rs (HeartbeatFragSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::fragment_submessages_validity_rules, crates/rtps/src/reliable_reader.rs::tests::a_heartbeat_frag_is_answered_when_an_available_fragment_is_missing

Status: done — a writerSN below 1 is refused.

Repo: crates/rtps/src/submessages.rs (InfoSourceSubmessage::guid_prefix)

Tests: crates/rtps/src/datagram.rs::tests::receiver_walk_attributes_submessages_after_info_source_to_the_new_prefix

Status: done

Spec: §8.3.8.11, p. 68 — “submessageLength in the Submessage header is too small.”

Repo: crates/rtps/src/submessages.rs (InfoTimestampSubmessage::read_body)

Status: done — the shortening is recognised; the submessage is invalid and the rest of the message with it, the submessages before it stand (ParsedDatagram::invalid_rest, counted).

§8.3.8.11 InfoTimestamp: set haveTimestamp and timestamp

Spec: §8.3.8.11, p. 68 — “if ( !InfoTimestamp.InvalidateFlag ) { Receiver.haveTimestamp = true; Receiver.timestamp = InfoTimestamp.timestamp … } else { Receiver.haveTimestamp = false }”.

Repo: crates/rtps/src/receiver_state.rs (ReceiverState::apply_info_timestamp)

Tests: crates/rtps/src/receiver_state.rs::tests::apply_info_timestamp_sets_value, crates/rtps/src/receiver_state.rs::tests::apply_info_timestamp_with_invalidate_clears, crates/rtps/src/datagram.rs::tests::receiver_walk_info_timestamp_invalidate_clears_have_timestamp

Spec: §8.3.8.12, p. 69, Table 8.50 — “count: Count — A counter that is incremented each time a new NackFrag message is sent.”

Repo: crates/rtps/src/reliable_reader.rs (build_nackfrag_datagram)

Tests: crates/rtps/src/reliable_reader.rs::tests::the_counts_of_acknack_and_nack_frag_rise_with_each_message

Status: done — successive NACK_FRAGs carry the counts 1, 2, 3.

§8.3.8.12 NackFrag invalid: submessageLength too small

Spec: §8.3.8.12, p. 69 — “submessageLength in the Submessage header is too small.”

Repo: crates/rtps/src/submessages.rs (NackFragSubmessage::read_body)

Status: done — the shortening is recognised; the submessage is invalid and the rest of the message with it, the submessages before it stand (ParsedDatagram::invalid_rest, counted).

§8.3.8.12 NackFrag invalid: writerSN ≤ 0

Spec: §8.3.8.12, p. 69 — “writerSN.value is zero or negative.”

Repo: crates/rtps/src/submessages.rs (NackFragSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::fragment_submessages_validity_rules

Status: done — a writerSN below 1 is refused.

§8.3.8.12 NackFrag invalid: invalid fragmentNumberState

Spec: §8.3.8.12, p. 69 — “fragmentNumberState is invalid (as defined in 8.3.5.7).”

Repo: crates/rtps/src/submessages.rs (FragmentNumberSet::read_from)

Tests: crates/rtps/src/submessages.rs::validity_tests::fragment_submessages_validity_rules, crates/rtps/src/submessages.rs::tests::fnset_rejects_num_bits_above_256

Status: done — numBits > 256 and bitmapBase < 1 are refused.

§8.3.8.12 NackFrag: writerGUID = {destGuidPrefix, writerId}

Spec: §8.3.8.12, p. 69 — “writerGUID = { Receiver.destGuidPrefix, NackFrag.writerId }”.

Repo: crates/dcps/src/runtime.rs (handle_user_datagram_from: rt.writer_slot(nf.writer_id))

Tests: crates/dcps/src/runtime.rs::tests::the_submessages_after_an_info_destination_for_another_participant_are_not_ours

Status: done

§8.3.8.12 NackFrag: readerGUID = {sourceGuidPrefix, readerId}

Spec: §8.3.8.12, p. 69 — “readerGUID = { Receiver.sourceGuidPrefix, NackFrag.readerId }”.

Repo: crates/dcps/src/runtime.rs (handle_user_datagram_from: Guid::new(src_prefix, nf.reader_id)); crates/rtps/src/reliable_writer.rs (handle_nackfrag)

Tests: crates/rtps/src/reliable_writer.rs::tests::handle_nackfrag_unknown_source_counts

Status: done

§8.3.8.13 Pad: Purpose

Spec: §8.3.8.13, p. 69 — “The purpose of this Submessage is to allow the introduction of any padding necessary to meet any desired memory- alignment requirements. It has no other meaning.”

Repo: —

Tests: —

Status: n/a (informative) — statement of purpose.

§8.3.8.13 Pad: length from submessageLength, always valid

Spec: §8.3.8.13, p. 69 — “This Submessage has no contents. … The amount of padding is determined by the value of submessageLength. … This Submessage is always valid.”

Repo: crates/rtps/src/datagram.rs (decode_datagram: PAD skipped as ParsedSubmessage::Unknown, length 0 as a length)

Tests: crates/rtps/src/datagram.rs::tests::pad_submessage_is_skipped_and_the_data_behind_it_still_decodes, crates/rtps/src/datagram.rs::tests::pad_submessage_is_skipped_and_re_encoded_byte_for_byte

Status: done

§8.4 Behavior Module

§8.4.1 Overview

Spec: §8.4.1, p. 70 — structure of the module; §8.4.2 holds the obligations, §8.4.7–§8.4.12 two reference implementations.

Repo: —

Tests: —

Status: n/a (informative) — structure.

§8.4.1 The DataWriter removes changes only per communication status and QoS

Spec: §8.4.1, p. 70 — “It is the responsibility of the DDS DataWriter to only remove those CacheChange changes that can be removed based on the communication status and the DDS DataWriter’s QoS. For example, the HISTORY QoS setting of KEEP_LAST with a depth of 1 allows a DataWriter to remove a CacheChange if a more recent change replaces the value of the same data-object.”

Repo: crates/rtps/src/reliable_writer.rs (remove_acknowledged, KEEP_LAST eviction through HistoryCache::insert_returning_evicted); crates/dcps/src/runtime.rs (await_writer_room for KEEP_ALL)

Tests: crates/rtps/src/reliable_writer.rs::tests::keep_last_evicts_oldest_on_overflow, crates/rtps/src/history_cache.rs::tests::keep_last_per_instance_keeps_the_newest_of_each_instance, crates/dcps/tests/reader_room_backpressure.rs::a_full_keep_all_reader_blocks_its_writer_and_loses_nothing

Status: done

§8.4.1.1 Example Behavior

Spec: §8.4.1.1, pp. 70–72 — “The contents of this sub clause are not part of the formal specification of the protocol.”

Repo: —

Tests: —

Status: n/a (informative) — explicitly not part of the formal spec.

§8.4.2 Behavior Required for Interoperability: scope

Spec: §8.4.2, pp. 72–73 — the obligations apply to exchanges between implementations of different vendors.

Repo: —

Tests: —

Status: n/a (informative) — scope; the obligations follow one by one.

§8.4.2.1 Only RTPS messages

Spec: §8.4.2.1, p. 73 — “No other messages can be used than the RTPS Messages defined in 8.3. … Vendors may extend Messages for vendor specific needs using the extension mechanisms provided by the protocol (see 8.6).”

Repo: crates/rtps/src/datagram.rs (decode_datagram, encode_datagram); crates/rtps/src/parameter_list.rs (vendor PIDs SHM_LOCATOR, ZERODDS_TYPE_ID)

Tests: crates/rtps/tests/vendor_frames.rs::cyclone_session_re_encodes_byte_for_byte, crates/rtps/tests/vendor_frames.rs::rti_session_re_encodes_byte_for_byte

Status: done — the deviation in the HeaderExtension id is listed under §9.4.5.1.1.

§8.4.2.1 Message receiver implemented

Spec: §8.4.2.1, p. 73 — “Implementations must implement the rules followed by the RTPS Message Receiver, as introduced in 8.3.4 … This requirement also includes proper Message formatting by preceding Entity Submessages with Interpreter Submessages when required”.

Repo: crates/rtps/src/datagram.rs (ParsedDatagram::receiver_walk); crates/rtps/src/reliable_writer.rs (INFO_TS and INFO_DST before DATA, HEARTBEAT); crates/rtps/src/reliable_reader.rs (wrap_to_writer)

Tests: crates/rtps/src/datagram.rs::tests::receiver_walk_attributes_submessages_after_info_source_to_the_new_prefix, crates/rtps/src/reliable_writer.rs::tests::write_stamped_prepends_info_ts_before_data, crates/rtps/src/reliable_reader.rs::tests::pre_emptive_acknack_carries_info_dst

Status: done — the receiver is implemented; the items under §8.3.4, §8.3.4.1 and §8.3.8 in which it differed from the spec (“Valid submessages before an invalid one”, “destGuidPrefix on the data path” and others) are done.

§8.4.2.1 Timing tunable

Spec: §8.4.2.1, p. 73 — “where the requirements on the protocol behavior allow delayed responses or specify periodic events, implementations must allow the end-user to tune those timing characteristics.”

Repo: crates/dcps/src/runtime.rs (RuntimeConfig::nack_response_delay, nack_suppression_duration, writer_heartbeat_period, reader_heartbeat_response_delay, reader_heartbeat_suppression_duration, spdp_period, wlp_period)

Tests: crates/dcps/tests/runtime_config_layering.rs::the_protocol_timing_parameters_are_settings, crates/rtps/src/reliable_writer.rs::tests::a_repair_waits_for_the_nack_response_delay, crates/rtps/src/reliable_writer.rs::tests::a_nack_inside_the_suppression_duration_is_ignored

Status: done — nackResponseDelay, nackSuppressionDuration, heartbeatPeriod, heartbeatResponseDelay, heartbeatSuppressionDuration, the SPDP and the WLP period are settings (writer.*_ms, reader.*_ms, discovery.*_ms, man page and example configuration).

§8.4.2.1 HEARTBEAT timings of the user endpoints tunable

Spec: §8.4.2.1, p. 73 — as the previous item; §8.4.7.1 Table 8.53 heartbeatPeriod, §8.4.10.1 Table 8.67 heartbeatResponseDelay, heartbeatSuppressionDuration.

Repo: crates/dcps/src/runtime.rs (writer_heartbeat_period, reader_heartbeat_response_delay, reader_heartbeat_suppression_duration)

Tests: crates/dcps/tests/runtime_config_layering.rs::the_protocol_timing_parameters_are_settings

Status: done — writer.heartbeat_period_ms, reader.heartbeat_response_delay_ms, reader.heartbeat_suppression_duration_ms.

§8.4.2.1 SPDP and SEDP implemented

Spec: §8.4.2.1, p. 73 — “For the purpose of interoperability, implementations must implement at least the Simple Participant Discovery Protocol and Simple Endpoint Discovery Protocol (see 8.5.1).”

Repo: crates/discovery/src/spdp.rs; crates/discovery/src/sedp/stack.rs

Tests: crates/discovery/src/spdp.rs::tests::beacon_serializes_to_decodable_datagram, crates/discovery/src/sedp/stack.rs::tests::end_to_end_discovery_between_two_stacks

Status: done — the individual obligations are under §8.5.

§8.4.2.2 Writers do not send out of order

Spec: §8.4.2.2, p. 73 — “A Writer must send out data samples in the order they were added to its HistoryCache.”

Repo: crates/rtps/src/reliable_writer.rs (write_sample_with_inline_qos: sends only to a proxy that is in step; repairs ascending through next_requested_change)

Tests: crates/rtps/tests/reliable_e2e.rs::e2e_zero_loss_delivers_all_in_order, crates/rtps/src/reliable_writer.rs::tests::repairs_in_order_bring_a_lagging_proxy_into_step

Status: done

§8.4.2.2 Writers send in-line QoS on the reader’s request

Spec: §8.4.2.2, p. 73 — “A Writer must honor a Reader’s request to receive data messages with in-line QoS.”

Repo: crates/rtps/src/reliable_writer.rs (set_inline_writer_qos, sample_inline_qos); crates/rtps/src/reader_proxy.rs (ReaderProxy::expects_inline_qos)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_reader_that_expects_inline_qos_gets_the_writers_qos_with_each_data

Status: done

§8.4.2.2 Periodic HEARTBEATs (reliable only)

Spec: §8.4.2.2, pp. 73–74 — “A Writer must periodically inform each matching reliable Reader of the availability of a data sample by sending a periodic HEARTBEAT Message … For strict reliable communication, the Writer must continue to send HEARTBEAT Messages to a Reader until the Reader has either acknowledged receiving all available samples or has disappeared.”

Repo: crates/rtps/src/reliable_writer.rs (tick: announcing, heartbeat_due)

Tests: crates/rtps/src/reliable_writer.rs::tests::tick_emits_heartbeat_after_period, crates/rtps/src/reliable_writer.rs::tests::an_acknowledged_reader_is_heartbeated_until_it_answers_one, crates/rtps/src/reliable_writer.rs::tests::a_reader_that_acknowledged_the_cache_gets_no_periodic_heartbeat

Status: done

§8.4.2.2 Response to a negative acknowledgement (reliable only)

Spec: §8.4.2.2, p. 74 — “When receiving an ACKNACK Message indicating a Reader is missing some data samples, the Writer must respond by either sending the missing data samples, sending a GAP message when the sample is not relevant, or sending a HEARTBEAT message when the sample is no longer available.”

Repo: crates/rtps/src/reliable_writer.rs (tick: DATA from the cache, GAP through append_gap for changes no longer present)

Tests: crates/rtps/src/reliable_writer.rs::tests::tick_resends_requested_as_data_aggregated_with_hb, crates/rtps/src/reliable_writer.rs::tests::tick_resends_evicted_request_as_gap

Status: done

§8.4.2.2 HEARTBEAT and GAP with writer group information

Spec: §8.4.2.2, p. 74 — “A Writer belonging to a Group shall send HEARTBEAT or GAP Submessages to its matched Readers even if the Reader has acknowledged all of that Writer’s samples.”

Repo: —

Tests: crates/rtps/src/reliable_writer.rs::tests::a_group_writer_heartbeats_an_acknowledged_reader_when_the_group_moved_on, crates/rtps/src/reliable_writer.rs::tests::a_group_writer_with_an_empty_cache_is_due_for_a_heartbeat

Status: done

§8.4.2.3 Best-effort readers are passive

Spec: §8.4.2.3, p. 74 — “A best-effort Reader is completely passive as it only receives data and does not send messages itself.”

Repo: crates/rtps/src/reliable_reader.rs (ReliableReader::tick_outbound)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_best_effort_reader_sends_no_acknack

Status: done — a reader with set_best_effort(true) sends neither ACKNACK nor NACK_FRAG, neither on matching nor in answer to HEARTBEATs.

§8.4.2.3 Response to a HEARTBEAT without FinalFlag

Spec: §8.4.2.3, p. 74 — “Upon receiving a HEARTBEAT Message with final flag not set, the Reader must respond with an ACKNACK Message. … The response may be delayed to avoid message storms.”

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat, tick_outbound)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_heartbeat_with_the_liveliness_flag_is_taken_as_a_heartbeat

Status: done

§8.4.2.3 Response to a HEARTBEAT with missing samples

Spec: §8.4.2.3, p. 74 — “a Reader that is missing some data samples must respond with an ACKNACK Message indicating which data samples are missing. This requirement only applies if the Reader can accommodate these missing samples in its cache … The response is not required when a liveliness HEARTBEAT has both liveliness and final flags set”.

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat, tick_outbound, full_for_the_consumer, build_acknack_datagram)

Tests: crates/rtps/src/reliable_reader.rs::tests::heartbeat_with_missing_triggers_acknack_after_delay, crates/rtps/src/reliable_reader.rs::tests::a_cache_full_for_the_consumer_holds_the_acknack_until_it_takes, crates/rtps/src/reliable_reader.rs::tests::a_cache_full_behind_a_missing_change_still_names_it

Status: done

§8.4.2.3 Once acknowledged, always acknowledged (reader)

Spec: §8.4.2.3, p. 74 — “Once a Reader has positively acknowledged receiving a sample using an ACKNACK Message, it can no longer negatively acknowledge that same sample at a later point.”

Repo: crates/rtps/src/writer_proxy.rs (acknack_base monotonic; unreceive_change_set only above the base)

Tests: crates/rtps/src/writer_proxy.rs::tests::acknack_base_walks_up, crates/rtps/src/reliable_reader.rs::tests::sample_rejected_by_a_full_cache_stays_missing_for_the_acknack

Status: done

§8.4.2.3 The writer resends acknowledged samples requested again

Spec: §8.4.2.3, p. 74 — “if a Writer receives a negative acknowledgement to a previously positively acknowledged sample, and the Writer can still service the request, the Writer should send the sample.”

Repo: crates/rtps/src/reader_proxy.rs (requested_changes_set); crates/rtps/src/reliable_writer.rs (handle_acknack_window, tick)

Tests: crates/rtps/src/reader_proxy.rs::tests::a_request_for_an_acknowledged_change_is_kept, crates/rtps/src/reliable_writer.rs::tests::an_acknowledged_change_asked_for_again_is_sent_again

Status: done — a new request for an acknowledged sample is kept; the writer sends it while its cache holds it, a GAP otherwise.

§8.4.2.3 ACKNACK only in response to a HEARTBEAT

Spec: §8.4.2.3, p. 74 — “In steady state, an ACKNACK Message can only be sent as a response to a HEARTBEAT Message from a Writer. ACKNACK Messages can be sent from a Reader when it first discovers a Writer as an optimization.”

Repo: crates/rtps/src/reliable_reader.rs (add_writer_proxy, handle_heartbeat, handle_data_frag_opening, tick_outbound)

Tests: crates/rtps/src/reliable_reader.rs::tests::acknack_and_nack_frag_wait_for_a_heartbeat, crates/rtps/src/reliable_reader.rs::tests::pre_emptive_acknack_emitted_after_add_writer_proxy

Status: done — an ACKNACK follows from a HEARTBEAT (Table 8.77 T2) and from the first match of a writer; neither the repeated add_writer_proxy of a known writer nor a DATA_FRAG with holes arms one.

§8.4.3 Implementing the RTPS Protocol

Spec: §8.4.3, p. 75 — “a compliant implementation of the protocol need only satisfy the requirements presented in 8.4.2. … Actual implementations need not necessarily follow the reference implementations.”

Repo: —

Tests: —

Status: n/a (informative) — makes the reference implementations optional. The transitions under §8.4.8–§8.4.12 are checked against the ZeroDDS types that model a reference implementation: ReliableWriter (stateful writer, best effort and reliable, user-data path), ReliableReader (stateful reader), BestEffortWriter, ReliableStatelessWriter, BestEffortReader (used in tests only) and the SPDP beacon.

§8.4.4 Permitted combinations of reliabilityLevel

Spec: §8.4.4, p. 75 — “An RTPS Writer cannot be matched to an RTPS Reader unless either the RTPS Writer has the reliabilityLevel set to RELIABLE, or else both the RTPS Writer and RTPS Reader have the reliabilityLevel set to BEST_EFFORT.”

Repo: crates/qos/src/policies/reliability.rs (ReliabilityKind ordering); QoS comparison on matching in crates/dcps/src/runtime.rs; the ReaderProxy is reliable only with a reliable writer and reader (ReaderProxy::new in the SEDP match path of crates/dcps/src/runtime.rs)

Tests: crates/qos/src/policies/reliability.rs::tests::best_effort_lt_reliable, crates/qos/src/policies/reliability.rs::tests::ordering_reliable_higher_than_besteffort, crates/dcps/tests/transient_local_durability.rs::linux::transient_local_writer_delivers_history_to_late_joiner

Status: done — the comparison of offered and requested QoS is listed in the DCPS audit.

§8.4.4 Stateful and stateless interoperate

Spec: §8.4.4, p. 75 — “a Stateful Writer is able to communicate with a Stateless Reader and vice versa.”

Repo: —

Tests: —

Status: n/a (informative) — follows from §8.4.2; no requirement of its own.

§8.4.5 Notational Conventions

Spec: §8.4.5, pp. 75–76, Table 8.51 — abbreviations DW, DR, W, RP, RL, R, WP, WHC, RHC.

Repo: —

Tests: —

Status: n/a (informative) — notation.

§8.4.6 Table 8.52 Duration_t

Spec: §8.4.6, p. 76, Table 8.52 — “Duration_t: Type used to hold time differences. Should have at least nano-second resolution.”

Repo: crates/qos/src/duration.rs (Duration {seconds, fraction}, 2⁻³² s)

Tests: crates/dcps/src/time.rs::tests::duration_zero_and_infinite_sentinels, crates/rtps/src/participant_data.rs::tests::duration_roundtrip_le

Status: done

§8.4.6 Table 8.52 ChangeForReaderStatusKind

Spec: §8.4.6, p. 76, Table 8.52 — “UNSENT, UNACKNOWLEDGED, REQUESTED, ACKNOWLEDGED, UNDERWAY”.

Repo: crates/rtps/src/reader_proxy.rs (highest_sent_sn, highest_acked_sn, requested_changes instead of a status per change)

Tests: crates/rtps/src/reader_proxy.rs::tests::next_unsent_change_walks_sequentially, crates/rtps/src/reader_proxy.rs::tests::acking_also_prunes_requested_changes

Status: done — modelled as counters and sets (§8.4.15.1).

§8.4.6 Table 8.52 ChangeFromWriterStatusKind

Spec: §8.4.6, p. 76, Table 8.52 — “NOT_AVAILABLE, MISSING, RECEIVED, UNKNOWN. There are three sub-kinds of NOT_AVAILABLE: NA_FILTERED, NA_REMOVED, NA_UNSPECIFIED”.

Repo: crates/rtps/src/writer_proxy.rs (ChangeFromWriterStatus, WriterProxy::change_status, NotAvailableKind, not_available_change_set, lost_changes_update); crates/rtps/src/reliable_reader.rs (ReliableReader::change_status, handle_gap)

Tests: crates/rtps/src/writer_proxy.rs::tests::change_status_is_kept_per_change_with_the_sub_kind, crates/rtps/src/writer_proxy.rs::tests::lost_changes_update_sets_na_removed_per_change, crates/rtps/src/writer_proxy.rs::tests::not_available_runs_are_joined_and_bounded, crates/rtps/src/reliable_reader.rs::tests::the_reader_keeps_the_status_of_each_change, crates/rtps/src/reliable_reader.rs::tests::a_gap_sorts_its_changes_by_the_filtered_count

Status: done — UNKNOWN, MISSING, RECEIVED and NOT_AVAILABLE with the sub-kinds NA_FILTERED, NA_REMOVED and NA_UNSPECIFIED are kept per change (WriterProxy::change_status). The NOT_AVAILABLE changes are held as runs of one sub-kind (at most 4096; older means None). lost_changes_update enters NA_REMOVED and counts it; a change with the FilteredFlag enters NA_FILTERED.

§8.4.6 Table 8.52 InstanceHandle_t

Spec: §8.4.6, p. 76, Table 8.52 — “Type used to represent the identity of a data-object whose changes in value are communicated by the RTPS protocol.”

Repo: crates/rtps/src/history_cache.rs (CacheChange::key_hash)

Tests: crates/rtps/src/history_cache.rs::tests::the_instance_index_follows_inserts_evictions_and_removals

Status: done — as Table 8.2 (§8.2.1.2).

§8.4.6 Table 8.52 ParticipantMessageData

Spec: §8.4.6, p. 76, Table 8.52 — “Type used to hold data exchanged between Participants. The most notable use of this type is for the Writer Liveliness Protocol.”

Repo: crates/rtps/src/participant_message_data.rs (ParticipantMessageData)

Tests: crates/rtps/src/participant_message_data.rs::tests::participant_message_data_roundtrip_le

Status: done — content and wire format under §8.4.13.4 and §9.6.3.1.

§8.4.7.1 Table 8.53 Writer pushMode

Spec: §8.4.7.1, p. 78, Table 8.53 — “If pushMode==true, then the Writer will push changes to the reader. If pushMode==false, changes will only be announced via heartbeats and only be sent as response to the request of a reader.”

Repo: crates/rtps/src/reliable_writer.rs (set_push_mode, push_mode)

Tests: crates/rtps/src/reliable_writer.rs::tests::push_mode_false_announces_by_heartbeat_and_sends_only_on_request, crates/rtps/src/reliable_writer.rs::tests::push_mode_false_sends_no_data_on_the_piggyback_path

Status: done

§8.4.7.1 Table 8.53 Writer heartbeatPeriod

Spec: §8.4.7.1, p. 78, Table 8.53 — “heartbeatPeriod: Protocol tuning parameter that allows the RTPS Writer to repeatedly announce the availability of data by sending a Heartbeat Message.”

Repo: crates/rtps/src/reliable_writer.rs (ReliableWriterConfig::heartbeat_period, DEFAULT_HEARTBEAT_PERIOD)

Tests: crates/rtps/src/reliable_writer.rs::tests::heartbeat_due_follows_the_last_heartbeat, crates/rtps/src/reliable_writer.rs::tests::tick_emits_heartbeat_after_period

Status: done — its tunability for the user is listed under §8.4.2.1.

§8.4.7.1 Table 8.53 Writer nackResponseDelay

Spec: §8.4.7.1, p. 78, Table 8.53 — “nackResponseDelay: Protocol tuning parameter that allows the RTPS Writer to delay the response to a request for data from a negative acknowledgment.”

Repo: crates/rtps/src/reliable_writer.rs (set_nack_response_delay); crates/rtps/src/reader_proxy.rs (repair_due)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_repair_waits_for_the_nack_response_delay, crates/rtps/src/reliable_writer.rs::tests::a_zero_nack_response_delay_repairs_on_the_next_tick

Status: done

§8.4.7.1 Table 8.53 Writer nackSuppressionDuration

Spec: §8.4.7.1, p. 78, Table 8.53 — “nackSuppressionDuration: Protocol tuning parameter that allows the RTPS Writer to ignore requests for data from negative acknowledgments that arrive ‘too soon’ after the corresponding change is sent.”

Repo: crates/rtps/src/reliable_writer.rs (set_nack_suppression_duration, too_soon)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_nack_inside_the_suppression_duration_is_ignored

Status: done

§8.4.7.1 Table 8.53 Writer lastChangeSequenceNumber

Spec: §8.4.7.1, p. 78, Table 8.53 — “Internal counter used to assign increasing sequence number to each change made by the Writer.”

Repo: crates/rtps/src/reliable_writer.rs (next_sn, last_written_sn)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_increments_sn_and_returns_data_datagram

Status: done

§8.4.7.1 Table 8.53 Writer writer_cache

Spec: §8.4.7.1, p. 78, Table 8.53 — “writer_cache: HistoryCache — Contains the history of CacheChange changes for this Writer.”

Repo: crates/rtps/src/reliable_writer.rs (ReliableWriter::cache)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_at_cache_capacity_is_error

Status: done

§8.4.7.1 Table 8.53 Writer dataMaxSizeSerialized

Spec: §8.4.7.1, p. 78, Table 8.53 — “Optional attribute that indicates the maximum size of any SerializedPayload that may be sent by the Writer.”

Repo: crates/dcps/src/dds_type.rs (MAX_SERIALIZED_SIZE); crates/dcps/src/publisher.rs (WriterRegistration); crates/dcps/src/runtime.rs (UserWriterConfig::data_max_size_serialized, build_publication_data)

Tests: crates/rtps/src/publication_data.rs::tests::the_max_payload_size_and_the_name_of_a_writer_travel

Status: done — the attribute is optional. The writer announces dataMaxSizeSerialized as PID_TYPE_MAX_SIZE_SERIALIZED when it is set: from DdsType::MAX_SERIALIZED_SIZE or from UserWriterConfig::data_max_size_serialized (the value is without the encapsulation header; it is announced with the 4 octets of the header). Without a value it announces nothing.

§8.4.7.1 Table 8.54 Writer new

Spec: §8.4.7.1, p. 79 — “this.lastChangeSequenceNumber := 0; this.writer_cache := new HistoryCache;” and the attributes taken from the constructor.

Repo: crates/rtps/src/reliable_writer.rs (ReliableWriter::new: next_sn: 0, a new HistoryCache)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_increments_sn_and_returns_data_datagram

Status: done

§8.4.7.1 Table 8.54 Writer new_change

Spec: §8.4.7.1, p. 79 — “The sequence number of the CacheChange is automatically set to be the sequenceNumber of the previous change plus one. … ++this.lastChangeSequenceNumber; a_change := new CacheChange(kind, this.guid, this.lastChangeSequenceNumber, data, inlineQos, handle);”

Repo: crates/rtps/src/reliable_writer.rs (stage_sample, write_lifecycle)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_increments_sn_and_returns_data_datagram, crates/rtps/src/writer.rs::tests::writer_sn_overflow_is_error

Status: done

§8.4.7.1 Default nackResponseDelay = 200 ms

Spec: §8.4.7.1, p. 79 — “nackResponseDelay.sec = 0; nackResponseDelay.nanosec = 200 * 1000 * 1000; //200 milliseconds”.

Repo: crates/rtps/src/reliable_writer.rs (DEFAULT_NACK_RESPONSE_DELAY, SPEC_NACK_RESPONSE_DELAY); crates/dcps/src/runtime.rs (RuntimeConfig::nack_response_delay)

Tests: crates/rtps/src/reliable_writer.rs::tests::nack_response_delay_defaults_to_the_spec_200_ms_and_suppression_to_zero, crates/dcps/tests/runtime_config_layering.rs::the_protocol_timing_parameters_are_settings

Status: done — DEFAULT_NACK_RESPONSE_DELAY and RuntimeConfig::nack_response_delay are 200 ms; a NACK is answered with the repair only after that time (test). writer.nack_response_delay_ms: 0 answers on the next tick.

§8.4.7.1 Default nackResponseDelay

Spec: §8.4.7.1, p. 79 — “The following timing-related values are used as the defaults in order to facilitate ‘out-of-the-box’ interoperability between implementations.”

Repo: crates/rtps/src/reliable_writer.rs (DEFAULT_NACK_RESPONSE_DELAY, DEFAULT_NACK_SUPPRESSION_DURATION); crates/dcps/src/runtime.rs; man/man5/zerodds.yaml.5; packaging/linux/configs/zerodds.yaml.example

Tests: crates/dcps/tests/runtime_config_layering.rs::the_protocol_timing_parameters_are_settings, crates/rtps/src/reliable_writer.rs::tests::nack_response_delay_defaults_to_the_spec_200_ms_and_suppression_to_zero

Status: done — the values of the spec are the defaults: nackResponseDelay 200 ms, nackSuppressionDuration 0 (runtime, YAML default, man page, example configuration). The former 0 ms stay reachable through writer.nack_response_delay_ms; tests that drive a millisecond clock set 0 explicitly.

§8.4.7.1 Default nackSuppressionDuration = 0

Spec: §8.4.7.1, p. 79 — “nackSuppressionDuration.sec = 0; nackSuppressionDuration.nanosec = 0;”.

Repo: crates/rtps/src/reliable_writer.rs (DEFAULT_NACK_SUPPRESSION_DURATION)

Tests: crates/rtps/src/reliable_writer.rs::tests::nack_response_delay_defaults_to_the_spec_200_ms_and_suppression_to_zero

Status: done

§8.4.7.2 Table 8.55 StatelessWriter reader_locators

Spec: §8.4.7.2, p. 80, Table 8.55 — “The StatelessWriter maintains the list of locators to which it sends the CacheChanges. This list may include both unicast and multicast locators.”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter::reader_locators, ReaderLocator); crates/discovery/src/spdp.rs (SpdpBeacon, target locators)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::reader_locators_are_added_looked_up_and_removed

Status: done — the list consists of ReaderLocator objects with state of their own (highest_sent_seq_num, requested changes, expects_inline_qos).

§8.4.7.2 Table 8.56 StatelessWriter new

Spec: §8.4.7.2, p. 80 — “this.reader_locators := ;”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter::new: reader_locators leer)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::reader_locators_are_added_looked_up_and_removed, crates/rtps/src/reliable_stateless_writer.rs::tests::shutdown_clears_the_cache_and_the_requests

Status: done

§8.4.7.2 Table 8.56 StatelessWriter reader_locator_add

Spec: §8.4.7.2, p. 80 — “ADD a_locator TO {this.reader_locators};”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator) reader_locator_add

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::reader_locators_are_added_looked_up_and_removed

Status: done — a locator is added as a ReaderLocator with expectsInlineQos, once per locator. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.7.2 Table 8.56 StatelessWriter reader_locator_remove

Spec: §8.4.7.3, p. 81 — “REMOVE a_locator FROM {this.reader_locators};”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter::reader_locator_remove)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::reader_locators_are_added_looked_up_and_removed

Status: done — a ReaderLocator is removed; removing it again reports false.

§8.4.7.2 Table 8.56 StatelessWriter unsent_changes_reset

Spec: §8.4.7.2, p. 81 — “This operation resets the ‘highestSentChangeSN’ for all the ReaderLocators … useful when called periodically to cause the StatelessWriter to keep re-sending all available changes”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter::unsent_changes_reset, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::unsent_changes_reset_makes_every_change_unsent_again, crates/rtps/src/reliable_stateless_writer.rs::tests::unsent_changes_are_pushed_in_order_then_announced

Status: done — unsent_changes_reset sets highestSentChangeSN of all ReaderLocators to 0; the next tick sends all changes of the cache again to every locator. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.7.3 Table 8.57 ReaderLocator attributes

Spec: §8.4.7.3, p. 81, Table 8.57 — highestSentChangeSN, requestedChanges, locator, expectsInlineQos.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Status: done — ReaderLocator holds locator, expects_inline_qos, highest_sent_seq_num and the requested changes. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.7.3 Table 8.58 ReaderLocator operations

Spec: §8.4.7.3, pp. 81–82, Table 8.58 — new, next_requested_change, next_unsent_change, requested_changes, requested_changes_set, unsent_changes.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Status: done — requested_changes, requested_changes_set, next_requested_change, unsent_changes are methods of ReaderLocator; next_unsent_change is in the push machine (next_cached_above). ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.7.4 Table 8.59 StatefulWriter matched_readers

Spec: §8.4.7.4, p. 83, Table 8.59 — “The StatefulWriter keeps track of all the RTPS Readers matched with it. Each matched reader is represented by an instance of the ReaderProxy class.”

Repo: crates/rtps/src/reliable_writer.rs (reader_proxies, reader_proxies())

Tests: crates/rtps/src/reliable_writer.rs::tests::write_fans_out_to_all_reader_proxies

Status: done

§8.4.7.4 Table 8.60 StatefulWriter new

Spec: §8.4.7.4, p. 83 — “this.matched_readers := ;”

Repo: crates/rtps/src/reliable_writer.rs (ReliableWriter::new with ReliableWriterConfig::reader_proxies)

Tests: crates/rtps/src/reliable_writer.rs::tests::is_acked_by_all_without_proxies_is_true

Status: done

§8.4.7.4 Table 8.60 StatefulWriter is_acked_by_all

Spec: §8.4.7.4, p. 83 — “return true IF and only IF FOREACH proxy IN this.matched_readers a_change_seq_num IN proxy.acknowledged_changes”.

Repo: crates/rtps/src/reliable_writer.rs (is_acked_by_all)

Tests: crates/rtps/src/reliable_writer.rs::tests::is_acked_by_all_follows_the_slowest_reader_proxy, crates/rtps/src/reliable_writer.rs::tests::is_acked_by_all_without_proxies_is_true

Status: done

§8.4.7.4 Table 8.60 StatefulWriter matched_reader_add

Spec: §8.4.7.4, pp. 83–84 — “ADD a_reader_proxy TO {this.matched_readers};”

Repo: crates/rtps/src/reliable_writer.rs (add_reader_proxy)

Tests: crates/rtps/src/reliable_writer.rs::tests::add_reader_proxy_is_idempotent_on_same_guid, crates/rtps/src/reliable_writer.rs::tests::heartbeat_after_add_reader_proxy_is_non_final

Status: done

§8.4.7.4 Table 8.60 StatefulWriter matched_reader_remove

Spec: §8.4.7.4, p. 84 — “REMOVE a_reader_proxy FROM {this.matched_readers}; delete proxy;”

Repo: crates/rtps/src/reliable_writer.rs (remove_reader_proxy)

Tests: crates/rtps/src/reliable_writer.rs::tests::remove_reader_proxy_by_guid

Status: done

§8.4.7.4 Table 8.60 StatefulWriter matched_reader_lookup

Spec: §8.4.7.4, p. 84 — “FIND proxy IN this.matched_readers SUCH-THAT (proxy.remoteReaderGuid == a_reader_guid); return proxy;”

Repo: crates/rtps/src/reliable_writer.rs (handle_acknack_window, handle_nackfrag: lookup by remote_reader_guid)

Tests: crates/rtps/src/reliable_writer.rs::tests::acknack_dispatches_to_matching_proxy_only

Status: done

§8.4.7.5 Table 8.61 ReaderProxy remoteReaderGuid

Spec: §8.4.7.5, p. 84, Table 8.61 — “remoteReaderGuid: GUID_t — Identifies the remote matched RTPS Reader that is represented by the ReaderProxy.”

Repo: crates/rtps/src/reader_proxy.rs (ReaderProxy::remote_reader_guid)

Tests: crates/rtps/src/reliable_writer.rs::tests::add_reader_proxy_is_idempotent_on_same_guid

Status: done

§8.4.7.5 Table 8.61 ReaderProxy remoteGroupEntityId

Spec: §8.4.7.5, p. 84, Table 8.61 — “remoteGroupEntityId: EntityId_t — Identifies the group to which the matched Reader belongs”.

Repo: crates/rtps/src/reader_proxy.rs (ReaderProxy::remote_group_entity_id, with_remote_group_entity_id); crates/dcps/src/runtime.rs (match path, PID_GROUP_GUID of the subscription)

Tests: crates/rtps/src/reader_proxy.rs::tests::the_remote_group_entity_id_is_kept, crates/dcps/src/runtime.rs::tests::the_proxies_of_a_match_carry_the_remote_group_entity_id

Status: done — the proxy holds remoteGroupEntityId; the match path fills it from PID_GROUP_GUID of the reader’s SEDP announcement, ENTITYID_UNKNOWN without a group.

§8.4.7.5 Table 8.61 ReaderProxy unicastLocatorList

Spec: §8.4.7.5, p. 84, Table 8.61 — “List of unicast locators … that can be used to send messages to the matched RTPS Reader. The list may be empty.”

Repo: crates/rtps/src/reader_proxy.rs (ReaderProxy::unicast_locators)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_fans_out_to_every_unicast_locator_of_a_proxy

Status: done

§8.4.7.5 Table 8.61 ReaderProxy multicastLocatorList

Spec: §8.4.7.5, p. 84, Table 8.61 — “List of multicast locators … that can be used to send messages to the matched RTPS Reader. The list may be empty.”

Repo: crates/rtps/src/reader_proxy.rs (ReaderProxy::multicast_locators); crates/rtps/src/reliable_writer.rs (proxy_targets_of)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_reader_proxy_with_multicast_locators_is_sent_to_at_the_multicast_locator

Status: done — a proxy with multicast locators is sent to there (DATA and HEARTBEAT, one datagram for the group), one without at its unicast locators. The SEDP match path passes an empty list (“The list may be empty”); the unicast locators of the reader apply then.

§8.4.7.5 Table 8.61 ReaderProxy highestSentChangeSN

Spec: §8.4.7.5, p. 84, Table 8.61 — “The highest sequence number of the changes that have been sent to the matched RTPS Reader.”

Repo: crates/rtps/src/reader_proxy.rs (highest_sent_sn)

Tests: crates/rtps/src/reader_proxy.rs::tests::next_unsent_change_walks_sequentially

Status: done

§8.4.7.5 Table 8.61 ReaderProxy requestedChanges

Spec: §8.4.7.5, p. 84, Table 8.61 — “A list of sequence numbers representing changes that were requested by the matched RTPS Reader.”

Repo: crates/rtps/src/reader_proxy.rs (requested_changes)

Tests: crates/rtps/src/reader_proxy.rs::tests::a_request_for_an_acknowledged_change_is_kept

Status: done

§8.4.7.5 Table 8.61 ReaderProxy acknowledgedChanges

Spec: §8.4.7.5, pp. 84–85, Table 8.61 — “A list of sequence numbers representing changes that have been acknowledged by the matched RTPS Reader.”

Repo: crates/rtps/src/reader_proxy.rs (highest_acked_sn)

Tests: crates/rtps/src/reader_proxy.rs::tests::acked_changes_set_monotonic

Status: done — kept as the highest acknowledged number.

§8.4.7.5 Table 8.61 ReaderProxy expectsInlineQos

Spec: §8.4.7.5, p. 85, Table 8.61 — “Specifies whether the remote matched RTPS Reader expects in-line QoS to be sent along with any data.”

Repo: crates/rtps/src/reader_proxy.rs (expects_inline_qos, set_expects_inline_qos)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_reader_that_expects_inline_qos_gets_the_writers_qos_with_each_data

Status: done

§8.4.7.5 Table 8.61 ReaderProxy isActive

Spec: §8.4.7.5, p. 85, Table 8.61 — “isActive: bool — Specifies whether the remote Reader is responsive to the Writer.”

Repo: crates/rtps/src/reader_proxy.rs (note_activity, is_inactive)

Tests: crates/rtps/src/reader_proxy.rs::tests::proxy_becomes_inactive_after_threshold_elapses, crates/rtps/src/reader_proxy.rs::tests::proxy_is_active_after_note_activity

Status: done

§8.4.7.5 Matching follows the DDS match

Spec: §8.4.7.5, p. 85 — “The matching is a consequence of the match of the corresponding DDS entities. That is, the DDS DataWriter matches a DDS DataReader by Topic, has compatible QoS, and is not being explicitly ignored by the application that uses DDS.”

Repo: crates/dcps/src/runtime.rs (SEDP match, add_reader_proxy); crates/dcps/src/participant.rs (ignore_subscription)

Tests: crates/discovery/src/sedp/stack.rs::tests::end_to_end_discovery_between_two_stacks, crates/dcps/tests/xtypes_aware_match.rs::final_vs_appendable_mismatch_rejected_at_match_time

Status: done

§8.4.7.5 Table 8.62 ReaderProxy new

Spec: §8.4.7.5, p. 85 — “this.requested_changes := ; this.acknowledged_changes := ; this.highest_sent_seq_num := 0;”

Repo: crates/rtps/src/reader_proxy.rs (ReaderProxy::new)

Tests: crates/rtps/src/reader_proxy.rs::tests::fresh_proxy_has_zero_state

Status: done

§8.4.7.5 Table 8.62 ReaderProxy acked_changes_set

Spec: §8.4.7.5, p. 86 — “FOR_EACH seq_num <= committed_seq_num DO ADD seq_num TO this.acknowledged_changes”.

Repo: crates/rtps/src/reader_proxy.rs (acked_changes_set)

Tests: crates/rtps/src/reader_proxy.rs::tests::acked_changes_set_monotonic, crates/rtps/src/reader_proxy.rs::tests::acking_also_prunes_requested_changes

Status: done — the parameter is readerSNState.base, the acknowledged upper bound base − 1.

§8.4.7.5 Table 8.62 ReaderProxy next_requested_change

Spec: §8.4.7.5, p. 86 — “return MIN( this.requested_changes() );”

Repo: crates/rtps/src/reader_proxy.rs (next_requested_change)

Tests: crates/rtps/src/reader_proxy.rs::tests::next_requested_change_pulls_smallest_first

Status: done

§8.4.7.5 Table 8.62 ReaderProxy next_unsent_change

Spec: §8.4.7.5, p. 86 — “unsent_changes := { changes SUCH-THAT change.sequenceNumber > this.higuest_sent_seq_num } … ELSE return MIN { unsent_changes.sequenceNumber }”.

Repo: crates/rtps/src/reader_proxy.rs (next_unsent_change)

Tests: crates/rtps/src/reader_proxy.rs::tests::next_unsent_change_walks_sequentially, crates/rtps/src/reader_proxy.rs::tests::next_unsent_change_picks_up_after_cache_grows

Status: done — returns highest_sent + 1 up to the cache maximum; tick answers numbers no longer present with a GAP.

§8.4.7.5 Table 8.62 ReaderProxy requested_changes

Spec: §8.4.7.5, p. 86 — “return this.requested_changes”.

Repo: crates/rtps/src/reader_proxy.rs (pending_requested_count, next_requested_change)

Tests: crates/rtps/src/reader_proxy.rs::tests::a_request_for_an_acknowledged_change_is_kept

Status: done

§8.4.7.5 Table 8.62 ReaderProxy requested_changes_set

Spec: §8.4.7.5, p. 86 — “FOR_EACH seq_num IN req_seq_num_set DO ADD seq_num TO this.requested_changes;”

Repo: crates/rtps/src/reader_proxy.rs (requested_changes_set)

Tests: crates/rtps/src/reader_proxy.rs::tests::a_request_for_an_acknowledged_change_is_kept

Status: done — takes every requested number from the ACKNACK’s base on, also one acknowledged before (§8.4.2.3).

§8.4.7.5 Table 8.62 ReaderProxy unsent_changes

Spec: §8.4.7.5, p. 86 — “return ( this.next_unsent_change() != SEQUENCE_NUMBER_INVALID )”.

Repo: crates/rtps/src/reader_proxy.rs (highest_sent_sn against the cache maximum)

Tests: crates/rtps/src/reader_proxy.rs::tests::next_unsent_change_picks_up_after_cache_grows

Status: done

§8.4.7.5 Table 8.62 ReaderProxy unacked_changes

Spec: §8.4.7.5, p. 86 — “return ( highest_available_seq_num > highest_acked_seq_num )”.

Repo: crates/rtps/src/reader_proxy.rs (unacked_changes)

Tests: crates/rtps/src/reader_proxy.rs::tests::unacked_changes_detects_gap

Status: done

§8.4.8.1 Table 8.63 best-effort StatelessWriter T1

Spec: §8.4.8.1, pp. 87–88, Table 8.63 T1 — “a_locator := new ReaderLocator( locator, expectsInlineQos ); the_rtps_writer.reader_locator_add( a_locator );”

Repo: crates/discovery/src/spdp.rs (SpdpBeacon); crates/dcps/src/runtime.rs (RuntimeConfig::initial_peers, the SPDP multicast locator)

Tests: crates/dcps/src/runtime.rs::tests::initial_peer_specs_expand_per_the_configured_participant_limit, crates/discovery/src/spdp.rs::tests::beacon_serializes_to_decodable_datagram

Status: done — the SPDP beacon is ZeroDDS’ best-effort StatelessWriter; its target locators come from the configuration (§8.5.3.1).

§8.4.8.1 Table 8.63 best-effort StatelessWriter T2

Spec: §8.4.8.1, p. 88 — “triggered by the guard condition [RL::unsent_changes() == true] … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action; T4 is what is observable.

§8.4.8.1 Table 8.63 best-effort StatelessWriter T3

Spec: §8.4.8.1, p. 88 — “[RL::unsent_changes() == false] … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action.

§8.4.8.1 Table 8.63 best-effort StatelessWriter T4

Spec: §8.4.8.1, p. 88 — next unsent change; GAP for skipped numbers; “DATA = new DATA(a_change); IF (the_reader_locator.expectsInlineQos) { DATA.inlineQos := … } DATA.readerId := ENTITYID_UNKNOWN; sendto the_reader_locator.locator, DATA;”

Repo: crates/discovery/src/spdp.rs (SpdpBeacon::serialize: one DATA with a consecutive number per announcement)

Tests: crates/discovery/src/spdp.rs::tests::beacon_serializes_to_decodable_datagram

Status: done — the DATA carries readerId = ENTITYID_SPDP_BUILTIN_PARTICIPANT_DETECTOR instead of UNKNOWN (§8.3.8.2 allows either); since every number is sent, no GAP arises.

§8.4.8.1 Table 8.63 best-effort StatelessWriter T5

Spec: §8.4.8.1, pp. 88–89 — “the_rtps_writer.reader_locator_remove( the_reader_locator); delete the_reader_locator;”

Repo: —

Tests: —

Status: n/a (informative) — for SPDP the locators are configured and fixed (§8.5.3.1); a removal by discovery does not occur.

§8.4.8.2 Table 8.64 reliable StatelessWriter T1

Spec: §8.4.8.2, p. 90, Table 8.64 T1 — “a_locator := new ReaderLocator( locator, expectsInlineQos ); the_rtps_writer.reader_locator_add( a_locator );”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::reader_locators_are_added_looked_up_and_removed

Status: done — reader_locator_add(locator, expects_inline_qos). ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T2

Spec: §8.4.8.2, p. 90 — “[RL::unsent_changes() == true] … The transition performs no logical actions”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::unsent_changes_are_pushed_in_order_then_announced

Status: done — unsent changes put the push machine in Pushing. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T3

Spec: §8.4.8.2, p. 90 — “[RL::unsent_changes == false] … The transition performs no logical actions”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::unsent_changes_are_pushed_in_order_then_announced

Status: done — with no unsent changes the push machine goes to Announcing. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T4

Spec: §8.4.8.2, p. 91 — send the next unsent change as DATA with readerId := ENTITYID_UNKNOWN, a GAP for skipped numbers; postcondition higuest_sent_seq_num == a_change_seq_num.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::unsent_changes_are_pushed_in_order_then_announced, crates/rtps/src/reliable_stateless_writer.rs::tests::a_gap_precedes_the_data_after_a_hole_in_the_cache, crates/rtps/src/reliable_stateless_writer.rs::tests::the_related_qos_goes_out_with_the_data_only_where_it_is_expected, crates/rtps/src/reliable_stateless_writer.rs::tests::the_resend_per_tick_is_bounded

Status: done — the next unsent change goes as DATA with readerId = ENTITYID_UNKNOWN to the locator, preceded by a GAP with filteredCount = 0 over the missing numbers; inline QoS of the related DDS writer only with expectsInlineQos; RL::can_send() is the bound max_per_tick. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T5

Spec: §8.4.8.2, p. 91 — periodically “HEARTBEAT := new HEARTBEAT(the_rtps_writer.writerGuid, seq_num_min, seq_num_max); HEARTBEAT.FinalFlag := SET; HEARTBEAT.readerId := ENTITYID_UNKNOWN;”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_announcing_locator_gets_a_final_heartbeat_each_period, crates/rtps/src/reliable_stateless_writer.rs::tests::a_heartbeat_of_an_empty_cache_has_first_after_last, crates/rtps/src/reliable_stateless_writer.rs::tests::the_heartbeat_count_wraps_at_u32_max

Status: done — HEARTBEAT with FinalFlag set and readerId = ENTITYID_UNKNOWN each heartbeatPeriod to an announcing locator; an empty cache announces firstSN = lastSN + 1. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T6

Spec: §8.4.8.2, pp. 91–92 — “FOREACH reply_locator_t IN { Receiver.unicastReplyLocatorList, Receiver.multicastReplyLocatorList } reader_locator := the_rtps_writer.reader_locator_lookup(reply_locator_t); reader_locator.requested_changes_set(ACKNACK.readerSNState.set);”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay, crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_without_a_usable_reply_locator_is_counted

Status: done — an ACKNACK sets requested_changes_set(readerSNState) for each reply locator of the receiver state that names a port and is a ReaderLocator; an ACKNACK without a usable reply locator (no InfoReply) is counted (unmatched_acknacks). ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T7

Spec: §8.4.8.2, p. 92 — “[RL::requested_changes() != ] … The transition performs no logical actions”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay

Status: done — requested changes put the repair machine in MustRepair. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T8

Spec: §8.4.8.2, p. 92 — “The transition performs the same logical actions performed by Transition T6”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay

Status: done — another ACKNACK in MustRepair is handled as in T6. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T9

Spec: §8.4.8.2, p. 92 — “triggered by the firing of a timer indicating that the duration of W::nackResponseDelay has elapsed since the state must_repair was entered.”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay

Status: done — after nackResponseDelay (set_nack_response_delay) the machine goes to Repairing. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T10 (DATA)

Spec: §8.4.8.2, p. 92 — “a_change_seq_num := the_reader_locator.next_requested_change(); … IF ( a_change != ) { DATA = new DATA(a_change); … DATA.readerId := ENTITYID_UNKNOWN; sendto the_reader_locator.locator, DATA; }”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay, crates/rtps/src/reliable_stateless_writer.rs::tests::the_related_qos_goes_out_with_the_data_only_where_it_is_expected

Status: done — next_requested_change goes as DATA with readerId = ENTITYID_UNKNOWN to the locator; inline QoS of the DDS writer and of the change with expectsInlineQos. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T10 (GAP)

Spec: §8.4.8.2, p. 92 — “ELSE { GAP = new GAP(a_change.sequenceNumber); GAP.readerId := ENTITYID_UNKNOWN; GAP.filteredCount := 0; sendto the_reader_locator.locator, GAP; }”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::a_requested_change_that_left_the_cache_is_answered_by_a_gap

Status: done — a requested change that is no longer in the cache is answered with a GAP (filteredCount = 0). ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T11

Spec: §8.4.8.2, p. 93 — “[RL::requested_changes() == ] … The transition performs no logical actions”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay

Status: done — with no requested changes the machine goes to Waiting. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.8.2 Table 8.64 reliable StatelessWriter T12

Spec: §8.4.8.2, p. 93 — “the_rtps_writer.reader_locator_remove( the_reader_locator); delete the_reader_locator;”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::reader_locators_are_added_looked_up_and_removed

Status: done — reader_locator_remove deletes the ReaderLocator. ReliableStatelessWriter is used by no production path; no vendor is measured.

§8.4.9.1 Table 8.65 best-effort StatefulWriter T1

Spec: §8.4.9.1, p. 94, Table 8.65 T1 — “a_reader_proxy := new ReaderProxy( remoteReaderGuid, remoteGroupEntityId, expectsInlineQos, unicastLocatorList, multicastLocatorList); the_rtps_writer.matched_reader_add(a_reader_proxy);”

Repo: crates/rtps/src/reliable_writer.rs (add_reader_proxy with ReaderProxy::new(.., is_reliable: false)); crates/rtps/src/reader_proxy.rs (remote_group_entity_id); crates/dcps/src/runtime.rs (match path)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_best_effort_reader_matched_late_gets_the_next_write, crates/rtps/src/reader_proxy.rs::tests::the_remote_group_entity_id_is_kept, crates/dcps/src/runtime.rs::tests::the_proxies_of_a_match_carry_the_remote_group_entity_id

Status: done — matched_reader_add takes remoteGroupEntityId, expectsInlineQos and both locator lists.

§8.4.9.1 Table 8.65 best-effort StatefulWriter T2

Spec: §8.4.9.1, p. 94 — “[RP::unsent_changes() == true] … Note that for a Best-Effort Writer, W::pushMode == true … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action.

§8.4.9.1 Table 8.65 best-effort StatefulWriter T3

Spec: §8.4.9.1, p. 94 — “[RP::unsent_changes() == false] … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action.

§8.4.9.1 Table 8.65 best-effort StatefulWriter T4

Spec: §8.4.9.1, pp. 94–95 — next unsent change; a GAP with filteredCount 0 for skipped numbers; DATA if DDS_FILTER passes, otherwise a GAP with filteredCount 1; in-line QoS on expectsInlineQos; postcondition higuest_sent_seq_num == a_change_seq_num.

Repo: crates/rtps/src/reliable_writer.rs (write_sample_with_inline_qos, tick, append_change, is_relevant, passes_dds_filter, gap_filtered_count); crates/rtps/src/reader_proxy.rs (ChangeFilter, with_filter)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_best_effort_reader_matched_late_gets_the_next_write, crates/rtps/src/reliable_writer.rs::tests::a_best_effort_reader_matched_late_is_pushed_what_the_cache_holds, crates/rtps/src/reliable_writer.rs::tests::a_best_effort_reader_behind_is_pushed_gaps_with_the_filtered_count, crates/rtps/src/reliable_writer.rs::tests::a_change_that_fails_the_readers_filter_is_a_gap_with_filtered_count_one, crates/rtps/src/reliable_writer.rs::tests::a_gap_for_a_number_the_cache_no_longer_holds_has_filtered_count_zero, crates/rtps/src/reliable_writer.rs::tests::write_fans_out_to_all_reader_proxies

Status: done — a proxy in step gets every new change as DATA; one that is behind gets every change not yet sent as DATA in tick, a number the cache no longer holds as a GAP with filteredCount 0. If a change fails DDS_FILTER(the_reader_proxy, a_change) (ReaderProxy::with_filter), a GAP with filteredCount 1 goes out instead of the DATA. The runtime sets no filter (DDS_FILTER may be a no-op, §8.2.10.1); the behaviour against Cyclone DDS, Fast DDS and OpenDDS is not measured.

§8.4.9.1 Best-effort StatefulWriter: lagging proxy

Spec: §8.4.9.1, p. 95 — T4 sends next_unsent_change() to every proxy, “if ( a_change_seq_num > the_reader_proxy.higuest_sent_seq_num +1 ) { GAP = … }”.

Repo: crates/rtps/src/reliable_writer.rs (tick: next_unsent_change per best-effort proxy, append_change)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_best_effort_reader_matched_late_is_pushed_what_the_cache_holds

Status: done — a lagging best-effort proxy gets the changes not yet sent to it in order, unasked; a number the cache no longer holds as a GAP.

§8.4.9.1 Table 8.65 best-effort StatefulWriter T5

Spec: §8.4.9.1, pp. 95–96 — “ADD a_change TO the_rtps_writer.writer_cache;” postcondition “FOREACH proxy IN the_rtps_writer.matched_readers proxy.unsent_changes() == true”.

Repo: crates/rtps/src/reliable_writer.rs (stage_sample)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_fans_out_to_all_reader_proxies

Status: done

§8.4.9.1 Table 8.65 best-effort StatefulWriter T6

Spec: §8.4.9.1, p. 96 — “the_rtps_writer.matched_reader_remove( the_reader_proxy); delete the_reader_proxy;”

Repo: crates/rtps/src/reliable_writer.rs (remove_reader_proxy)

Tests: crates/rtps/src/reliable_writer.rs::tests::remove_reader_proxy_by_guid

Status: done

§8.4.9.2 Table 8.66 reliable StatefulWriter T1

Spec: §8.4.9.2, p. 98, Table 8.66 T1 — “a_reader_proxy := new ReaderProxy( remoteReaderGuid, remoteGroupEntityId, expectsInlineQos, unicastLocatorList, multicastLocatorList); the_rtps_writer.matched_reader_add(a_reader_proxy);”

Repo: crates/rtps/src/reliable_writer.rs (add_reader_proxy); crates/rtps/src/reader_proxy.rs (remote_group_entity_id); crates/dcps/src/runtime.rs (match path, skip_samples_up_to for VOLATILE)

Tests: crates/rtps/src/reliable_writer.rs::tests::heartbeat_after_add_reader_proxy_is_non_final, crates/rtps/src/reliable_writer.rs::tests::a_reader_matched_inside_an_open_coherent_set_gets_the_whole_set, crates/rtps/src/reader_proxy.rs::tests::the_remote_group_entity_id_is_kept, crates/dcps/src/runtime.rs::tests::the_proxies_of_a_match_carry_the_remote_group_entity_id

Status: done — matched_reader_add takes remoteGroupEntityId, expectsInlineQos and both locator lists.

§8.4.9.2 Table 8.66 reliable StatefulWriter T2

Spec: §8.4.9.2, pp. 98–99 — “[RP::unsent_changes() != ] … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action.

§8.4.9.2 Table 8.66 reliable StatefulWriter T3

Spec: §8.4.9.2, p. 99 — “[RP::unsent_changes() == false] … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action.

§8.4.9.2 Table 8.66 reliable StatefulWriter T4

Spec: §8.4.9.2, pp. 99–100 — the next unsent change as DATA (or a GAP if DDS_FILTER = false, filteredCount 1), a GAP for numbers removed from the cache (filteredCount 0); “DATA.readerId := ENTITYID_UNKNOWN; // or ReaderProxy.entityId”.

Repo: crates/rtps/src/reliable_writer.rs (write_sample_with_inline_qos, write_with_heartbeat_stamped; tick for lagging proxies)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_increments_sn_and_returns_data_datagram, crates/rtps/src/reliable_writer.rs::tests::repairs_in_order_bring_a_lagging_proxy_into_step, crates/rtps/src/reliable_writer.rs::tests::a_reliable_proxy_behind_the_cache_is_pushed_into_step, crates/rtps/src/reliable_writer.rs::tests::a_repair_out_of_order_is_followed_by_the_changes_before_it, crates/rtps/src/reliable_writer.rs::tests::a_reader_asking_for_a_replaced_change_gets_the_current_one

Status: done — write sends a change at once to the proxies in step; to a lagging proxy (a late joiner, or one whose request a GAP answered) tick under pushMode sends the unsent changes in order, DATA for those in the cache, GAP for those removed. A change repaired out of order in the same round does not go out twice.

§8.4.9.2 Table 8.66 reliable StatefulWriter T5

Spec: §8.4.9.2, p. 100 — “[RP::unacked_changes() == false] … The transition performs no logical actions”.

Repo: crates/rtps/src/reliable_writer.rs (tick: no periodic HEARTBEAT without unacknowledged changes)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_reader_that_acknowledged_the_cache_gets_no_periodic_heartbeat

Status: done

§8.4.9.2 Table 8.66 reliable StatefulWriter T6

Spec: §8.4.9.2, p. 100 — “[RP::unacked_changes() == true] … The transition performs no logical actions”.

Repo: crates/rtps/src/reliable_writer.rs (tick: announcing)

Tests: crates/rtps/src/reliable_writer.rs::tests::the_heartbeat_sent_with_a_change_is_answered_by_the_next_acknack

Status: done

§8.4.9.2 Table 8.66 reliable StatefulWriter T7

Spec: §8.4.9.2, p. 100 — “HEARTBEAT := new HEARTBEAT(the_rtps_writer.writerGuid, seq_num_min, seq_num_max); HEARTBEAT.FinalFlag := NOT_SET; HEARTBEAT.readerId := ENTITYID_UNKNOWN; send HEARTBEAT;”

Repo: crates/rtps/src/reliable_writer.rs (tick, append_heartbeat)

Tests: crates/rtps/src/reliable_writer.rs::tests::periodic_heartbeat_has_final_flag_unset, crates/rtps/src/reliable_writer.rs::tests::heartbeat_carries_cache_range

Status: done — the HEARTBEAT goes per proxy with its readerId; firstSN is max(seq_num_min, highest_acked + 1) of the proxy.

§8.4.9.2 Table 8.66 reliable StatefulWriter T8

Spec: §8.4.9.2, p. 100 — “the_rtps_writer.acked_changes_set( ACKNACK.readerSNState.base - 1); the_reader_proxy.requested_changes_set( ACKNACK.readerSNState.set);”

Repo: crates/rtps/src/reliable_writer.rs (handle_acknack_window)

Tests: crates/rtps/src/reliable_writer.rs::tests::handle_acknack_updates_proxy_state, crates/rtps/src/reliable_writer.rs::tests::handle_acknack_with_lower_base_leaves_requested

Status: done

§8.4.9.2 Table 8.66 reliable StatefulWriter T9

Spec: §8.4.9.2, p. 100 — “[RP::requested_changes() != ] … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action.

§8.4.9.2 Table 8.66 reliable StatefulWriter T10

Spec: §8.4.9.2, p. 101 — “The transition performs the same logical actions as Transition T8”.

Repo: crates/rtps/src/reliable_writer.rs (handle_acknack_window)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_full_nack_window_gets_a_heartbeat_with_its_repair

Status: done

§8.4.9.2 Table 8.66 reliable StatefulWriter T11

Spec: §8.4.9.2, p. 101 — “triggered by the firing of a timer indicating that the duration of W::nackResponseDelay has elapsed since the state must_repair was entered.”

Repo: crates/rtps/src/reader_proxy.rs (repair_due, note_nack)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_repair_waits_for_the_nack_response_delay

Status: done

§8.4.9.2 Table 8.66 reliable StatefulWriter T12

Spec: §8.4.9.2, pp. 101–102 — the requested change from the cache as DATA (or a GAP with filteredCount 1 if DDS_FILTER = false), otherwise “GAP = new GAP(a_change.sequenceNumber, the_reader_proxy.remoteReaderGuid); GAP.filteredCount := 0;”; postcondition: the change is no longer requested.

Repo: crates/rtps/src/reliable_writer.rs (tick: append_data, append_lifecycle, append_gap)

Tests: crates/rtps/src/reliable_writer.rs::tests::tick_resends_requested_as_data_aggregated_with_hb, crates/rtps/src/reliable_writer.rs::tests::tick_resends_evicted_request_as_gap, crates/rtps/src/reliable_writer.rs::tests::lifecycle_repair_reproduces_the_key

Status: done — the GAP carries no filteredCount field; that equals a change not counted.

§8.4.9.2 Table 8.66 reliable StatefulWriter T13

Spec: §8.4.9.2, p. 102 — “[RP::requested_changes() == ] … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action.

§8.4.9.2 Table 8.66 reliable StatefulWriter T14

Spec: §8.4.9.2, p. 102 — “ADD a_change TO the_rtps_writer.writer_cache;” postcondition: every proxy has unsent changes.

Repo: crates/rtps/src/reliable_writer.rs (stage_sample)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_fans_out_to_all_reader_proxies

Status: done

§8.4.9.2 Table 8.66 reliable StatefulWriter T15

Spec: §8.4.9.2, p. 102 — “triggered by the removal of a CacheChange ‘a_change’ from the HistoryCache of the RTPS Writer”.

Repo: crates/rtps/src/reliable_writer.rs (KEEP_LAST eviction in stage_sample, remove_acknowledged, remove_samples_up_to)

Tests: crates/rtps/src/reliable_writer.rs::tests::keep_last_stalled_reader_does_not_block_fresh_writes, crates/rtps/src/reliable_writer.rs::tests::tick_resends_evicted_request_as_gap

Status: done

§8.4.9.2 Table 8.66 reliable StatefulWriter T16

Spec: §8.4.9.2, p. 102 — “the_rtps_writer.matched_reader_remove( the_reader_proxy); delete the_reader_proxy;”

Repo: crates/rtps/src/reliable_writer.rs (remove_reader_proxy)

Tests: crates/rtps/src/reliable_writer.rs::tests::remove_reader_proxy_by_guid, crates/rtps/src/reliable_writer.rs::tests::the_unacked_window_fills_and_acknowledgements_free_it

Status: done

§8.4.10.1 Table 8.67 Reader heartbeatResponseDelay

Spec: §8.4.10.1, p. 103, Table 8.67 — “heartbeatResponseDelay: Protocol tuning parameter that allows the RTPS Reader to delay the sending of a positive or negative acknowledgment”.

Repo: crates/rtps/src/reliable_reader.rs (ReliableReaderConfig::heartbeat_response_delay, tick_outbound)

Tests: crates/rtps/src/reliable_reader.rs::tests::heartbeat_with_missing_triggers_acknack_after_delay

Status: done — its tunability for the user is listed under §8.4.2.1.

§8.4.10.1 Table 8.67 Reader heartbeatSuppressionDuration

Spec: §8.4.10.1, p. 103, Table 8.67 — “heartbeatSuppressionDuration: Protocol tuning parameter that allows the RTPS Reader to ignore HEARTBEATs that arrive ‘too soon’ after a previous HEARTBEAT was received.”

Repo: crates/rtps/src/reliable_reader.rs (set_heartbeat_suppression_duration, handle_heartbeat)

Tests: crates/rtps/src/reliable_reader.rs::tests::heartbeat_suppression_duration_ignores_a_heartbeat_that_arrives_too_soon

Status: done

§8.4.10.1 Table 8.67 Reader reader_cache

Spec: §8.4.10.1, p. 103, Table 8.67 — “reader_cache: History Cache — Contains the history of CacheChange changes for this RTPS Reader.”

Repo: crates/rtps/src/reliable_reader.rs (WriterProxyState::received_cache); crates/dcps/src/subscriber.rs (the DataReader’s sample store)

Tests: crates/rtps/src/reliable_reader.rs::tests::out_of_order_data_buffered_until_gap_filled, crates/rtps/src/reliable_reader.rs::tests::a_full_cache_takes_the_change_in_front_of_what_it_holds

Status: done

§8.4.10.1 Table 8.67 Reader expectsInlineQos

Spec: §8.4.10.1, p. 104, Table 8.67 — “expectsInlineQos: bool — Specifies whether the RTPS Reader expects in-line QoS to be sent along with any data.”

Repo: crates/rtps/src/subscription_data.rs (SubscriptionBuiltinTopicData::expects_inline_qos)

Tests: crates/rtps/src/subscription_data.rs::tests::expects_inline_qos_goes_out_when_set_and_reads_back

Status: done

§8.4.10.1 Default heartbeatResponseDelay = 500 ms

Spec: §8.4.10.1, p. 104 — “heartbeatResponseDelay.sec = 0; heartbeatResponseDelay.nanosec = 500 * 1000 * 1000; // 500 milliseconds”.

Repo: crates/rtps/src/reliable_reader.rs (DEFAULT_HEARTBEAT_RESPONSE_DELAY, SPEC_HEARTBEAT_RESPONSE_DELAY); crates/dcps/src/runtime.rs (RuntimeConfig::reader_heartbeat_response_delay)

Tests: crates/rtps/src/reliable_reader.rs::tests::default_heartbeat_suppression_duration_is_the_spec_zero, crates/dcps/tests/runtime_config_layering.rs::the_protocol_timing_parameters_are_settings

Status: done — DEFAULT_HEARTBEAT_RESPONSE_DELAY and RuntimeConfig::reader_heartbeat_response_delay are 500 ms; reader.heartbeat_response_delay_ms: 0 answers on the next tick.

§8.4.10.1 Default heartbeatResponseDelay

Spec: §8.4.10.1, p. 104 — “The following timing-related values are used as the defaults in order to facilitate ‘out-of-the-box’ interoperability between implementations.”

Repo: crates/rtps/src/reliable_reader.rs (DEFAULT_HEARTBEAT_RESPONSE_DELAY, DEFAULT_HEARTBEAT_SUPPRESSION_DURATION); crates/dcps/src/runtime.rs; crates/dcps/src/type_lookup_transport.rs; man/man5/zerodds.yaml.5; packaging/linux/configs/zerodds.yaml.example

Tests: crates/dcps/tests/runtime_config_layering.rs::the_protocol_timing_parameters_are_settings, crates/rtps/src/reliable_reader.rs::tests::default_heartbeat_suppression_duration_is_the_spec_zero

Status: done — the values of the spec are the defaults: heartbeatResponseDelay 500 ms, heartbeatSuppressionDuration 0 (runtime, man page, example configuration). The former 0 ms stay reachable through reader.heartbeat_response_delay_ms. §8.4.7.1 names no heartbeatPeriod; it stays 100 ms (writer.heartbeat_period_ms). The built-in readers of SEDP, secure volatile and TypeLookup use the same default.

§8.4.10.1 Default heartbeatSuppressionDuration = 0

Spec: §8.4.10.1, p. 104 — “heartbeatSuppressionDuration.sec = 0; heartbeatSuppressionDuration.nanosec = 0;”.

Repo: crates/rtps/src/reliable_reader.rs (DEFAULT_HEARTBEAT_SUPPRESSION_DURATION)

Tests: crates/rtps/src/reliable_reader.rs::tests::default_heartbeat_suppression_duration_is_the_spec_zero, crates/rtps/src/reliable_reader.rs::tests::heartbeat_storm_from_a_writer_that_never_fulfils_a_nack_cannot_arise, crates/discovery/src/sedp/reader.rs::tests::sedp_reader_does_not_storm_against_a_writer_that_never_delivers

Status: done — every reader runs with 0, the built-in ones of SEDP and VolatileSecure too. A writer that re-announces the same range at short intervals (HDDS 1.4.8: a HEARTBEAT [1,1] about every 1.5 ms) gets one response per heartbeatResponseDelay: the delay runs from the first HEARTBEAT that asks for a response.

§8.4.10.1 Table 8.68 Reader new

Spec: §8.4.10.1, p. 104 — takes over guid, locator lists, reliabilityLevel, topicKind, expectsInlineQos, heartbeatResponseDelay; “this.reader_cache := new HistoryCache;”

Repo: crates/rtps/src/reliable_reader.rs (ReliableReader::new)

Tests: crates/rtps/src/reliable_reader.rs::tests::add_writer_proxy_increases_count

Status: done

§8.4.10.2 Table 8.69 StatelessReader new

Spec: §8.4.10.2, pp. 104–105 — “The RTPS StatelessReader has no knowledge of the number of matched writers, nor does it maintain any state for each matched RTPS Writer.”

Repo: crates/rtps/src/reader.rs (BestEffortReader::new); crates/discovery/src/spdp.rs (SpdpReader::new)

Tests: crates/rtps/src/reader.rs::tests::reader_delivers_data_addressed_to_us, crates/discovery/src/spdp.rs::tests::reader_rejects_non_spdp_datagram

Status: done

§8.4.10.3 Table 8.70 StatefulReader matched_writers

Spec: §8.4.10.3, p. 105, Table 8.70 — “matched_writers: WriteProxy[*] — Used to maintain state on the remote Writers matched up with the Reader.”

Repo: crates/rtps/src/reliable_reader.rs (writer_proxies)

Tests: crates/rtps/src/reliable_reader.rs::tests::two_writers_with_overlapping_sn_spaces_both_delivered

Status: done

§8.4.10.3 Table 8.71 StatefulReader new

Spec: §8.4.10.3, pp. 105–106 — “this.matched_writers := ;”

Repo: crates/rtps/src/reliable_reader.rs (ReliableReader::new)

Tests: crates/rtps/src/reliable_reader.rs::tests::no_pre_emptive_acknack_without_proxy

Status: done

§8.4.10.3 Table 8.71 StatefulReader matched_writer_add

Spec: §8.4.10.3, p. 106 — “ADD a_writer_proxy TO {this.matched_writers};”

Repo: crates/rtps/src/reliable_reader.rs (add_writer_proxy)

Tests: crates/rtps/src/reliable_reader.rs::tests::add_writer_proxy_increases_count, crates/rtps/src/reliable_reader.rs::tests::re_adding_known_writer_preserves_reliability_state

Status: done

§8.4.10.3 Table 8.71 StatefulReader matched_writer_remove

Spec: §8.4.10.3, p. 106 — “REMOVE a_writer_proxy FROM {this.matched_writers}; delete a_writer_proxy;”

Repo: crates/rtps/src/reliable_reader.rs (remove_writer_proxy, depart_writer_proxy)

Tests: crates/rtps/src/reliable_reader.rs::tests::remove_writer_proxy_drops_its_state, crates/rtps/src/reliable_reader.rs::tests::a_departed_writer_leaves_its_held_samples_with_the_reader

Status: done

§8.4.10.3 Table 8.71 StatefulReader matched_writer_lookup

Spec: §8.4.10.3, p. 106 — “FIND proxy IN this.matched_writers SUCH-THAT (proxy.remoteWriterGuid == a_writer_guid); return proxy;”

Repo: crates/rtps/src/reliable_reader.rs (proxy_index_by_writer)

Tests: crates/rtps/src/reliable_reader.rs::tests::same_entity_id_different_prefix_not_confused

Status: done

§8.4.10.4 The WriterProxy follows the DDS match

Spec: §8.4.10.4, p. 106 — “The association is a consequence of the matching of the corresponding DDS Entities … the DDS DataReader matching a DDS DataWriter by Topic, having compatible QoS, belonging to a common partition, and not being explicitly ignored by the application that uses DDS.”

Repo: crates/dcps/src/runtime.rs (match path, add_writer_proxy); crates/dcps/src/participant.rs (ignore_publication)

Tests: crates/dcps/src/runtime.rs::tests::partition_mismatch_blocks_match_without_any_incompatible_qos_event, crates/dcps/src/participant.rs::tests::ignore_publication_records_handle

Status: done

§8.4.10.4 Table 8.72 WriterProxy remoteWriterGuid

Spec: §8.4.10.4, p. 106, Table 8.72 — “remoteWriterGuid: GUID_t — Identifies the matched Writer.”

Repo: crates/rtps/src/writer_proxy.rs (WriterProxy::remote_writer_guid)

Tests: crates/rtps/src/reliable_reader.rs::tests::same_entity_id_different_prefix_not_confused

Status: done

§8.4.10.4 Table 8.72 WriterProxy unicastLocatorList

Spec: §8.4.10.4, p. 106, Table 8.72 — “List of unicast (address, port) combinations that can be used to send messages to the matched Writer or Writers. The list may be empty.”

Repo: crates/rtps/src/writer_proxy.rs (WriterProxy::unicast_locators); crates/rtps/src/reliable_reader.rs (tick_outbound: ACKNACK to these locators)

Tests: crates/rtps/src/reliable_reader.rs::tests::tick_emits_one_acknack_per_writer_with_missing

Status: done

§8.4.10.4 Table 8.72 WriterProxy multicastLocatorList

Spec: §8.4.10.4, p. 106, Table 8.72 — “List of multicast (address, port) combinations that can be used to send messages to the matched Writer or Writers. The list may be empty.”

Repo: crates/rtps/src/writer_proxy.rs (WriterProxy::multicast_locators, refresh_locators)

Tests: crates/rtps/src/reliable_reader.rs::tests::re_adding_known_writer_preserves_reliability_state

Status: done — the list is kept; ACKNACKs go to the unicast locators.

§8.4.10.4 Table 8.72 WriterProxy dataMaxSizeSerialized

Spec: §8.4.10.4, p. 106, Table 8.72 — “Optional attribute that indicates the maximum size of any SerializedPayload that may be sent by the matched Writer.”

Repo: crates/rtps/src/reliable_reader.rs (set_writer_data_max_size, oversize_payload_count); crates/dcps/src/runtime.rs (wiring when the writer proxy is created, reader.honor_data_max_size_serialized)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_payload_beyond_the_announced_maximum_is_refused_and_counted, crates/dcps/tests/runtime_config_layering.rs::the_data_max_size_setting_is_on_by_default_and_read_from_yaml

Status: done — the reader takes the attribute from the announcement and refuses a SerializedPayload beyond it (after a protected payload is opened; the number counts as not available and the counter oversize_payload_count rises). A DATA_FRAG sample is checked once reassembled; AssemblerCaps still bounds the size of reassembled samples. The named setting reader.honor_data_max_size_serialized=false takes the payload anyway, for a writer that exceeds its own announcement (Fast DDS 3.6.1: 160 octets announced, 100 036 sent).

§8.4.10.4 Table 8.72 WriterProxy changes_from_writer

Spec: §8.4.10.4, p. 106, Table 8.72 — “List of CacheChange changes received or expected from the matched RTPS Writer.”

Repo: crates/rtps/src/writer_proxy.rs (known_up_to, received, irrelevant, first_available_sn, last_available_sn)

Tests: crates/rtps/src/writer_proxy.rs::tests::the_known_run_answers_as_the_sets_of_every_sn_did

Status: done — modelled as counters and sets (§8.4.15.1).

§8.4.10.4 Table 8.72 WriterProxy remoteGroupEntityId

Spec: §8.4.10.4, p. 107, Table 8.72 — “remoteGroupEntityId: EntityId_t — Identifies the group to which the matched Reader belongs”.

Repo: crates/rtps/src/writer_proxy.rs (WriterProxy::remote_group_entity_id, with_remote_group_entity_id); crates/dcps/src/runtime.rs (match path, PID_GROUP_GUID of the publication)

Tests: crates/rtps/src/writer_proxy.rs::tests::the_remote_group_entity_id_is_kept, crates/dcps/src/runtime.rs::tests::the_proxies_of_a_match_carry_the_remote_group_entity_id

Status: done — the proxy holds remoteGroupEntityId; the match path fills it from PID_GROUP_GUID of the writer’s SEDP announcement, ENTITYID_UNKNOWN without a group.

§8.4.10.4 Table 8.73 WriterProxy new

Spec: §8.4.10.4, p. 107 — “this.changes_from_writer := ; … initialized to UNKNOWN”.

Repo: crates/rtps/src/writer_proxy.rs (WriterProxy::new: first_available_sn = 1, last_available_sn = 0)

Tests: crates/rtps/src/writer_proxy.rs::tests::fresh_proxy_has_no_missing

Status: done

§8.4.10.4 Table 8.73 WriterProxy available_changes_max

Spec: §8.4.10.4, p. 108 — “seq_num := MAX { change.sequenceNumber SUCH-THAT ( change IN this.changes_from_writer AND ( change.status == RECEIVED OR change.status == NOT_AVAILABLE) ) }” provided that no smaller number is MISSING or UNKNOWN.

Repo: crates/rtps/src/writer_proxy.rs (available_changes_max)

Tests: crates/rtps/src/writer_proxy.rs::tests::available_changes_max_stops_at_the_first_hole, crates/rtps/src/writer_proxy.rs::tests::available_changes_max_passes_over_an_irrelevant_change

Status: done

§8.4.10.4 Table 8.73 WriterProxy not_available_change_set

Spec: §8.4.10.4, p. 108 — “IF ( filteredCount == COUNT(this. a_seq_num_set) ) THEN change.status := NA_FILTERED; ELSE IF ( filteredCount == 0) change.status := NA_REMOVED; ELSE change.status := NA_UNSPECIFIED;”

Repo: crates/rtps/src/writer_proxy.rs (NotAvailableKind, WriterProxy::not_available_change_set, not_available_count, change_status); crates/rtps/src/reliable_reader.rs (handle_gap, not_available_count)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_gap_sorts_its_changes_by_the_filtered_count, crates/rtps/src/reliable_reader.rs::tests::the_reader_keeps_the_status_of_each_change, crates/rtps/src/writer_proxy.rs::tests::change_status_is_kept_per_change_with_the_sub_kind

Status: done — filteredCount equal to the size of the set gives NA_FILTERED, 0 gives NA_REMOVED, anything between gives NA_UNSPECIFIED; the status is kept per change. A GAP without the FilteredCountFlag counts as 0 (assumption: the field is missing from peers before 2.5, whose GAP reports removed changes only; not measured against a vendor). A number already known is not counted or changed again.

§8.4.10.4 Table 8.73 WriterProxy lost_changes_update

Spec: §8.4.10.4, p. 108 — “FOREACH change IN this.changes_from_writer SUCH-THAT ( change.status == UNKNOWN OR change.status == MISSING AND seq_num < first_available_seq_num ) DO { change.status := NA_REMOVED; }”.

Repo: crates/rtps/src/writer_proxy.rs (lost_changes_update)

Tests: crates/rtps/src/writer_proxy.rs::tests::lost_changes_update_counts_what_was_neither_received_nor_irrelevant, crates/rtps/src/writer_proxy.rs::tests::lost_changes_update_retires_everything_below_the_new_base

Status: done

§8.4.10.4 Table 8.73 WriterProxy missing_changes

Spec: §8.4.10.4, p. 109 — “return { change IN this.changes_from_writer SUCH-THAT change.status == MISSING};”

Repo: crates/rtps/src/writer_proxy.rs (missing_changes)

Tests: crates/rtps/src/writer_proxy.rs::tests::missing_changes_respects_max_count, crates/rtps/src/writer_proxy.rs::tests::received_removes_from_missing

Status: done

§8.4.10.4 Table 8.73 WriterProxy missing_changes_update

Spec: §8.4.10.4, p. 109 — “FOREACH change IN this.changes_from_writer SUCH-THAT ( change.status == UNKNOWN AND seq_num <= last_available_seq_num ) DO { change.status := MISSING; }”.

Repo: crates/rtps/src/writer_proxy.rs (update_from_heartbeat: last_available_sn)

Tests: crates/rtps/src/writer_proxy.rs::tests::heartbeat_sets_available_range

Status: done

§8.4.10.4 Table 8.73 WriterProxy received_change_set

Spec: §8.4.10.4, p. 109 — “FIND change FROM this.changes_from_writer SUCH-THAT change.sequenceNumber == a_seq_num; change.status := RECEIVED”.

Repo: crates/rtps/src/writer_proxy.rs (received_change_set)

Tests: crates/rtps/src/writer_proxy.rs::tests::received_removes_from_missing, crates/rtps/src/writer_proxy.rs::tests::received_before_first_is_ignored

Status: done

§8.4.10.5 Table 8.74 ChangeFromWriter status

Spec: §8.4.10.5, pp. 109–110, Table 8.74 — “status: ChangeFromWriter StatusKind — Indicates the status of a CacheChange relative to the RTPS Writer represented by the WriterProxy.” Values UNKNOWN, MISSING, RECEIVED, NOT_AVAILABLE with the sub-kinds NA_FILTERED, NA_REMOVED, NA_UNSPECIFIED.

Repo: crates/rtps/src/writer_proxy.rs (ChangeFromWriterStatus, change_status, is_known, missing_changes, not_available_count)

Tests: crates/rtps/src/writer_proxy.rs::tests::change_status_is_kept_per_change_with_the_sub_kind, crates/rtps/src/writer_proxy.rs::tests::lost_changes_update_sets_na_removed_per_change, crates/rtps/src/reliable_reader.rs::tests::the_reader_keeps_the_status_of_each_change, crates/rtps/src/reliable_reader.rs::tests::a_gap_sorts_its_changes_by_the_filtered_count

Status: done — the four main values and the three sub-kinds of NOT_AVAILABLE are kept per change (item under §8.4.6 Table 8.52 ChangeFromWriterStatusKind).

§8.4.10.5 Table 8.74 ChangeFromWriter is_relevant

Spec: §8.4.10.5, p. 109, Table 8.74 — “is_relevant: bool — Indicates whether the change is relevant to the RTPS Reader. The determination of relevant changes is affected by DDS DataReader TIME_BASED_FILTER QoS and also by the use of DDS ContentFilteredTopics.”

Repo: crates/rtps/src/history_cache.rs (ChangeKind::is_relevant, ChangeKind::AliveFiltered); crates/dcps/src/runtime.rs (tbf_should_deliver)

Tests: crates/rtps/src/history_cache.rs::tests::change_kind_alive_filtered_is_alive_but_not_relevant

Status: done

§8.4.11.1 Table 8.75 best-effort StatelessReader T1

Spec: §8.4.11.1, pp. 110–111, Table 8.75 T1 — “triggered by the creation of an RTPS StatelessReader … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action.

§8.4.11.1 Table 8.75 best-effort StatelessReader T2

Spec: §8.4.11.1, p. 111 — “a_change := new CacheChange(DATA); the_rtps_reader.reader_cache.add_change(a_change);”

Repo: crates/discovery/src/spdp.rs (SpdpReader::samples); crates/rtps/src/reader.rs (BestEffortReader::recv_datagram)

Tests: crates/discovery/src/spdp.rs::tests::samples_reads_every_participant_a_datagram_bundles, crates/rtps/src/reader.rs::tests::reader_handles_multiple_data_in_one_datagram

Status: done

§8.4.11.1 Table 8.75 best-effort StatelessReader T3

Spec: §8.4.11.1, p. 111 — “triggered by the destruction of an RTPS Reader … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action.

§8.4.11.2 Reliable StatelessReader not supported

Spec: §8.4.11.2, p. 111 — “This combination is not supported by the RTPS protocol.”

Repo: —

Tests: —

Status: n/a (informative) — no requirement; ZeroDDS has no reliable StatelessReader.

§8.4.12.1 Table 8.76 best-effort StatefulReader T1

Spec: §8.4.12.1, p. 112, Table 8.76 T1 — “a_writer_proxy := new WriterProxy(remoteWriterGuid, remoteGroupEntityId, unicastLocatorList, multicastLocatorList); the_rtps_reader.matched_writer_add(a_writer_proxy);”

Repo: crates/rtps/src/reliable_reader.rs (add_writer_proxy, set_best_effort); crates/rtps/src/writer_proxy.rs (remote_group_entity_id)

Tests: crates/rtps/src/reliable_reader.rs::tests::best_effort_reader_skips_leading_gap, crates/rtps/src/writer_proxy.rs::tests::the_remote_group_entity_id_is_kept, crates/dcps/src/runtime.rs::tests::the_proxies_of_a_match_carry_the_remote_group_entity_id

Status: done — matched_writer_add takes remoteGroupEntityId and both locator lists.

§8.4.12.1 Table 8.76 best-effort StatefulReader T2

Spec: §8.4.12.1, p. 113 — “expected_seq_num := writer_proxy.available_changes_max() + 1; if ( a_change.sequenceNumber >= expected_seq_num ) { … add_change(a_change); received_change_set(…); if ( a_change.sequenceNumber > expected_seq_num ) { lost_changes_update(…) } }”.

Repo: crates/rtps/src/reliable_reader.rs (handle_data_into: gap_skipped, lost_changes_update with best_effort)

Tests: crates/rtps/src/reliable_reader.rs::tests::best_effort_reader_skips_leading_gap, crates/rtps/src/reliable_reader.rs::tests::duplicate_data_is_rejected, crates/rtps/src/reliable_reader.rs::tests::a_best_effort_reader_counts_the_samples_a_gap_lost

Status: done

§8.4.12.1 Table 8.76 best-effort StatefulReader T3

Spec: §8.4.12.1, p. 113 — “the_rtps_reader.matched_writer_remove( the_writer_proxy); delete the_writer_proxy;”

Repo: crates/rtps/src/reliable_reader.rs (remove_writer_proxy)

Tests: crates/rtps/src/reliable_reader.rs::tests::remove_writer_proxy_drops_its_state

Status: done

§8.4.12.1 Table 8.76 best-effort StatefulReader T4

Spec: §8.4.12.1, p. 113 — “the_writer_proxy.not_available_change_set(GAP. sequence_number_set, GAP.filteredCount);”

Repo: crates/rtps/src/reliable_reader.rs (handle_gap)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_best_effort_reader_counts_the_samples_a_gap_lost, crates/rtps/src/reliable_reader.rs::tests::a_gap_sorts_its_changes_by_the_filtered_count, crates/rtps/src/reliable_reader.rs::tests::the_reader_keeps_the_status_of_each_change

Status: done — the numbers of the GAP are marked not available with the sub-kind given by filteredCount and are kept per change.

§8.4.12.2 Table 8.77 reliable StatefulReader T1

Spec: §8.4.12.2, pp. 114–115, Table 8.77 T1 — “a_writer_proxy := new WriterProxy(remoteWriterGuid, remoteGroupEntityId, unicastLocatorList, multicastLocatorList); the_rtps_reader.matched_writer_add(a_writer_proxy);”

Repo: crates/rtps/src/reliable_reader.rs (add_writer_proxy); crates/rtps/src/writer_proxy.rs (remote_group_entity_id)

Tests: crates/rtps/src/reliable_reader.rs::tests::add_writer_proxy_increases_count, crates/rtps/src/reliable_reader.rs::tests::changes_a_writer_sent_before_the_match_are_requested_at_once, crates/rtps/src/writer_proxy.rs::tests::the_remote_group_entity_id_is_kept, crates/dcps/src/runtime.rs::tests::the_proxies_of_a_match_carry_the_remote_group_entity_id

Status: done — matched_writer_add takes remoteGroupEntityId and both locator lists.

§8.4.12.2 Table 8.77 reliable StatefulReader T2

Spec: §8.4.12.2, p. 114 — HEARTBEAT received: “if (HB.FinalFlag == NOT_SET) then must_send_ack else if (HB.LivelinessFlag == NOT_SET) then may_send_ack else waiting”.

Repo: —

Tests: crates/rtps/src/reliable_reader.rs::tests::a_heartbeat_with_the_liveliness_flag_is_taken_as_a_heartbeat

Status: done

§8.4.12.2 Table 8.77 reliable StatefulReader T3

Spec: §8.4.12.2, p. 115 — “[W::missing_changes() == ] … The transition performs no logical actions.”

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat: no ACKNACK on F = 1 with nothing missing)

Tests: crates/rtps/src/reliable_reader.rs::tests::heartbeat_without_missing_and_final_schedules_no_acknack

Status: done

§8.4.12.2 Table 8.77 reliable StatefulReader T4

Spec: §8.4.12.2, p. 115 — “[W::missing_changes() != ] … The transition performs no logical actions.”

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat: has_missing sets pending_acknack_since)

Tests: crates/rtps/src/reliable_reader.rs::tests::final_heartbeat_from_unknown_to_data_writer_requests_the_missing_sn

Status: done

§8.4.12.2 Table 8.77 reliable StatefulReader T5

Spec: §8.4.12.2, pp. 115–116 — after heartbeatResponseDelay “missing_seq_num_set.base := the_writer_proxy.available_changes_max() + 1; … send ACKNACK(missing_seq_num_set);” — with too many missing numbers “the subset with smallest value of the sequence number”.

Repo: crates/rtps/src/reliable_reader.rs (tick_outbound, build_acknack_datagram); crates/rtps/src/submessages.rs (SequenceNumberSet::from_missing)

Tests: crates/rtps/src/reliable_reader.rs::tests::heartbeat_with_missing_triggers_acknack_after_delay, crates/rtps/src/submessages.rs::tests::snset_from_missing_spread_wide_stays_within_256_bits, crates/rtps/src/reliable_reader.rs::tests::a_partly_received_sample_is_asked_for_by_nack_frag_not_acknack

Status: done — base and smallest subset are right; the set holds only numbers of which no fragment has arrived (NACK_FRAG asks for the others, §8.4.14.1).

§8.4.12.2 Table 8.77 reliable StatefulReader T6

Spec: §8.4.12.2, p. 116 — “Similar to T1 … The transition performs no logical actions in the virtual machine.”

Repo: —

Tests: —

Status: n/a (informative) — transition without a logical action.

§8.4.12.2 Table 8.77 reliable StatefulReader T7

Spec: §8.4.12.2, p. 116 — “the_writer_proxy.missing_changes_update( HEARTBEAT.lastSN); the_writer_proxy.lost_changes_update(HEARTBEAT.firstSN, true);”

Repo: crates/rtps/src/writer_proxy.rs (update_from_heartbeat)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_heartbeat_with_the_liveliness_flag_is_taken_as_a_heartbeat

Status: done

§8.4.12.2 Table 8.77 reliable StatefulReader T8

Spec: §8.4.12.2, p. 116 — “a_change := new CacheChange(DATA); the_reader.reader_cache.add_change(a_change); the_writer_proxy.received_change_set(a_change.sequenceNumber);”

Repo: crates/rtps/src/reliable_reader.rs (handle_data_into, store_received)

Tests: crates/rtps/src/reliable_reader.rs::tests::in_order_data_delivered_immediately, crates/rtps/src/reliable_reader.rs::tests::out_of_order_data_buffered_until_gap_filled

Status: done

§8.4.12.2 Table 8.77 reliable StatefulReader T9

Spec: §8.4.12.2, p. 116 — “the_writer_proxy.not_available_change_set(GAP. sequence_number_set, GAP.filteredCount);”

Repo: crates/rtps/src/reliable_reader.rs (handle_gap)

Tests: crates/rtps/src/reliable_reader.rs::tests::gap_after_the_held_data_releases_it, crates/rtps/src/reliable_reader.rs::tests::a_gap_sorts_its_changes_by_the_filtered_count, crates/rtps/src/reliable_reader.rs::tests::the_reader_keeps_the_status_of_each_change

Status: done — filteredCount is evaluated (item under §8.4.10.4 Table 8.73 WriterProxy not_available_change_set); the numbers are held per change as NOT_AVAILABLE.

§8.4.12.2 Table 8.77 reliable StatefulReader T10

Spec: §8.4.12.2, p. 116 — “the_rtps_reader.matched_writer_remove( the_writer_proxy); delete the_writer_proxy;”

Repo: crates/rtps/src/reliable_reader.rs (remove_writer_proxy, depart_writer_proxy)

Tests: crates/rtps/src/reliable_reader.rs::tests::remove_writer_proxy_drops_its_state, crates/rtps/src/reliable_reader.rs::tests::a_departed_writer_counts_what_is_missing_in_front_of_its_held_samples

Status: done

§8.4.12.3 ChangeFromWriter illustrated

Spec: §8.4.12.3, pp. 117–118, Figure 8.25 — states Unknown, Missing, NotRequested, Requested, Received, NotAvailable (Filtered, Removed, Unspecified) and the events that trigger them.

Repo: —

Tests: —

Status: n/a (informative) — illustrates the transitions of §8.4.10.4 and §8.4.12.2 (“It is illustrative”); no requirement of its own.

§8.4.13 Writer Liveliness Protocol: support is mandatory

Spec: §8.4.13, p. 118 — “All implementations must support the Writer Liveliness Protocol in order to be interoperable.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint); crates/dcps/src/runtime.rs (DcpsRuntime::wlp)

Tests: crates/dcps/tests/wlp_integration.rs::linux_only::two_participants_exchange_automatic_wlp_heartbeats, crates/dcps/src/runtime.rs::tests::two_runtimes_exchange_wlp_heartbeat, crates/dcps/src/wlp.rs::tests::a_late_reader_is_told_by_heartbeat_and_gets_the_held_samples_on_request, crates/dcps/src/wlp.rs::tests::the_reader_is_treated_as_builtin_endpoint_qos_says

Status: done — writer and reader of the protocol run in every participant; the writer has the QoS of §8.4.13.3 and treats the reader as builtinEndpointQos says. The writer’s wire change is not measured against Cyclone, Fast DDS, OpenDDS and RTI.

§8.4.13.1 Association with the built-in endpoints of a discovered participant

Spec: §8.4.13.1, p. 118 — “once a Participant knows of the presence of another Participant, it can assume the presence of the built-in Endpoints made available by the remote Participant and establish the association with the locally matching built-in Endpoints.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::add_peer_reader); crates/dcps/src/runtime.rs (spdp_announced, wlp_unicast_targets, answer_wlp_heartbeats)

Tests: crates/dcps/src/runtime.rs::tests::wlp_unicast_targets_prefers_metatraffic_then_default, crates/dcps/src/runtime.rs::tests::two_runtimes_assert_liveliness_reaches_peer, crates/dcps/src/wlp.rs::tests::only_a_participant_with_a_message_reader_gets_a_proxy

Status: done — every SPDP announcement makes (unchanged: keeps) a reader proxy for the participant’s BuiltinParticipantMessageReader when its availableBuiltinEndpoints name it; the target is its metatraffic locators.

§8.4.13.1 The same protocol as for application-defined endpoints

Spec: §8.4.13.1, p. 118 — “The protocol used to communicate between built-in Endpoints is the same as used for application-defined Endpoints.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint: make_writer, write_pulse, add_peer_reader, handle_reader_messages, tick); crates/dcps/src/runtime.rs (WLP-Tick, spdp_announced)

Tests: crates/dcps/src/wlp.rs::tests::a_late_reader_is_told_by_heartbeat_and_gets_the_held_samples_on_request, crates/dcps/src/wlp.rs::tests::the_writer_heartbeats_until_the_reader_has_acknowledged

Status: done — the WLP writer is a ReliableWriter with a reader proxy per participant: DATA with a piggyback HEARTBEAT, periodic HEARTBEATs until acknowledged, repair of what was asked for only, GAP for superseded numbers. The reader answers HEARTBEATs (heartbeat_responses) and keeps the highest sequence number received per writer.

§8.4.13.2 Built-in endpoints BuiltinParticipantMessageWriter and -Reader

Spec: §8.4.13.2, p. 118 — “The RTPS Protocol reserves the following values of the EntityId_t for these built-in Endpoints: ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER”

Repo: crates/rtps/src/wire_types.rs (EntityId::BUILTIN_PARTICIPANT_MESSAGE_WRITER, EntityId::BUILTIN_PARTICIPANT_MESSAGE_READER); crates/dcps/src/wlp.rs (WlpEndpoint::handle_datagram)

Tests: crates/dcps/src/wlp.rs::tests::wlp_handle_datagram_updates_peer_state, crates/dcps/src/wlp.rs::tests::wlp_handle_datagram_ignores_non_wlp_traffic

Status: done — the values are listed under §9.3.1.3.

§8.4.13.3 Writer durability.kind = TRANSIENT_LOCAL

Spec: §8.4.13.3, p. 118 — “both the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader shall use the following QoS values: durability.kind = TRANSIENT_LOCAL_DURABILITY”.

Repo: crates/dcps/src/wlp.rs (WlpEndpoint: make_writer, write_pulse, add_peer_reader, handle_reader_messages, tick); crates/dcps/src/runtime.rs (WLP-Tick, spdp_announced)

Tests: crates/dcps/src/wlp.rs::tests::a_late_reader_is_told_by_heartbeat_and_gets_the_held_samples_on_request

Status: done — a reader that comes later gets the held samples with the first tick, without asking (the history keeps one sample per kind, so a request would meet a newer sample), and a HEARTBEAT says what the history holds; asking again it gets them once more.

§8.4.13.3 Writer history KEEP_LAST, depth 1

Spec: §8.4.13.3, pp. 118–119 — “history.kind = KEEP_LAST_HISTORY_QOS”, “history.depth = 1”.

Repo: crates/dcps/src/wlp.rs (WlpEndpoint: make_writer, write_pulse, add_peer_reader, handle_reader_messages, tick); crates/dcps/src/runtime.rs (WLP-Tick, spdp_announced)

Tests: crates/dcps/src/wlp.rs::tests::the_history_holds_the_last_sample_of_each_kind

Status: done — the history holds the last sample of each instance (participantGuidPrefix, kind; PID_KEY_HASH in the in-line QoS); superseded samples are not repeated.

§8.4.13.3 Reader durability.kind = TRANSIENT_LOCAL

Spec: §8.4.13.3, p. 118 — “both the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader shall use the following QoS values: durability.kind = TRANSIENT_LOCAL_DURABILITY”.

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::heartbeat_responses: the request starts at the HEARTBEAT’s firstSN, not at the match)

Tests: crates/dcps/src/wlp.rs::tests::a_heartbeat_announcing_a_pulse_not_received_is_answered_with_a_request_for_it, crates/dcps/tests/cyclone_live_wlp.rs::cyclone_live_wlp_handshake

Status: done

§8.4.13.3 Reader history KEEP_LAST, depth 1

Spec: §8.4.13.3, pp. 118–119 — “history.kind = KEEP_LAST_HISTORY_QOS”, “history.depth = 1”.

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::peers: per participant the state last received)

Tests: crates/dcps/src/wlp.rs::tests::wlp_handle_datagram_updates_peer_state

Status: done — the reader keeps no samples; it hands every sample received at once to the DataReaders’ liveliness bookkeeping and keeps last_seen and last_kind per participant.

§8.4.13.3 Writer reliability.kind = RELIABLE

Spec: §8.4.13.3, p. 119 — “The BuiltinParticipantMessageWriter shall use reliability.kind = RELIABLE_RELIABILITY_QOS.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint: make_writer, write_pulse, add_peer_reader, handle_reader_messages, tick); crates/dcps/src/runtime.rs (WLP-Tick, spdp_announced)

Tests: crates/dcps/src/wlp.rs::tests::the_writer_heartbeats_until_the_reader_has_acknowledged, crates/dcps/src/wlp.rs::tests::a_late_reader_is_told_by_heartbeat_and_gets_the_held_samples_on_request

Status: done — the writer keeps state per reader (reader proxy), sends HEARTBEATs until acknowledged and repairs on ACKNACK (handle_reader_messages).

§8.4.13.3 Reader RELIABLE or BEST_EFFORT

Spec: §8.4.13.3, p. 119 — “The BuiltinParticipantMessageReader may be configured to use either RELIABLE_RELIABILITY_QOS or BEST_EFFORT_RELIABILITY_QOS. If the BuiltinParticipantMessageReader is configured to use BEST_EFFORT_RELIABILITY_QOS then the BEST_EFFORT_PARTICIPANT_MESSAGE_DATA_READER flag in ParticipantProxy::builtinEndpointQos shall be set.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::heartbeat_responses)

Tests: crates/dcps/src/wlp.rs::tests::a_heartbeat_announcing_a_pulse_not_received_is_answered_with_a_request_for_it, crates/dcps/src/wlp.rs::tests::once_the_pulse_arrived_a_final_heartbeat_gets_no_answer_and_a_plain_one_the_ack

Status: done — the reader answers HEARTBEATs as a RELIABLE reader does; the flag does not apply, ZeroDDS sends no PID_BUILTIN_ENDPOINT_QOS.

§8.4.13.3 The writer treats the reader by builtinEndpointQos

Spec: §8.4.13.3, p. 119 — “If the ParticipantProxy::builtinEndpointQos is included in the SPDPdiscoveredParticipantData, then the BuiltinParticipantMessageWriter shall treat the BuiltinParticipantMessageReader as indicated by the flags. If the ParticipantProxy::builtinEndpointQos is not included then the BuiltinParticipantMessageWriter shall treat the BuiltinParticipantMessageReader as if it is configured with RELIABLE_RELIABILITY_QOS.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::add_peer_reader, sync_proxy); crates/dcps/src/runtime.rs (spdp_announced)

Tests: crates/dcps/src/wlp.rs::tests::the_reader_is_treated_as_builtin_endpoint_qos_says

Status: done — with builtinEndpointQos and the flag the reader is a best-effort proxy (no HEARTBEATs), otherwise RELIABLE.

§8.4.13.4 Figure 8.26 ParticipantMessageData

Spec: §8.4.13.4, p. 119, Figure 8.26 — “Figure 8.26 defines the ParticipantMessageData datatype associated with the RTPS built-in Endpoint for the DCPSParticipantMessage Topic.” Attributes participantGuidPrefix, kind, data.

Repo: crates/rtps/src/participant_message_data.rs (ParticipantMessageData, to_cdr, from_cdr)

Tests: crates/rtps/src/participant_message_data.rs::tests::participant_message_data_octets_are_those_of_9_6_3_1, crates/rtps/src/participant_message_data.rs::tests::participant_message_data_reads_the_fast_dds_beat, crates/rtps/src/participant_message_data.rs::tests::participant_message_data_roundtrip_with_topic_token

Status: done

§8.4.13.5 AUTOMATIC: a sample faster than the shortest lease

Spec: §8.4.13.5, p. 119 — “If the Participant contains one or more Writers with a liveliness of AUTOMATIC_LIVELINESS_QOS, then one sample is written at a rate faster than the smallest lease duration among the Writers sharing this QoS.”

Repo: crates/dcps/src/runtime.rs (refresh_wlp_period: a third of the shortest finite lease of an AUTOMATIC writer, at most a third of the participant lease); crates/dcps/src/wlp.rs (WlpEndpoint::tick)

Tests: crates/dcps/tests/liveliness_qos.rs::linux::an_automatic_writer_that_never_writes_stays_alive_at_a_remote_reader, crates/dcps/src/wlp.rs::tests::wlp_tick_emits_again_after_period, crates/dcps/src/runtime.rs::tests::wlp_period_default_is_lease_over_three

Status: done — the AUTOMATIC sample also goes out without an AUTOMATIC writer.

§8.4.13.5 MANUAL_BY_PARTICIPANT: a separate sample

Spec: §8.4.13.5, p. 119 — “Similarly, a separate sample is written if the Participant contains one or more Writers with a liveliness of MANUAL_BY_PARTICIPANT_LIVELINESS_QOS at a rate faster than the smallest lease duration among these Writers.”

Repo: crates/dcps/src/runtime.rs (DcpsRuntime::assert_liveliness, refresh_manual_by_participant); crates/dcps/src/wlp.rs (WlpEndpoint::assert_participant, refresh_participant)

Tests: crates/dcps/src/wlp.rs::tests::wlp_assert_participant_emits_manual_pulse, crates/dcps/src/wlp.rs::tests::refreshes_before_the_tick_share_one_manual_by_participant_sample, crates/dcps/tests/wlp_integration.rs::linux_only::manual_by_participant_pulse_arrives_at_peer, crates/dcps/src/runtime.rs::tests::a_manual_by_participant_writer_refreshes_the_participant_liveliness

Status: done — the sample is written by DomainParticipant::assert_liveliness and by write, assert_liveliness, dispose and unregister_instance of a MANUAL_BY_PARTICIPANT writer; calls before the tick share one sample.

§8.4.13.5 Two instances, key participantGuidPrefix and kind

Spec: §8.4.13.5, p. 119 — “The instances are distinguished using their DDS key, which is comprised of the participantGuidPrefix and kind fields. Each of the two types of liveliness QoS handled through this protocol will result in a unique kind field and therefore form two distinct instances in the HistoryCache.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::write_pulse)

Tests: crates/dcps/src/wlp.rs::tests::the_history_holds_the_last_sample_of_each_kind, crates/dcps/src/wlp.rs::tests::wlp_assert_participant_emits_manual_pulse, crates/dcps/src/wlp.rs::tests::wlp_handle_datagram_updates_peer_state

Status: done — the instance is (participantGuidPrefix, kind); the KeyHash (12 octets of prefix, 4 octets of kind, big endian) is PID_KEY_HASH in the in-line QoS of every DATA, and the history holds one sample per instance.

§8.4.13.5 participantGuidPrefix of the writing participant

Spec: §8.4.13.5, p. 119 — “In both liveliness cases the participantGuidPrefix field contains the GuidPrefix_t of the Participant that is writing the data (and therefore asserting the liveliness of its Writers).”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::encode_pulse: ParticipantMessageData::automatic(self.own_prefix))

Tests: crates/dcps/src/wlp.rs::tests::wlp_handle_datagram_updates_peer_state, crates/rtps/src/participant_message_data.rs::tests::participant_message_data_automatic_default_data_empty

Status: done

§8.4.13.5 MANUAL_BY_TOPIC not through the BuiltinParticipantMessageWriter

Spec: §8.4.13.5, p. 119 — “The DDS liveliness kind MANUAL_BY_TOPIC_LIVELINESS_QOS is not implemented using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. It is discussed in 8.7.2.2.3.”

Repo: crates/dcps/src/publisher.rs (DataWriter::assert_liveliness → DcpsRuntime::assert_writer_liveliness_eid: HEARTBEAT with the LivelinessFlag)

Tests: crates/dcps/src/runtime.rs::tests::assert_liveliness_keeps_a_manual_writer_alive_without_writing, crates/rtps/src/reliable_writer.rs::tests::liveliness_heartbeat_is_a_final_heartbeat_with_the_liveliness_flag

Status: done — DcpsRuntime::assert_writer_liveliness also writes a sample with the vendor kind 0x80000001; the DCPS API does not call it.

§8.4.14 Optional behavior

Spec: §8.4.14, p. 119 — “Optional features may not be supported by all RTPS implementations. An optional feature does not affect basic interoperability, but is only available if all implementations involved support it.”

Repo: —

Tests: —

Status: n/a (informative) — classification of the following subclauses, no requirement.

§8.4.14.1 Large Data: transport limits and fragment submessages

Spec: §8.4.14.1, p. 120 — “a transport may impose its own limitations. For example, it may limit the maximum packet size (e.g., 64K for UDP) … 8.3.8 introduces the following Submessages to enable fragmenting large data: DataFrag, HeartbeatFrag, NackFrag”.

Repo: —

Tests: —

Status: n/a (informative) — rationale, no requirement; the submessages are listed under §8.3.8.

§8.4.14.1 Fragment size from the writer’s transports

Spec: §8.4.14.1, p. 120 — “All transports available to the Writer must be able to accommodate DataFrag Submessages containing at least one fragment. This means the transport with the smallest maximum message size determines the fragment size.” “Note the fragment size is determined by all transports available to the Writer, not simply the subset of transports required to reach all currently known Readers.”

Repo: crates/transport/src/lib.rs (Transport::max_message_size, DEFAULT_MAX_MESSAGE_SIZE); crates/transport-udp/src/udp_transport.rs (UdpTransportConfig::max_message_size); crates/transport-shm, transport-uds, transport-tcp, transport-tsn (each max_message_size); crates/dcps/src/layered_transport.rs (minimum of the legs); crates/rtps/src/reliable_writer.rs (fragment_size_for_message_size); crates/dcps/src/runtime.rs (writer creation)

Tests: crates/dcps/src/runtime.rs::tests::a_writers_fragment_size_follows_the_message_size_of_its_transport, crates/rtps/src/reliable_writer.rs::tests::the_fragment_size_is_bounded_by_what_the_field_holds, crates/transport-udp/src/udp_transport.rs::tests::max_message_size_is_the_configured_one_up_to_the_datagram_limit, crates/dcps/tests/runtime_config_layering.rs::the_udp_message_size_is_a_setting, crates/rtps/src/reliable_writer.rs::tests::fragment_size_is_fixed_and_a_larger_path_gets_one_data

Status: done — every transport states its largest message (Transport::max_message_size; for UDP it is a setting, transport.udp.max_message_size, default 1472; SHM and UDS their datagram limit, TCP the frame limit, TSN 1500; the layered transport the minimum of its legs). The fragment size of a writer is the message of the smallest transport less 128 octets, fixed for the life of the writer: 1344 at the default.

§8.4.14.1 Fragment size fixed per writer

Spec: §8.4.14.1, p. 120 — “The fragment size must be fixed for a given Writer and is identical for all remote Readers. By fixing the fragment size, the data a fragment number refers to does not depend on a particular remote Reader.”

Repo: crates/rtps/src/reliable_writer.rs (ReliableWriter::fragment_size_for, needs_fragmentation); crates/rtps/src/reader_proxy.rs (ReaderProxy::message_limit)

Tests: crates/rtps/src/reliable_writer.rs::tests::fragment_size_is_fixed_and_a_larger_path_gets_one_data, crates/rtps/src/reliable_writer.rs::tests::the_fragment_size_does_not_depend_on_the_reader_expecting_inline_qos

Status: done — the fragment size is not changed after the writer is created (set_fragmentation is gone) and is the same for all readers; the in-line QoS that shortens a fragment is counted at its largest length for any reader, so a reader’s expectsInlineQos does not change it either.

§8.4.14.1 Fragment size ≤ 65536

Spec: §8.4.14.1, p. 120 — “The fragment size must satisfy: fragment size <= 65536 bytes.”

Repo: crates/rtps/src/reliable_writer.rs (MAX_FRAGMENT_SIZE, ReliableWriter::try_new, ReliableWriter::new, fragment_size_for)

Tests: crates/rtps/src/reliable_writer.rs::tests::the_fragment_size_is_bounded_by_what_the_field_holds

Status: done — fragmentSize of the DATA_FRAG is an unsigned short; 65536 has no encoding, the bound is 65535. try_new refuses larger values with an error (new panics). A DATA_FRAG holds its 32 fixed octets, the in-line QoS and the fragment in the 65535 octets of octetsToNextHeader; the fragment size is accordingly at most 65503.

§8.4.14.1 DataFrag in increasing fragment number

Spec: §8.4.14.1, p. 120 — “DataFrag Submessages are sent in order, where ordering is defined by increasing fragment numbers.”

Repo: crates/rtps/src/reliable_writer.rs (push_sample_datagrams)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_above_fragment_size_packs_the_fragments_a_message_carries

Status: done

§8.4.14.1 Fragment only if required (per sequence number)

Spec: §8.5.3.1, p. 125 — “The pre-configured list of locators may include both unicast and multicast locators. Port numbers are defined by each PSM.”

Repo: crates/dcps/src/runtime.rs (send_spdp_multicast, send_spdp_unicast, expand_initial_peer)

Tests: crates/dcps/src/runtime.rs::tests::multicast_free_discovery_via_initial_peers, crates/dcps/src/runtime.rs::tests::expand_initial_peer_ip_only_yields_well_known_port_range

Status: done

Repo: —

Tests: —

Status: n/a (informative) — the duty to SEDP is listed under §8.5.1; the rest is a permission.

§8.6 Versioning and Extensibility

§8.6 Processing higher minor versions

Spec: §8.6, p. 137 — “Implementations of this version of the RTPS protocol should be able to process RTPS Messages not only with the same major version but possibly higher minor versions.”

Repo: crates/rtps/src/datagram.rs (decode_datagram: only a higher major version is refused)

Tests: crates/rtps/src/datagram.rs::tests::decode_accepts_minor_version_above_supported, crates/rtps/src/datagram.rs::tests::decode_rejects_major_version_above_supported

Status: done

§8.6.1 Skip unknown submessages

Spec: §8.6.1, p. 137 — “Additional Submessages with other submessageIds can be introduced and used anywhere in an RTPS Message. An implementation should skip over unknown Submessages using the submessageLength field in the SubmessageHeader.”

Repo: crates/rtps/src/datagram.rs (decode_datagram, ParsedSubmessage::Unknown)

Tests: crates/rtps/src/datagram.rs::tests::decode_skips_unknown_submessage_without_must_understand, crates/rtps/src/datagram.rs::tests::decode_skips_an_unknown_submessage_whatever_its_flags

Status: done — a submessage with an unknown SubmessageId is skipped by submessageLength, also with flag bit 7 set (§8.3.4.1 rule 3 has no must-understand at submessage level).

§8.6.1 Skip additional fields at the end of a submessage

Spec: §8.6.1, p. 137 — “Additional fields can be added to the end of a Submessage that was already defined in the current minor version. An implementation should skip over additional fields using the submessageLength field in the SubmessageHeader.”

Repo: crates/rtps/src/datagram.rs (decode_submessage); the read_body of the submessages in crates/rtps/src/submessages.rs

Tests: crates/rtps/src/datagram.rs::tests::additional_fields_at_the_end_of_a_known_submessage_are_skipped

Status: done — HEARTBEAT, ACKNACK, GAP, HEARTBEAT_FRAG, NACK_FRAG, INFO_TS, INFO_SRC, INFO_REPLY, INFO_REPLY_IP4 and INFO_DST give the same value with eight more octets at the end of the body as without. For DATA and DATA_FRAG the body ends with the payload; new fields before it are skipped through octetsToInlineQos.

§8.6.1 Ignore unknown built-in endpoints

Spec: §8.6.1, p. 137 — “Additional built-in Endpoints with new IDs can be added. An implementation should ignore any unknown built-in Endpoints.”

Repo: crates/discovery/src/sedp/stack.rs (routing of known EntityIds only); crates/discovery/src/sedp/stack.rs (on_participant_discovered: known bits only)

Tests: crates/discovery/src/sedp/stack.rs::tests::routing_unknown_with_wrong_writer_does_not_match, crates/discovery/src/sedp/stack.rs::tests::partial_endpoint_set_wires_only_matching_sides

Status: done

§8.6.1 Ignore unknown parameters

Spec: §8.6.1, p. 137 — “Additional parameters with new parameterIds can be added. An implementation should ignore any unknown parameters.”

Repo: crates/rtps/src/parameter_list.rs (ParameterList::from_bytes); crates/rtps/src/publication_data.rs (decoders pass over unknown PIDs)

Tests: crates/rtps/src/publication_data.rs::tests::unknown_pids_are_skipped, crates/rtps/src/parameter_list.rs::tests::validate_must_understand_in_data_pipeline_optional_unknown_pid_passes

Status: done — unknown PIDs with the must-understand bit are listed under §9.4.2.11.

§8.6.1 Extensions raise the minor version

Spec: §8.6.1, p. 137 — “All such changes require an increase of the minor version number.”

Repo: —

Tests: —

Status: n/a (informative) — a requirement on future editions of the specification.

§8.6.2 What cannot change within the major version

Spec: §8.6.2, p. 137 — “A Submessage cannot be deleted. A Submessage cannot be modified except as described in 8.6.1. The meaning of submessageIds cannot be modified.”

Repo: —

Tests: —

Status: n/a (informative) — a requirement on future editions of the specification.

§8.7 Implementing DDS QoS and advanced DDS features using RTPS

Spec: §9.3.2.1, p. 155 — “typedef octet GroupDigest_t[4];”

Repo: crates/rtps/src/group_digest.rs (GroupDigest, GroupDigest::of_entities)

Status: done

§9.3.2.1 BuiltinEndpointSet_t (IDL)

Spec: §9.3.2.1, p. 155 — “bitmask BuiltinEndpointSet_t { @position(0) DISC_BUILTIN_ENDPOINT_PARTICIPANT_ANNOUNCER, … @position(29) DISC_BUILTIN_ENDPOINT_TOPICS_DETECTOR };”

Repo: crates/rtps/src/participant_data.rs (endpoint_flag)

Tests: crates/rtps/src/participant_data.rs::tests::endpoint_flag_bit_positions_match_spec

Status: done — the positions are listed one by one under §9.3.2.12.

Spec: §9.3.2.4, p. 156 — “0x00000003 - 0x01ffffff (inclusive) are reserved for vendor-specific Locator_t kinds … 0x02000000 - 0x02ffffff (inclusive) are reserved for future use by the RTPS specification … 0x03000000 and greater are reserved for Locator_t kinds that identify a transport developed by a third-party”.

Repo: crates/rtps/src/wire_types.rs (LocatorKind, LocatorKind::from_i32, set_tcp_kinds_fast_dds); crates/dcps/src/runtime.rs (RuntimeConfig::tcp_locator_kinds_fast_dds, key transport.tcp_locator_kinds)

Tests: crates/rtps/src/wire_types.rs::tests::the_zerodds_locator_kinds_are_in_the_vendor_specific_range, crates/rtps/src/wire_types.rs::tests::the_tcp_kinds_are_vendor_range_by_default_and_fast_dds_by_setting, crates/rtps/src/wire_types.rs::tests::locator_kind_rejects_unknown, crates/transport-tcp/src/tcp_transport.rs::tests::locator_kinds_are_zerodds_vendor_range_values, crates/dcps/tests/runtime_config_layering.rs::the_tcp_locator_kinds_are_a_setting, crates/transport-shm/src/posix.rs::tests::locator_kind_is_the_vendor_reserved_shm_value, crates/transport-uds/src/lib.rs::tests::locator_kind_is_the_vendor_reserved_uds_value, crates/rtps/src/submessages.rs::tests::info_reply_leaves_out_a_locator_of_a_kind_it_does_not_know

Status: done — all kinds besides UDPv4 (1) and UDPv6 (2) lie in the vendor range 3 to 0x01ffffff: Shm, Uds, Tsn (0x01F0_0001 to 0x01F0_0003) and now Tcpv4 (0x01F0_0004) and Tcpv6 (0x01F0_0005). ZeroDDS sends the values 4 and 8 of Fast DDS (and of the DDS-TCP-PSM) only with the named setting transport.tcp_locator_kinds: fast-dds (environment ZERODDS_TCP_LOCATOR_KINDS, man page, example configuration); both values are read. A kind the receiver does not know does not invalidate an INFO_REPLY, the locator is left out. Expected Fast DDS behaviour: with fast-dds it recognises the TCP locators of ZeroDDS (kinds 4 and 8); without the setting it ignores kinds in the vendor range and opens no TCP connection to ZeroDDS. Not measured.

Spec: §9.4.2.15, p. 166, Table 9.8 — “0, 0 — N/A — The messageChecksum is not included in the HeaderExtension”.

Repo: crates/rtps/src/header_extension.rs (ChecksumKind::None)

Tests: crates/rtps/src/header_extension.rs::tests::checksum_kind_roundtrip, crates/rtps/src/header_extension.rs::tests::empty_he_le_roundtrip

Status: done

§9.4.3.1 LocatorUDPv4

Spec: §9.4.3.1, p. 170, Table 9.13 — “The LocatorUDPv4 SubmessageElement is identical to a LocatorList SubmessageElement containing a single locator of kind LOCATOR_KIND_UDPv4.” Wire form unsigned long address, unsigned long port.

Repo: crates/rtps/src/submessages.rs (InfoReplyIp4Submessage::write_locator_udpv4, read_locator_udpv4)

Tests: crates/rtps/src/submessages.rs::tests::locator_udpv4_is_two_unsigned_longs_in_the_byte_order_of_the_submessage, crates/rtps/src/submessages.rs::tests::info_reply_ip4_with_multicast_roundtrip_be

Status: done — address and port are each an unsigned long in the byte order of the submessage; 192.0.2.10 is the number 0xC000020A (first octet most significant). Before, the address was four octets in network order in every byte order, which differs in the little-endian case. 2.5 does not define LocatorUDPv4_t; the mapping of a.b.c.d to the number is an assumption. No vendor is measured.

Spec: §9.4.4, p. 170 — wire form 'R' 'T' 'P' 'S', ProtocolVersion version, VendorId vendorId, GuidPrefix guidPrefix. “The structure of the Header cannot change in this major version (2) of the protocol.”

Repo: crates/rtps/src/header.rs (RtpsHeader::to_bytes, from_bytes)

Tests: crates/rtps/src/header.rs::tests::header_roundtrip, crates/rtps/src/header.rs::tests::header_total_size_is_20_bytes

Status: done

Spec: §9.4.5.6, p. 177 — “F = SubmessageHeader.flags & 0x04”.

Repo: crates/rtps/src/submessages.rs (GAP_FLAG_FILTERED_COUNT = 0x04)

Tests: crates/rtps/src/submessages.rs::tests::the_gap_flags_are_those_of_9_4_5_6

Status: done

§9.4.5.6 Gap gapStartGSN and gapEndGSN

Spec: §9.4.5.6, p. 177 — “G=1 means the Gap also includes a gapStartGSN and a gapEndGSN.”

Repo: —

Status: done

§9.4.5.7 Heartbeat: wire form

Spec: §9.4.5.7, p. 178 — HEARTBEAT |X|X|X|X|G|L|F|E|, readerId, writerId, firstSN, lastSN, Count count, currentGSN/firstGSN/lastGSN [G].

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::write_body, read_body)

Tests: crates/rtps/src/submessages.rs::tests::heartbeat_submessage_roundtrip_le, crates/rtps/tests/cyclone_compliance.rs::cyclone_heartbeat_decodes

Status: done — the part after count is listed under “Heartbeat: group fields”.

§9.4.5.7 Heartbeat FinalFlag (0x02)

Spec: §9.4.5.7, p. 178 — “F = SubmessageHeader.flags & 0x02”.

Repo: crates/rtps/src/submessages.rs (HEARTBEAT_FLAG_FINAL = 0x02)

Tests: crates/rtps/src/datagram.rs::tests::decode_heartbeat_preserves_final_and_liveliness_flags

Status: done

§9.4.5.7 Heartbeat LivelinessFlag (0x04)

Spec: §9.4.5.7, p. 178 — “L = SubmessageHeader.flags & 0x04”.

Repo: crates/rtps/src/submessages.rs (HEARTBEAT_FLAG_LIVELINESS = 0x04)

Tests: crates/rtps/src/submessages.rs::tests::heartbeat_submessage_liveliness_flag_roundtrip, crates/rtps/src/datagram.rs::tests::decode_heartbeat_preserves_final_and_liveliness_flags

Status: done

§9.4.5.7 Heartbeat GroupInfoFlag (0x08)

Spec: §9.4.5.7, p. 178 — “G = SubmessageHeader.flags & 0x08”.

Repo: crates/rtps/src/submessages.rs (HEARTBEAT_FLAG_GROUP_INFO = 0x08)

Tests: crates/rtps/src/submessages.rs::tests::heartbeat_with_group_info_roundtrip_le, crates/rtps/src/submessages.rs::tests::the_group_info_is_the_three_sequence_numbers_of_9_4_5_7

Status: done

Spec: §9.4.5.15, p. 181 — INFO_REPLY_IP4 |X|X|X|X|X|X|M|E|, LocatorUDPv4 unicastLocator, LocatorUDPv4 multicastLocator [M]. “Its use and interpretation are identical to those of an InfoReply Submessage containing a single unicast and possibly a single multicast locator”.

Repo: crates/rtps/src/submessages.rs (InfoReplyIp4Submessage)

Status: done — structure (unicast LocatorUDPv4, with the M flag a multicast LocatorUDPv4), flags (E, M) and effect are right; the address follows LocatorUDPv4 (item under §9.4.3.1).

§9.4.5.15 InfoReplyIp4 MulticastFlag (0x02)

Spec: §9.4.5.15, p. 182 — “M = SubmessageHeader.flags & 0x02”.

Repo: crates/rtps/src/submessages.rs (InfoReplyIp4Submessage::write_body, read_body)

Tests: crates/rtps/src/submessages.rs::tests::info_reply_ip4_with_multicast_roundtrip_be

Status: done

§9.5 One message per UDP datagram

Spec: §9.5, p. 182 — “When RTPS is used over UDP/IP, a Message is the contents (payload) of exactly one UDP/IP Datagram.”

Repo: crates/transport-udp/src/udp_transport.rs (UdpTransport)

Tests: crates/transport-udp/tests/e2e.rs::e2e_write_udp_read_single_datagram, crates/transport-udp/src/udp_transport.rs::tests::without_the_cache_a_largest_datagram_arrives

Status: done

§9.6.1 ParameterIds in the HeaderExtension

Spec: §9.6.1, p. 182 — “This version of the protocol does not specify any ParameterId that may appear in the HeaderExtension. … Compliant implementations encountering an unrecognized ParameterId within the HeaderExtension shall either skip and the parameter or reject the entire RTPS Message, as specified in Table 9.6.”

Repo: crates/rtps/src/datagram.rs (decode_datagram: validate_must_understand_in_data_pipeline on the parameters of the HeaderExtension)

Tests: crates/rtps/tests/cyclone_he_must_understand.rs::the_decoder_refuses_a_header_extension_with_an_unknown_must_understand_pid, crates/rtps/src/header_extension.rs::tests::roundtrip_with_parameter_list, crates/rtps/src/datagram.rs::tests::decode_data_after_header_extension, crates/rtps/src/parameter_list.rs::tests::a_vendor_specific_must_understand_pid_of_another_vendor_is_an_error

Status: done — an unrecognized PID with bit 0x4000 in the HeaderExtension drops the message, a vendor-specific one included (see Table 9.6); one without the bit is skipped.

§9.6.2.1 Table 9.15 SPDP_WELL_KNOWN_MULTICAST_PORT

Spec: §9.6.2.1, p. 182, Table 9.15 — “Multicast — SPDP_WELL_KNOWN_MULTICAST_PORT — PB + DG * domainId + d0”.

Repo: crates/rtps/src/wire_types.rs (spdp_multicast_port)

Tests: crates/rtps/src/wire_types.rs::tests::all_four_ports_follow_the_spec_formula, crates/rtps/src/wire_types.rs::tests::spdp_multicast_port_domain_0_is_7400

Status: done

§9.6.2.1 Table 9.15 SPDP_WELL_KNOWN_UNICAST_PORT

Spec: §9.6.2.1, p. 182, Table 9.15 — “Unicast — SPDP_WELL_KNOWN_UNICAST_PORT — PB + DG * domainId + d1 + PG * participantId”.

Repo: crates/rtps/src/wire_types.rs (spdp_unicast_port)

Tests: crates/rtps/src/wire_types.rs::tests::domain_zero_ports_match_the_worked_spec_example, crates/dcps/src/runtime.rs::tests::spdp_unicast_port_follows_rtps_formula

Status: done

§9.6.2.1 A unique participantId per node and domain

Spec: §9.6.2.1, p. 182 — “Each Participant on the same node and in the same domain must use a unique participantId.” “participantId values ideally start at 0 and are incremented for each additional Participant on the same node and in the same domain.”

Repo: crates/dcps/src/runtime.rs (DcpsRuntime::start: participantId 0 to 119, the first free SPDP unicast port; otherwise a free port)

Tests: crates/dcps/src/runtime.rs::tests::two_runtimes_discover_each_other_via_spdp, crates/dcps/src/runtime.rs::tests::expand_initial_peer_ip_only_yields_well_known_port_range

Status: done — if none of the 120 ports is free, ZeroDDS binds any port and is reachable only through multicast.

§9.6.2.1 SEDP on the ports of SPDP

Spec: §9.6.2.1, p. 182 — “The default ports used by the SEDP built-in Endpoints match those used by the SPDP. If a node chooses not to use the default ports for the SEDP, it can include the new port numbers as part of the information exchanged during the SPDP.”

Repo: crates/dcps/src/runtime.rs (metatraffic locators = the SPDP unicast socket and the SPDP multicast group)

Tests: crates/dcps/src/runtime.rs::tests::two_runtimes_discover_each_other_via_spdp

Status: done

§9.6.2.2 Table 9.16 user traffic: multicast port

Spec: §9.6.2.2, p. 183, Table 9.16 — “Multicast — PB + DG * domainId + d2”. “User-defined Endpoints may choose to not use the default ports.”

Repo: crates/rtps/src/wire_types.rs (user_traffic_multicast_port); crates/dcps/src/runtime.rs (transport.user_multicast)

Tests: crates/rtps/src/wire_types.rs::tests::all_four_ports_follow_the_spec_formula, crates/dcps/src/runtime.rs::tests::the_user_multicast_port_is_d2_and_announced_unless_turned_off

Status: done — ZeroDDS endpoints announce the multicast locator on PB + DG * domainId + d2 (default; transport.user_multicast: false for a host without multicast). Expected: Cyclone DDS (announces 239.255.0.1 on d2), Fast DDS and OpenDDS accept an announced multicast locator or ignore it; ZeroDDS writers themselves send to unicast locators only.

§9.6.2.2 Table 9.16 user traffic: unicast port

Spec: §9.6.2.2, p. 183, Table 9.16 — “Unicast — PB + DG * domainId + d3 + PG * participantId”. “In that case, remote Endpoints obtain the port number as part of the information exchanged during the Simple Endpoint Discovery Protocol.”

Repo: crates/rtps/src/wire_types.rs (user_traffic_unicast_port); crates/dcps/src/runtime.rs (user socket on a freely chosen port, announced as the default unicast locator)

Tests: crates/rtps/src/wire_types.rs::tests::the_four_ports_of_one_participant_are_distinct, crates/dcps/src/runtime.rs::tests::announce_locators_automatic_is_non_empty_and_includes_probe

Status: done — ZeroDDS does not use the default port but announces the port bound, as the subclause permits.

§9.6.2.3 Default values PB, DG, PG, d0–d3

Spec: §9.6.2.3, p. 183 — “PB = 7400 DG = 250 PG = 2 d0 = 0 d1 = 10 d2 = 1 d3 = 11”.

Repo: crates/rtps/src/wire_types.rs (SPDP_PORT_BASE, SPDP_DOMAIN_GAIN, SPDP_PARTICIPANT_GAIN and the offsets)

Tests: crates/rtps/src/wire_types.rs::tests::port_formula_constants_match_spec

Status: done

§9.6.2.3 Parameters customisable by the user

Spec: §9.6.2.3, p. 183 — “Implementations must expose these parameters so they can be customized by the user.”

Repo: crates/rtps/src/wire_types.rs (PortMapping); crates/dcps/src/runtime.rs (RuntimeConfig::port_mapping, select_user_transport, user_port_fallbacks, transport.user_multicast); man/man5/zerodds.yaml.5

Tests: crates/rtps/src/wire_types.rs::tests::the_port_mapping_formulas_use_the_given_parameters, crates/dcps/tests/runtime_config_layering.rs::the_port_mapping_parameters_are_settings, crates/dcps/src/runtime.rs::tests::the_spdp_unicast_port_follows_the_configured_port_mapping, crates/dcps/src/runtime.rs::tests::the_user_unicast_socket_takes_the_d3_port_of_its_participant_id, crates/dcps/src/runtime.rs::tests::a_taken_user_port_is_counted_and_the_socket_takes_an_ephemeral_one, crates/dcps/src/runtime.rs::tests::the_user_multicast_port_is_d2_and_announced_unless_turned_off

Status: done — PB, DG, PG and d0 to d3 are settings (file and environment, 0..=65535, default the spec’s values). The runtime binds the discovery ports (d0, d1) and the user unicast socket to PB + DG * domainId + d3 + PG * participantId, with the participantId of the SPDP unicast socket; if the port is taken the socket takes an ephemeral port, which is counted (user_port_fallbacks) and logged as the event transport.user_unicast.port_taken. The user multicast port d2 is bound with transport.user_multicast (join of the SPDP group, reception, announcement as the default multicast locator); default on (the default locators of §9.6.2.3 include d2), false for a host without multicast. A peer otherwise reaches it at its unicast locators. Measured in tools/wire-capture/rtps-sessions (locators of the SPDP announcements): Fast DDS 2.6.10 and RTI 7.7.0 bind d1/d3 + PG * participantId (Fast DDS 23160/23161, 23162/23163; RTI 22910/22911, 22912/22913); Cyclone 11.0.1 takes ephemeral ports for metatraffic and user data (the same port) and announces default multicast 239.255.0.1 on d2; OpenDDS 3.34.0 takes an ephemeral metatraffic port and announces 127.0.0.1:12345 as user locator (no d3 port). Not measured: a run against the vendors with the port change, and the behaviour of ZeroDDS writers towards announced multicast locators (they send to unicast locators only).

§9.6.2.4 Default multicast address 239.255.0.1

Spec: §9.6.2.4, p. 183 — “DefaultMulticastLocator = {LOCATOR_KIND_UDPv4, “239.255.0.1”, PB + DG * domainId + d0}. All Participants must announce and listen on this multicast address.”

Repo: crates/rtps/src/wire_types.rs (SPDP_DEFAULT_MULTICAST_ADDRESS); crates/dcps/src/runtime.rs (spdp_multicast_group, joining and announcing)

Tests: crates/rtps/src/wire_types.rs::tests::spdp_default_multicast_is_239_255_0_1, crates/discovery/tests/spdp_loopback_e2e.rs::loopback_multicast_self_discovery

Status: done — the group is configurable; without multicast ZeroDDS works with initial peers.

§9.6.2.4 Default announcement rate 30 seconds

Spec: §9.6.2.4, p. 183 — “The default rate by which SPDP periodic announcements are sent equals 30 seconds. SPDPbuiltinParticipantWriter. resendPeriod = {30, 0};”

Repo: crates/dcps/src/runtime.rs (DEFAULT_SPDP_PERIOD, default_spdp_period_for); man/man5/zerodds.yaml.5; packaging/linux/configs/zerodds.yaml.example

Tests: crates/dcps/src/runtime.rs::tests::a_short_lease_without_a_period_beacons_three_times_a_lease, crates/dcps/tests/runtime_config_layering.rs::the_protocol_timing_parameters_are_settings

Status: done — DEFAULT_SPDP_PERIOD = 30 s (YAML default, man page, example configuration); the former 5 s stay reachable through discovery.spdp_period_ms: 5000. A lease under 90 s shortens the default to a third (§8.5.3.1).

§9.6.3.1 ParticipantMessageData: structure and wire form

Spec: §9.6.3.1, p. 184 — “struct ParticipantMessageData { GuidPrefix_t participantGuidPrefix; OctetArray4 kind; OctetSeq data; };” wire form: GuidPrefix_t participantGuidPrefix (12 octets), octet[4] kind, unsigned long data.length, octet[] data.value.

Spec: §9.6.3.2, p. 186, Table 9.18 — “PID_LIVELINESS — 0x001b — LivelinessQosPolicy”; Table 9.19, p. 188 — Topic, Publication, Subscription liveliness.

Repo: crates/qos/src/pid.rs (Pid::LIVELINESS)

Status: done

Spec: §9.6.3.2, p. 186, Table 9.18 — “PID_OWNERSHIP — 0x001f — OwnershipQosPolicy”; Table 9.19, p. 188 — Topic, Publication, Subscription ownership.

Repo: crates/qos/src/pid.rs (Pid::OWNERSHIP)

Status: done

§9.6.3.2 Table 9.18/9.19 PID_OWNERSHIP_STRENGTH

Spec: §9.6.3.2, p. 186, Table 9.18 — “PID_OWNERSHIP_STRENGTH — 0x0006 — OwnershipStrengthQosPolicy”; Table 9.19, p. 188 — PublicationBuiltinTopicData::ownership_strength.

Repo: crates/qos/src/pid.rs (Pid::OWNERSHIP_STRENGTH)

Tests: crates/rtps/tests/sedp_qos_roundtrip.rs::publication_data_roundtrip_preserves_all_new_qos_policies

Status: done

§9.6.4.8 KeyHash: 16 octets

Spec: §9.6.4.8, p. 193 — “The KeyHash_t is defined as a 16-Byte octet array (see 9.3.2) therefore the key hash inline parameter just copies those 16 Bytes.”

Repo: crates/dcps/src/key_hash.rs (KEY_HASH_LEN); crates/rtps/src/inline_qos.rs (find_key_hash)

Tests: crates/dcps/src/key_hash.rs::tests::a_holder_of_exactly_sixteen_is_the_hash, crates/rtps/src/submessages.rs::tests::data_frag_key_hash_roundtrips_both_byte_orders

Status: done

§9.6.4.8 KeyHash step 1: FooKeyHolder

Spec: §9.6.4.8, pp. 193–194 — “FooKeyHolder shall have extensibility kind ‘FINAL’ … If there are any key members, then remove the non-key members … Reorder the members in ascending order of their memberId values.”

Repo: crates/dcps/src/key_hash.rs (keyhash_cdr2_be: sorting by member_id)

Tests: crates/dcps/src/key_hash.rs::tests::the_member_order_does_not_reach_the_hash

Status: done

§9.6.4.8 KeyHash steps 2 and 3: values and recursion

Spec: §9.6.4.8, p. 194 — “Step 2. … setting the members present in FooKeyHolderObject to the same values as the corresponding members in FooObject. Step 3. Apply steps 1 and 2 recursively to the members of FooKeyHolder if they are themselves Aggregated types”.

Repo: crates/dcps/src/key_hash.rs (PlainCdr2BeKeyHolder); crates/dcps/src/runtime.rs (reader_key_hash_context)

Tests: crates/dcps/src/runtime.rs::tests::alive_sample_without_key_hash_gets_the_types_computed_hash, crates/dcps/tests/lifecycle_wire_e2e.rs::linux::dispose_marker_carries_the_key_fields_of_a_string_keyed_type

Status: done

§9.6.4.8 KeyHash step 4: PLAIN_CDR2 big endian

Spec: §9.6.4.8, p. 194 — “Compute the PLAIN_CDR2 Big Endian Serialization … The serialization shall be performed on a buffer that is initially aligned to the maximum alignment in PLAIN_CDR2 (i.e., 4). Furthermore, any padding bytes added due to alignment rules shall be set to zero.”

Repo: crates/dcps/src/key_hash.rs (PlainCdr2BeKeyHolder)

Tests: crates/dcps/src/key_hash.rs::tests::a_u32_goes_out_big_endian, crates/dcps/src/key_hash.rs::tests::a_u64_is_aligned_to_four_and_not_to_eight, crates/dcps/src/key_hash.rs::tests::a_string_carries_its_terminator_in_its_length

Status: done

§9.6.4.8 KeyHash step 5: padding or MD5 by the maximum size

Spec: §9.6.4.8, p. 194 — “Step 5.1 If the FooKeyHolder has a maximum serialized size that is less than or equal to 16 bytes, then the KeyHash of FooObject shall be set to the result of Step 4, extended to 16 bytes. … Step 5.2 If the FooKeyHolder has a maximum serialized size that is greater than 16 bytes, then the KeyHash_t of FooObject shall be set to the MD5 Hash”.

Repo: crates/dcps/src/key_hash.rs (compute_key_hash: key_holder_max_size)

Tests: crates/dcps/src/key_hash.rs::tests::a_short_instance_of_a_bounded_type_still_pads, crates/dcps/src/key_hash.rs::tests::a_holder_over_sixteen_is_hashed

Status: done

§9.6.4.8 KeyHash examples 1 to 3

Spec: §9.6.4.8, pp. 194–196 — “Example 1 …”, “Example 2 …”, “Example 3 …” with the expected octets.

Repo: crates/dcps/src/key_hash.rs (PlainCdr2BeKeyHolder, compute_key_hash); crates/dcps/src/dds_type.rs (DdsType::compute_key_hash)

Tests: crates/dcps/src/dds_type.rs::tests::key_hash_example_1_of_the_spec_is_the_holder_padded_with_zeros, crates/dcps/src/dds_type.rs::tests::key_hash_example_2_of_the_spec_is_the_md5_of_the_holder, crates/dcps/src/dds_type.rs::tests::key_hash_example_3_of_the_spec_is_the_md5_of_the_reordered_holder

Status: done — the three examples give the octets of the spec: Example 1 the holder extended with zeros to 16 octets, Examples 2 and 3 the MD5 of the 20-octet and the 13-octet holder (f91a59e3…, 374b96e2…).

§9.6.4.9 StatusInfo_t: 4 octets

Spec: §9.6.4.9, p. 196 — “The StatusInfo_t is defined as a 4-Byte octet array (see 9.3.2) therefore the status info inline parameter just copies those 4 Bytes.”

Repo: crates/rtps/src/inline_qos.rs (status_info_param: network order; find_status_info)

Tests: crates/dcps/tests/lifecycle_wire_decode.rs::reader_push_lifecycle_unregistered_sets_instance_state, crates/dcps/tests/lifecycle_wire_e2e.rs::linux::unregister_with_autodispose_false_propagates_unregister_only

Status: done

§9.6.4.9 StatusInfo in Data or DataFrag

Spec: §9.6.4.9, p. 196 — “The status info parameter may appear in the Data or in the DataFrag submessages.”

Repo: crates/rtps/src/reliable_reader.rs (classify_change_kind for DATA, handle_data_frag_opening for DATA_FRAG)

Tests: crates/dcps/tests/lifecycle_wire_decode.rs::reader_push_lifecycle_disposed_sets_instance_state, crates/rtps/src/reliable_reader.rs::tests::a_reassembled_key_is_a_dispose_or_a_registration_as_a_data_is, crates/rtps/src/reliable_reader.rs::tests::a_reassembled_sample_with_the_filtered_flag_is_known_but_not_delivered

Status: done — evaluated in DATA and in DATA_FRAG (a key with D or U as dispose and unregister, F as a filtered sample).

§9.6.4.9 StatusInfo: X flags

Spec: §9.6.4.9, p. 197 — “The flags represented with the literal ‘X’ are unused by this version of the protocol and should be set to zero by the writer and not interpreted by the reader”.

Repo: crates/rtps/src/inline_qos.rs (status_info); crates/rtps/src/reliable_reader.rs (classify_change_kind: D and U only)

Tests: crates/dcps/tests/lifecycle_wire_decode.rs::reader_push_lifecycle_disposed_sets_instance_state

Status: done

§9.6.4.9 StatusInfo DisposedFlag

Spec: §9.6.4.9, p. 197 — “D=1 indicates that the DDS DataWriter has disposed the instance of the data-object whose Key appears in the submessage.”

Repo: crates/rtps/src/inline_qos.rs (status_info::DISPOSED = 0x1)

Tests: crates/dcps/tests/lifecycle_wire_e2e.rs::linux::dispose_propagates_over_wire_to_reader, crates/dcps/tests/lifecycle_wire_decode.rs::reader_push_lifecycle_disposed_sets_instance_state

Status: done

§9.6.4.9 StatusInfo UnregisteredFlag

Spec: §9.6.4.9, p. 197 — “U=1 indicates that the DDS DataWriter has unregistered the instance of the data-object whose Key appears in the submessage.”

Repo: crates/rtps/src/inline_qos.rs (status_info::UNREGISTERED = 0x2)

Tests: crates/dcps/tests/lifecycle_wire_decode.rs::reader_push_lifecycle_unregistered_sets_instance_state, crates/dcps/tests/lifecycle_wire_e2e.rs::linux::instance_goes_no_writers_when_its_last_writer_disappears

Status: done

§9.6.4.9 StatusInfo FilteredFlag

Spec: §9.6.4.9, p. 197 — “F=1 indicates that the DDS DataWriter has written as sample for the instance … but the sample did not pass the content filter specified by the DDS DataReader.” “If both DisposedFlag==0 and UnregisteredFlag=0 … FilteredFlag==1 indicates it did not pass the filter.”

Repo: crates/rtps/src/reliable_reader.rs (status_change_kind, classify_change_kind, ReliableReader::filtered_sample_count)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_sample_with_the_filtered_flag_is_known_but_not_delivered, crates/rtps/src/reliable_reader.rs::tests::a_reassembled_sample_with_the_filtered_flag_is_known_but_not_delivered, crates/rtps/src/reliable_reader.rs::tests::the_reader_keeps_the_status_of_each_change

Status: done — a DATA or DATA_FRAG with F = 1 and D = U = 0 (with or without payload and key flag) gives ChangeKind::AliveFiltered: the number is known and NA_FILTERED (the writer does not repeat it), the sample is not delivered and is counted in filtered_sample_count. With D or U set the lifecycle marker applies. ZeroDDS does not send F (the runtime does not filter on the writer side); whether another vendor sends F is not measured.

§9.6.4.9 Registration not propagated

Spec: §9.6.4.9, p. 197 — “Note that the protocol does not require that the DDS DataWriter propagates the”register” operation.”

Repo: —

Tests: —

Status: n/a (informative) — no requirement.

§9.6.5 Table 9.24 DDS-XTypes

Spec: §9.6.5, p. 197, Table 9.24 — “DDS-XTypes 1.1 … 1.3 — 0x0069, 0x0072, 0x0073, 0x0074, 0x0075, 0x0076; Note that 0x0076 was deprecated in DDS-XTypes 1.2”.

Repo: crates/rtps/src/parameter_list.rs (pid::DATA_REPRESENTATION, TYPE_CONSISTENCY_ENFORCEMENT, TYPE_INFORMATION)

Tests: crates/rtps/src/publication_data.rs::tests::issue30_type_identifier_from_standard_type_information, crates/discovery/tests/vendor_discovery_frames.rs::cyclone_announcements_read_and_write_back

Status: done

§9.6.5 Table 9.24 DDS-Security

Spec: §9.6.5, p. 197, Table 9.24 — “DDS-Security 1.1 — Parameter IDs in the range 0x1000 to 0x1FFF; Parameter IDs in the range 0x5000 to 0x5FFF”.

Repo: crates/rtps/src/parameter_list.rs (security PIDs 0x1001 to 0x1013)

Tests: crates/rtps/src/parameter_list.rs::tests::is_standard_pid_recognises_dds_security_pids, crates/rtps/src/participant_data.rs::tests::participant_security_info_pid_roundtrip

Status: done

§9.6.5 Table 9.24 DDS-RPC

Spec: §9.6.5, p. 197, Table 9.24 — “DDS-RPC 1.0 — 0x0080, 0x0081, 0x0082, 0x0083”.

Repo: crates/rtps/src/parameter_list.rs (pid::SERVICE_INSTANCE_NAME, RELATED_ENTITY_GUID, TOPIC_ALIASES, RELATED_SAMPLE_IDENTITY)

Tests: crates/rtps/src/parameter_list.rs::tests::rpc_pid_constants_match_spec, crates/rtps/src/publication_data.rs::tests::rpc_pid_constants_in_emitted_bytes

Status: done

§9.6.6 Table 9.25 PID_PERSISTENCE (0x0003)

Spec: §9.6.6, pp. 197–198, Table 9.25 — “PID_PERSISTENCE — 0x0003 — 2.2”; “These parameters should not be used by versions of the protocol equal or newer than the deprecated version unless they are used with the same meaning as in versions prior to the deprecated version.”

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception.

§9.6.6 Table 9.25 PID_TYPE_CHECKSUM (0x0008)

Spec: §9.6.6, p. 198, Table 9.25 — “PID_TYPE_CHECKSUM — 0x0008 — 2.2”.

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception.

§9.6.6 Table 9.25 PID_TYPE2_NAME (0x0009)

Spec: §9.6.6, p. 198, Table 9.25 — “PID_TYPE2_NAME — 0x0009 — 2.2”.

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception.

§9.6.6 Table 9.25 PID_TYPE2_CHECKSUM (0x000a)

Spec: §9.6.6, p. 198, Table 9.25 — “PID_TYPE2_CHECKSUM — 0x000a — 2.2”.

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception.

§9.6.6 Table 9.25 PID_EXPECTS_ACK (0x0010)

Spec: §9.6.6, p. 198, Table 9.25 — “PID_EXPECTS_ACK — 0x0010 — 2.2”.

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception.

§9.6.6 Table 9.25 PID_MANAGER_KEY (0x0012)

Spec: §9.6.6, p. 198, Table 9.25 — “PID_MANAGER_KEY — 0x0012 — 2.2”.

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception.

§9.6.6 Table 9.25 PID_SEND_QUEUE_SIZE (0x0013)

Spec: §9.6.6, p. 198, Table 9.25 — “PID_SEND_QUEUE_SIZE — 0x0013 — 2.2”.

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception (RTI sends it, vendor_discovery_frames.rs).

§9.6.6 Table 9.25 PID_RELIABILITY_ENABLED (0x0014)

Spec: §9.6.6, p. 198, Table 9.25 — “PID_RELIABILITY_ENABLED — 0x0014 — 2.2”.

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception.

§9.6.6 Table 9.25 PID_VARGAPPS_SEQUENCE_NUMBER_LAST (0x0017)

Spec: §9.6.6, p. 198, Table 9.25 — “PID_VARGAPPS_SEQUENCE_NUMBER_LAST — 0x0017 — 2.2”.

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception.

§9.6.6 Table 9.25 PID_RECV_QUEUE_SIZE (0x0018)

Spec: §9.6.6, p. 198, Table 9.25 — “PID_RECV_QUEUE_SIZE — 0x0018 — 2.2”.

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception (RTI sends it, vendor_discovery_frames.rs).

§9.6.6 Table 9.25 PID_RELIABILITY_OFFERED (0x0019)

Spec: §9.6.6, p. 198, Table 9.25 — “PID_RELIABILITY_OFFERED — 0x0019 — 2.2”.

Repo: —

Tests: —

Status: n/a (informative) — deprecated PID; ZeroDDS does not send it and passes over it on reception.

§10 Serialized Payload Representation

§10.1 Introduction

Spec: §10.1, p. 199 — “The representation of the serialized application data is not part of the RTPS protocol. The RTPS protocol does not interpret the content of the SerializedPayload.”; “the content and format of the SerializedPayload is defined in sections 10.3 to 10.5.”

Repo: —

Tests: —

§10.3 representation_options: the sender sets zero

Spec: §10.3, p. 200 — “The current version of the protocol does not use the representation_options: The sender shall set the representation_options to zero.”

Repo: crates/rtps/src/participant_data.rs (to_pl_cdr_le, to_pl_cdr_be: options 0x0000)

Tests: crates/rtps/src/participant_data.rs::tests::participant_data_first_4_bytes_are_pl_cdr_le_encapsulation

Status: done

§10.3 representation_options: the receiver ignores them

Spec: §10.3, p. 200 — “The receiver shall ignore the value of the representation_options.”

Repo: crates/rtps/src/participant_data.rs, publication_data.rs, subscription_data.rs (from_pl_cdr_le)

Tests: crates/rtps/src/subscription_data.rs::tests::the_receiver_ignores_the_representation_options, crates/rtps/src/participant_data.rs::tests::the_receiver_ignores_the_representation_options_of_a_participant, crates/rtps/src/publication_data.rs::tests::the_receiver_ignores_the_representation_options_of_a_publication

Status: done — the decoders read an announcement with representation_options ≠ 0 like one with 0; the sender writes 0.

§10.4 Other built-in endpoints use Table 10.2

Spec: §10.4, p. 200 — “The SerializedPayload for the data messages associated with built-in endpoints other than discovery built-in endpoints shall use one of the RepresentationIdentifier values and formats defined in Table 10.2 below.”

Repo: crates/rtps/src/participant_message_data.rs (to_cdr: CDR_LE or CDR_BE); crates/security/src/generic_message.rs (CDR_LE)

Tests: crates/rtps/src/participant_message_data.rs::tests::participant_message_data_roundtrip_le, crates/security-runtime/src/builtin_topics.rs::tests::encode_starts_with_cdr_le_encapsulation

Status: done — ParticipantMessageData and the messages of the DDS-Security endpoints use CDR_LE. The TypeLookup endpoints use CDR2_LE, the representation their own definition names (DDS-XTypes 1.4 Beta 1 §7.6.3.3.3), and CDR_LE under the setting xcdr1 (item “TypeLookup endpoints with CDR2_LE”).

§10.4 TypeLookup endpoints with CDR2_LE

Spec: §10.4, p. 200 — “shall use one of the RepresentationIdentifier values and formats defined in Table 10.2 below.” Table 10.2 names CDR_BE, CDR_LE, PL_CDR_BE and PL_CDR_LE.

Repo: crates/types/src/type_lookup.rs (TypeLookupEncoding, TypeLookupEncapsulation, to_payload), crates/types/src/framing.rs (EncodingVersion, encode_optional, encode_mutable), crates/dcps/src/runtime.rs (send_type_lookup_request_datagram, send_type_lookup_reply, dispatch_type_lookup_datagram, RuntimeConfig::type_lookup_encoding), crates/java-omgdds/java/src/main/java/org/zerodds/typelookup/TypeLookupService.java (Encoding, Encapsulation), .../generated/ZdCodec.java (ZdCodec.Xcdr1)

Tests: crates/types/tests/type_lookup_xcdr1.rs (eight tests, among them a_get_types_request_is_cdr_le_with_its_parameters_as_a_parameter_list and a_get_types_reply_carries_its_object_in_the_encoding_version_1), crates/dcps/tests/type_lookup_e2e.rs::{server_handles_inbound_get_types_request_via_dispatch, a_get_types_request_in_cdr_le_is_answered, the_setting_xcdr1_answers_in_cdr_le, a_request_is_written_in_the_configured_encoding}, crates/dcps/tests/typelookup_resolution_e2e.rs::a_complete_object_crosses_between_an_xcdr1_and_an_xcdr2_participant, crates/java-omgdds/java/src/test/java/org/zerodds/typelookup/TypeLookupEncodingTest.java (five tests), crates/dcps/tests/java_typelookup_live.rs (Java asks the Rust runtime and the Rust runtime asks Java, over RTPS between two processes, both with the default XCDR2)

Status: done — request and reply of the TypeLookup service go out with 00 07 (CDR2_LE) and the XCDR2 encoding by default: the FINAL envelope without a DHEADER, the appendable unions with one, the MUTABLE _In/_Out parameters with a DHEADER and an EMHEADER per member. DDS-XTypes 1.4 Beta 1 (ptc/2026-02-06) §7.6.3.3.3: “The Data Representation used by these endpoints shall be Extended CDR Representation (encoding version 2)”, the resolution of OMG issue DDSXTY14-29. §10.4 leaves the format to “the definition of each of those builtin Endpoints”, and that definition now names XCDR2; CDR2_LE is not in Table 10.2, and DDSI-RTPS 2.5 is the current version. The form of Table 10.2 is the named setting wire.type_lookup_encoding = xcdr1 (env ZERODDS_WIRE_TYPE_LOOKUP_ENCODING, zerodds.yaml(5)): 00 01 (CDR_LE) with XCDR1, the outer type without a header, the MUTABLE parameters as PL_CDR1 lists with PID_EXTENDED (0x7F01, Table 34) for the @hashid ids above 0x3F00 and PID_LIST_END (0x7F02), the @optional members of the TypeObjects behind a parameter header instead of a presence octet (XTypes 1.3 §7.4.1.1.5.2, §7.4.1.2). It is the reading of XTypes 1.3, which names no representation for these endpoints: no DataRepresentation (default XCDR, §7.6.3.1.1), an unannotated outer type is APPENDABLE (§7.3.1.2.1.8), Table 60 gives CDR_LE. A received sample is read in the encoding its identifier names (CDR_BE/CDR_LE → XCDR1, CDR2_BE/CDR2_LE → XCDR2) under either setting; any other identifier is dropped and reported as typelookup.sample.rejected. The sample ends on a four-octet boundary and the options count the padding (XTypes 1.3 §7.6.3.1.2, 38d06cac567). The Java runtime (crates/java-omgdds) has the same default and the same setting (property zerodds.wire.type_lookup_encoding or the same environment variable, 21bbd369efa); its XCDR1 codec is generated from the same unmodified IDL and writes the octets the Rust runtime writes (TypeLookupEncodingTest::aGetTypesRequestIsWrittenInTheEncodingVersion1, theRustReplyReadsAndIsWrittenBackOctetForOctet). The expected XCDR1 octets of the tests are derived from the clauses, not a vendor capture: no measured vendor sends this form. Measured (Linux test host, internal/release/evidence/rc7-typelookup-encapsulation, e954fd7cfe8), in each direction with a type the peer does not know:

Vendor	sends	reads a CDR_LE request	reads a CDR_LE reply
Cyclone DDS 11.0.1	CDR2_LE, options = padding	no (`deserialization failed`)	no (`deserialization failed`)
Fast DDS 3.6.1	CDR2_LE (replies)	yes, answers	not measured: Fast DDS asked in no cell
OpenDDS 3.34.0	CDR2_LE, options `0000`	no (`failed to deserialize type lookup request`)	no (`failed to deserialize type lookup reply`)
RTI Connext 7.7.0	CDR2_LE	no (`no deserialization program … CDR_LE`)	no (the same message)

Status: done

§10.5 Table 10.3 CDR2_BE {0x00, 0x10}

Spec: §10.5, p. 201, Table 10.3 — “CDR2_BE — {0x00, 0x10} — Plain CDR representation (version2) with Big Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — CDR2_BE: big endian, even identifier. Both sets of values are read. The default sent is DDS-XTypes 1.3 Table 60, to which the header of Table 10.3 refers and which Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 and RTI 7.7.0 send (measured in tools/wire-capture/frames/*/*.xcdr2.frames). With wire.encapsulation_ids: table-39 (environment ZERODDS_WIRE_ENCAPSULATION_IDS) ZeroDDS sends the identifiers of Table 39 (§7.4.3.4), whose XCDR2 values are those of Table 10.3 (XML: {0x01, 0x00}). Expected from the vendors: a peer that reads Table 60 only cannot read data with 0x0010 to 0x0015; the setting is for peers that send and expect Table 10.3. Not measured: a run against the vendors with the setting.

§10.5 Table 10.3 CDR2_LE {0x00, 0x11}

Spec: §10.5, p. 201, Table 10.3 — “CDR2_LE — {0x00, 0x11} — Plain CDR representation (version2) with Little Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — CDR2_LE. Both sets of values are read. The default sent is DDS-XTypes 1.3 Table 60, to which the header of Table 10.3 refers and which Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 and RTI 7.7.0 send (measured in tools/wire-capture/frames/*/*.xcdr2.frames). With wire.encapsulation_ids: table-39 (environment ZERODDS_WIRE_ENCAPSULATION_IDS) ZeroDDS sends the identifiers of Table 39 (§7.4.3.4), whose XCDR2 values are those of Table 10.3 (XML: {0x01, 0x00}). Expected from the vendors: a peer that reads Table 60 only cannot read data with 0x0010 to 0x0015; the setting is for peers that send and expect Table 10.3. Not measured: a run against the vendors with the setting.

§10.5 Table 10.3 PL_CDR2_BE {0x00, 0x12}

Spec: §10.5, p. 201, Table 10.3 — “PL_CDR2_BE — {0x00, 0x12} — Extended CDR representation (version2) for MUTABLE types with Big Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — PL_CDR2_BE. Both sets of values are read. The default sent is DDS-XTypes 1.3 Table 60, to which the header of Table 10.3 refers and which Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 and RTI 7.7.0 send (measured in tools/wire-capture/frames/*/*.xcdr2.frames). With wire.encapsulation_ids: table-39 (environment ZERODDS_WIRE_ENCAPSULATION_IDS) ZeroDDS sends the identifiers of Table 39 (§7.4.3.4), whose XCDR2 values are those of Table 10.3 (XML: {0x01, 0x00}). Expected from the vendors: a peer that reads Table 60 only cannot read data with 0x0010 to 0x0015; the setting is for peers that send and expect Table 10.3. Not measured: a run against the vendors with the setting.

§10.5 Table 10.3 PL_CDR2_LE {0x00, 0x13}

Spec: §10.5, p. 201, Table 10.3 — “PL_CDR2_LE — {0x00, 0x13} — Extended CDR representation (version2) for MUTABLE types with Little Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — PL_CDR2_LE. Both sets of values are read. The default sent is DDS-XTypes 1.3 Table 60, to which the header of Table 10.3 refers and which Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 and RTI 7.7.0 send (measured in tools/wire-capture/frames/*/*.xcdr2.frames). With wire.encapsulation_ids: table-39 (environment ZERODDS_WIRE_ENCAPSULATION_IDS) ZeroDDS sends the identifiers of Table 39 (§7.4.3.4), whose XCDR2 values are those of Table 10.3 (XML: {0x01, 0x00}). Expected from the vendors: a peer that reads Table 60 only cannot read data with 0x0010 to 0x0015; the setting is for peers that send and expect Table 10.3. Not measured: a run against the vendors with the setting.

§10.5 Table 10.3 D_CDR_BE {0x00, 0x14}

Spec: §10.5, p. 201, Table 10.3 — “D_CDR_BE — {0x00, 0x14} — Extended CDR representation (version2) for APPENDABLE types with Big Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — D_CDR_BE. Both sets of values are read. The default sent is DDS-XTypes 1.3 Table 60, to which the header of Table 10.3 refers and which Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 and RTI 7.7.0 send (measured in tools/wire-capture/frames/*/*.xcdr2.frames). With wire.encapsulation_ids: table-39 (environment ZERODDS_WIRE_ENCAPSULATION_IDS) ZeroDDS sends the identifiers of Table 39 (§7.4.3.4), whose XCDR2 values are those of Table 10.3 (XML: {0x01, 0x00}). Expected from the vendors: a peer that reads Table 60 only cannot read data with 0x0010 to 0x0015; the setting is for peers that send and expect Table 10.3. Not measured: a run against the vendors with the setting.

§10.5 Table 10.3 D_CDR_LE {0x00, 0x15}

Spec: §10.5, p. 201, Table 10.3 — “D_CDR_LE — {0x00, 0x15} — Extended CDR representation (version2) for APPENDABLE types with Little Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — D_CDR_LE. Both sets of values are read. The default sent is DDS-XTypes 1.3 Table 60, to which the header of Table 10.3 refers and which Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 and RTI 7.7.0 send (measured in tools/wire-capture/frames/*/*.xcdr2.frames). With wire.encapsulation_ids: table-39 (environment ZERODDS_WIRE_ENCAPSULATION_IDS) ZeroDDS sends the identifiers of Table 39 (§7.4.3.4), whose XCDR2 values are those of Table 10.3 (XML: {0x01, 0x00}). Expected from the vendors: a peer that reads Table 60 only cannot read data with 0x0010 to 0x0015; the setting is for peers that send and expect Table 10.3. Not measured: a run against the vendors with the setting.

§10.5 Table 10.3: identifiers 0x0010 to 0x0015

Spec: §10.5, p. 201, Table 10.3 — “CDR2_BE {0x00, 0x10}”, “CDR2_LE {0x00, 0x11}”, “PL_CDR2_BE {0x00, 0x12}”, “PL_CDR2_LE {0x00, 0x13}”, “D_CDR_BE {0x00, 0x14}”, “D_CDR_LE {0x00, 0x15}”.

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — The six identifiers 0x0010 to 0x0015 (even big endian, odd little endian). Both sets of values are read. The default sent is DDS-XTypes 1.3 Table 60, to which the header of Table 10.3 refers and which Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 and RTI 7.7.0 send (measured in tools/wire-capture/frames/*/*.xcdr2.frames). With wire.encapsulation_ids: table-39 (environment ZERODDS_WIRE_ENCAPSULATION_IDS) ZeroDDS sends the identifiers of Table 39 (§7.4.3.4), whose XCDR2 values are those of Table 10.3 (XML: {0x01, 0x00}). Expected from the vendors: a peer that reads Table 60 only cannot read data with 0x0010 to 0x0015; the setting is for peers that send and expect Table 10.3. Not measured: a run against the vendors with the setting.

§10.5 Table 10.3 XML {0x00, 0x04}

Spec: §10.5, p. 201, Table 10.3 — “XML — {0x00, 0x04} — See DDS-XTypes [3] clause 7.4.4.”

Repo: crates/dcps/src/runtime.rs (XML_ENCAP, user_payload_encap, xml_wire_body, xml_sample_as_cdr); crates/dcps/src/xml_data.rs; crates/dcps/src/publisher.rs

Tests: crates/dcps/src/runtime.rs::tests::an_xml_sample_reaches_the_reader_as_its_cdr_body, crates/dcps/src/runtime.rs::tests::an_xml_sample_that_is_no_document_of_the_type_is_refused, crates/dcps/src/runtime.rs::tests::an_xml_dispose_carries_the_instance_key, crates/dcps/src/runtime.rs::tests::an_xml_writer_sends_the_document_of_the_sample, crates/dcps/src/runtime.rs::tests::a_writer_registered_with_xml_first_is_accepted

Status: done — a writer whose first DataRepresentation is XML sends the document of the sample under {0x00, 0x04}; a reader reads the sample against its registered type and hands on the XCDR2 body. Not measured: a vendor that sends or reads XML.

§10.5 Legacy DDS implementations without DDS-XTypes

Spec: §10.5, p. 201 — “Legacy DDS implementations that are not compliant with DDS-XTYPES should minimally support the RepresentationIdentifier values CDR_BE and CDR_LE and the type system elements specified in clause F1”.

Repo: —

Tests: —

Status: n/a (informative) — addressed to implementations without DDS-XTypes; ZeroDDS supports CDR_BE and CDR_LE (§10.5 Table 10.3).

§10.6 Example for built-in endpoint data

Spec: §10.6, pp. 201–203 — “Following is the SerializedPayload element used by the SEDPbuiltinSubscriptionsWriter to declare a DataReader.” with layout and octets.

Repo: crates/rtps/src/subscription_data.rs (SubscriptionBuiltinTopicData::from_pl_cdr_le, to_pl_cdr_le)

Tests: crates/rtps/src/subscription_data.rs::tests::the_example_of_10_6_is_read, crates/rtps/src/subscription_data.rs::tests::the_parameters_of_the_example_of_10_6_are_written_as_the_spec_prints_them

Status: done — the 84 octets of the spec are read as the DataReader they describe; the encoder writes the five parameters of the example with the same octets (the spec leaves the default values out, ZeroDDS writes them in addition).

§10.7 Example for user-defined topic data

Spec: §10.7, pp. 203–204 — “Following is the SerializedPayload element used by an application DataWriter to send Data on the Topic “Square” with type “ShapeType”” with layout and octets.

Repo: crates/dcps/src/runtime.rs (user_payload_encap, strip_user_encap)

Tests: crates/dcps/src/runtime.rs::tests::the_example_of_10_7_has_the_header_and_body_of_the_spec

Status: done — the CDR_LE header ({0x00, 0x01}, options 0) and the 24-octet body of the example (“BLUE”, 34, 100, 24) are read as the spec prints them; the header for an XCDR1 final writer is the one of the spec.

Annex A References

Spec: Annex A, p. 205 — “[1] DDS-SECURITY: DDS Security version 1.1 https://www.omg.org/spec/DDS-SECURITY”.

Repo: —

Tests: —

Status: n/a (informative) — list of references.

Audit-Status

978 done / 3 partial / 15 open / 2 blocked / 127 n/a (informative).

Open items: ddsi-rtps-2.5.open.en.md.

DDSI-RTPS 2.5 — Spec-Coverage

Quelle: internal/standards/cache/omg/ddsi-rtps-2.5.pdf (206 Seiten, OMG formal/2022-04-01) — OMG DDSI-RTPS 2.5

Item-für-Item-Audit gegen die PDF nach internal/spec-coverage/PROCESS.md. Seitenangaben sind PDF-Seiten (PDF-Seite = gedruckte Seite + 6). Jede Zeile einer normativen Tabelle ist ein eigenes Item. done steht nur, wo Code und Test die Anforderung abdecken; ein Test-Zitat nennt die Testfunktion als datei::modul::name.

Kontext: Der DDSI-RTPS-2.5-Stack ist verteilt über:

crates/rtps/ · docs.rs — Header, Submessages, HeaderExtension, ParameterList, Inline-QoS, Receiver-Zustand, Writer- und Reader-Zustandsmaschinen mit ihren Proxies, HistoryCache, Fragmentierung, Discovery-Datentypen.
crates/discovery/ · docs.rs — SPDP, SEDP, TypeLookup, die sicheren Builtin-Endpoints.
crates/transport/ · docs.rs, crates/transport-udp/ — Transport-Schnittstelle und der UDP/IP-PSM (§9.5).
crates/dcps/ · docs.rs — die DDS-Seite (§8.2.10), Writer Liveliness Protocol, KeyHash, Encapsulation-Header (§10).
crates/qos/ · docs.rs — die QoS-Policies und ihr Wire-Format.

§7.1 Introduction

Spec: §7.1, S. 13 — Motivation eines DDS-Wire-Protokolls.

Repo: —

Tests: —

Status: n/a (informative) — Einführung ohne Anforderung.

§7.2 Requirements for a DDS Wire-protocol

Spec: §7.2, S. 13–14 — Anforderungen an ein DDS-Wire-Protokoll als Entwurfsziele (kein zentraler Namensdienst, keine Single Points of Failure, Erweiterbarkeit).

Repo: —

Tests: —

Status: n/a (informative) — Entwurfsziele; die daraus folgenden Mechanismen (SPDP/SEDP ohne Server, Versionierung) sind unter §8.5 und §8.6 geführt.

§7.3 The RTPS Wire-protocol

Spec: §7.3, S. 14 — Herkunft und Eigenschaften von RTPS.

Repo: —

Tests: —

Status: n/a (informative) — Beschreibung.

§7.4 The RTPS Platform Independent Model (PIM)

Spec: §7.4–§7.4.4, S. 14–17 — Gliederung des PIM in die Module Structure, Messages, Behavior und Discovery.

Repo: —

Tests: —

Status: n/a (informative) — Übersicht; die Module sind unter §8.2–§8.5 geführt.

Spec: §7.6, S. 18 — “The transport can receive a datagram at a specific address/port.”

Repo: crates/transport/src/lib.rs (Transport::recv); crates/transport-udp/src/udp_transport.rs (UdpTransport::recv, UdpTransport::bind_v4)

Status: done

§8.2.1.2 Table 8.2 InstanceHandle_t

Spec: §8.2.1.2, S. 22, Table 8.2 — “Type used to represent the identity of a data-object whose changes in value are communicated by the RTPS protocol.”

Repo: crates/rtps/src/history_cache.rs (CacheChange::key_hash); crates/dcps/src/instance_handle.rs (InstanceHandle)

Tests: crates/dcps/src/instance_handle.rs::tests::from_guid_distinguishes_keys, crates/rtps/src/history_cache.rs::tests::keep_last_per_instance_keeps_the_newest_of_each_instance

Status: done — auf RTPS-Ebene trägt der KeyHash (§9.6.4.8) die Instanz-Identität.

Spec: §8.2.2.2, S. 25 — “This operation inserts the CacheChange a_change into the HistoryCache. This operation will only fail if there are not enough resources to add the change to the HistoryCache.”

Repo: crates/rtps/src/history_cache.rs (HistoryCache::insert, HistoryCache::insert_returning_evicted, CacheError)

Status: done — insert weist zusätzlich eine bereits belegte Sequenznummer ab; nach außen nicht sichtbar, da Writer jede Nummer nur einmal vergeben.

§8.2.2.2 RESOURCE_LIMITS und Fehlerweitergabe an den DDS-Nutzer

Spec: §8.2.2.2, S. 25 — “It is the responsibility of the DDS service implementation to configure the HistoryCache in a manner consistent with the DDS Entity RESOURCE_LIMITS QoS and to propagate any errors to the DDS-user in the manner specified by the DDS specification.”

Repo: crates/dcps/src/runtime.rs (await_writer_room); crates/rtps/src/history_cache.rs (HistoryKind, HistoryCache::set_per_instance_depth)

Status: done

Spec: §8.2.3, S. 26, Table 8.5 — “kind: ChangeKind_t — Identifies the kind of change.”

Repo: crates/rtps/src/history_cache.rs (CacheChange::kind); crates/rtps/src/reliable_reader.rs (DeliveredSample::kind)

Status: done

§8.2.3 Table 8.5 CacheChange::writerGuid

Spec: §8.2.3, S. 26, Table 8.5 — “writerGuid: GUID_t — The GUID_t that identifies the RTPS Writer that made the change”.

Repo: crates/rtps/src/reliable_reader.rs (DeliveredSample::writer_guid); Writer-Seite implizit, je Writer ein eigener HistoryCache.

Status: done

Spec: §8.2.3, S. 26, Table 8.5 — “inlineQos: ParameterList — Contains QoS that may affect the interpretation of the CacheChange::data_value.”

Repo: crates/rtps/src/history_cache.rs (CacheChange::inline_qos, CacheChange::with_inline_qos); Reader-Seite: crates/rtps/src/reliable_reader.rs (DeliveredSample mit den ausgewerteten Parametern key_hash, coherent_set_sn, related_sample_identity)

Status: done

§8.2.4 Table 8.6 Entity::guid

Spec: §8.2.4, S. 26, Table 8.6 — “guid: GUID_t — Globally and uniquely identifies the RTPS Entity within the DDS domain. Maps to the value of the DDS BuiltinTopicKey_t”.

Repo: crates/rtps/src/wire_types.rs (Guid); crates/dcps/src/builtin_topics.rs (Schlüssel der Builtin-Topic-Daten)

Tests: crates/rtps/src/wire_types.rs::tests::guid_layout_is_prefix_then_entity_id, crates/dcps/src/instance_handle.rs::tests::from_guid_distinguishes_keys

Status: done

§8.2.4.1 Table 8.7 GUID = <prefix, entityId>

Spec: §8.2.4.1, S. 26–27, Table 8.7 — “The GUID is built as a tuple <prefix, entityId> combining a GuidPrefix_t prefix and an EntityId_t entityId.”

Repo: crates/rtps/src/wire_types.rs (Guid::new, Guid::to_bytes)

Tests: crates/rtps/src/wire_types.rs::tests::guid_layout_is_prefix_then_entity_id

Status: done

§8.2.4.2 Participant-GUID <prefix, ENTITYID_PARTICIPANT>

Spec: §8.2.4.2, S. 27 — “Every Participant has GUID <prefix, ENTITYID_PARTICIPANT>”.

Repo: crates/rtps/src/wire_types.rs (EntityId::PARTICIPANT); crates/dcps/src/participant.rs (random_guid_prefix)

Tests: crates/rtps/src/wire_types.rs::tests::entity_id_participant_constant, crates/dcps/src/participant.rs::tests::random_guid_prefixes_share_host_id_within_process

Status: done

§8.2.4.2 Prefix eindeutig in der Domain

Spec: §8.2.4.2, S. 27 — “The implementation is free to choose the prefix, as long as every Participant in the Domain has a unique GUID.”

Repo: crates/dcps/src/participant.rs (next_process_unique, namespaced_pid, process_unique); crates/dcps/src/runtime.rs (DcpsRuntime::prefix_collisions)

Status: done — die Prefixe der Participants eines Prozesses sind paarweise verschieden (Zähler des Prozesses, 65536 je Prozess, auch für die C-API und die Brücken); über Prozesse und Hosts hinweg verhindert die Konstruktion die Kollision (Item „Eindeutigkeit des Prefix über Hosts und Prozesse“).

§8.2.4.2 Eindeutigkeit des Prefix über Hosts und Prozesse

Spec: §8.2.4.2, S. 27 — “every Participant in the Domain has a unique GUID”.

Status: done — der Prefix besteht aus der VendorId, dem Host-Kennwert (4 Oktette), der Prozess-ID und einem Prozessanteil (Startwert aus der Zufallsquelle des Betriebssystems plus Zähler des Prozesses). Die Prozess-ID trägt die Marke des PID-Namensraums (namespaced_pid: XOR mit einer Maske aus dem Inode von /proc/self/ns/pid, im Ausgangs-Namensraum null, innerhalb eines Namensraums umkehrbar eindeutig). Container mit dem Netz des Hosts (gleicher Host-Kennwert) und eigenem PID-Namensraum, deren erster Prozess die Nummer 1 hat, tragen dadurch verschiedene Prefixe. same_process (erste zehn Oktette) und same_host (Host-Kennwert) lesen unverändert. Verbleibende Kollision: zwei verschiedene Hostnamen mit gleichem 32-Bit-Hash, gleicher markierter Prozess-ID und gleichem Prozessanteil; DcpsRuntime::prefix_collisions zählt einen SPDP-Beacon mit dem eigenen Prefix und fremden Locatoren.

§8.2.4.3 GUID einer Endpoint-Gruppe

Spec: §8.2.4.3, S. 27 — “The endpoint Groups contained by a Participant with GUID <participantPrefix, ENTITYID_PARTICIPANT> have the GUID <participantPrefix, entityId>. The entityId is the unique identification of the Group relative to the Participant.”

Tests: crates/rtps/src/publication_data.rs::tests::the_writers_group_travels_as_pid_group_guid, crates/rtps/src/wire_types.rs::tests::every_kind_table_9_1_names_decodes_to_a_named_kind

Status: done

§8.2.4.4 GUID der Endpoints eines Participants

Spec: §8.2.4.4, S. 27 — “The Endpoints contained by a Participant with GUID <participantPrefix, ENTITYID_PARTICIPANT> have the GUID <participantPrefix, entityId>. The entityId is the unique identification of the Endpoint relative to the Participant.”

Status: done — der 3-Oktett-Schlüssel kommt aus einem Zähler; nach dem Umlauf der 24 Bit wird ein Schlüssel übersprungen, den ein registrierter Writer, Reader, ein angekündigtes Topic, eine reservierte, noch nicht registrierte Id oder eine Gruppen-Id (Publisher, Subscriber) hält; ein zurückgegebener Schlüssel ist wieder frei.

§8.2.5 Table 8.8 Participant::defaultUnicastLocatorList

Spec: §8.2.5, S. 28, Table 8.8 — “Default list of unicast locators … These are the unicast locators that will be used in case the Endpoint does not specify its own set of Locators.”

Repo: crates/rtps/src/participant_data.rs (ParticipantBuiltinTopicData::default_unicast_locators)

Tests: crates/rtps/src/participant_data.rs::tests::participant_data_roundtrip_full

Status: done — der Rückgriff des Endpoints auf die Default-Locatoren ist unter §8.5.5.1 geführt.

§8.2.5 Table 8.8 Participant::defaultMulticastLocatorList

Spec: §8.2.5, S. 28, Table 8.8 — “Default list of multicast locators … used in case the Endpoint does not specify its own set of Locators.”

Repo: crates/rtps/src/participant_data.rs (ParticipantBuiltinTopicData::default_multicast_locators)

Tests: crates/rtps/src/participant_data.rs::tests::participant_data_roundtrip_full

Status: done

§8.2.5 Table 8.8 Participant::protocolVersion

Spec: §8.2.5, S. 28, Table 8.8 — “protocolVersion: ProtocolVersion_t — Identifies the version of the RTPS protocol that the Participant uses to communicate.”

Repo: crates/rtps/src/participant_data.rs (ParticipantBuiltinTopicData::protocol_version); crates/rtps/src/header.rs (RtpsHeader::new)

Tests: crates/rtps/src/header.rs::tests::header_protocol_version_at_bytes_4_5, crates/rtps/src/participant_data.rs::tests::participant_data_roundtrip_full

Status: done

§8.2.5 Table 8.8 Participant::vendorId

Spec: §8.2.5, S. 28, Table 8.8 — “vendorId: VendorId_t — Identifies the vendor of the RTPS middleware that contains the Participant.”

Repo: crates/rtps/src/participant_data.rs (ParticipantBuiltinTopicData::vendor_id); crates/rtps/src/header.rs

Tests: crates/rtps/src/header.rs::tests::header_vendor_id_at_bytes_6_7, crates/rtps/src/participant_data.rs::tests::participant_data_roundtrip_full

Status: done

Spec: §8.2.10.1, S. 32, Table 8.11 T1 — “the_rtps_writer = new RTPS::Writer; the_dds_writer.related_rtps_writer := the_rtps_writer;”

Repo: crates/dcps/src/publisher.rs (Publisher::create_datawriter); crates/dcps/src/runtime.rs (register_user_writer_as)

Status: done

§8.2.10.1 Table 8.11 DataWriter T2 (write)

Spec: §8.2.10.1, S. 32, Table 8.11 T2 — “a_change := the_rtps_writer.new_change(ALIVE, data, inlineQos, handle); the_rtps_writer.writer_cache.add_change(a_change);” Nachbedingung “the_rtps_writer.writer_cache.get_seq_num_max() == a_change.sequenceNumber”.

Repo: crates/dcps/src/publisher.rs (DataWriter::write); crates/rtps/src/reliable_writer.rs (ReliableWriter::write)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_increments_sn_and_returns_data_datagram, crates/rtps/src/reliable_writer.rs::tests::heartbeat_carries_cache_range

Status: done

§8.2.10.1 Table 8.11 DataWriter T3 (dispose, WITH_KEY)

Spec: §8.2.10.1, S. 32 — “if (the_rtps_writer.topicKind == WITH_KEY) { a_change := the_rtps_writer.new_change(NOT_ALIVE_DISPOSED, , inlineQos, handle); the_rtps_writer.writer_cache.add_change(a_change); }”

Tests: crates/dcps/tests/lifecycle_wire_e2e.rs::linux::dispose_propagates_over_wire_to_reader, crates/rtps/src/reliable_writer.rs::tests::lifecycle_with_a_key_sets_k_and_carries_it

Status: done

§8.2.10.1 Table 8.11 DataWriter T4 (unregister, WITH_KEY)

Spec: §8.2.10.1, S. 33 — “if (the_rtps_writer.topicKind == WITH_KEY) { a_change := the_rtps_writer.new_change(NOT_ALIVE_UNREGISTERED, , inlineQos, handle); the_rtps_writer.writer_cache.add_change(a_change); }”

Repo: crates/dcps/src/publisher.rs (DataWriter::unregister_instance_w_timestamp); crates/dcps/src/runtime.rs (write_user_lifecycle)

Status: done

§8.2.10.1 T3/T4 ohne Wirkung bei NO_KEY

Spec: §8.2.10.1, S. 32–33 — dispose und unregister: “This operation has no effect if the topicKind==NO_KEY.”

Repo: crates/dcps/src/runtime.rs (write_user_lifecycle_with, keyless_lifecycle_not_sent); writer.keyless_lifecycle_on_wire

Status: done — dispose und unregister eines Writers ohne Schlüssel erzeugen keinen Change und senden keinen Marker (gezählt in DcpsRuntime::keyless_lifecycle_not_sent); der Instanzzustand des Writers selbst ändert sich (DDS 1.4 §2.2.1.2.2: eine Instanz). writer.keyless_lifecycle_on_wire (Umgebung ZERODDS_WRITER_KEYLESS_LIFECYCLE_ON_WIRE) sendet den Marker (nur Status-Bits) für einen Peer, der ihn erwartet. Erwartet bei den Herstellern: Reader von Topics ohne Schlüssel sehen kein NOT_ALIVE_DISPOSED der ZeroDDS-Writer mehr; ob Cyclone DDS, Fast DDS oder OpenDDS selbst einen Marker für NO_KEY senden, ist nicht gemessen.

§8.2.10.1 Table 8.11 DataWriter T5 (delete DDS DataWriter)

Spec: §8.2.10.1, S. 33 — “delete the_dds_writer.related_rtps_writer;”

Repo: crates/dcps/src/publisher.rs (Publisher::delete_datawriter)

Tests: crates/dcps/tests/entity_deletion.rs::delete_datawriter_deletes_the_writer_behind_every_handle, crates/dcps/tests/entity_deletion.rs::the_last_handle_deletes_the_writer

Status: done

§8.2.10.2 DataReader: read und take greifen auf den HistoryCache zu

Spec: §8.2.10.2, S. 33 — “The changes returned to the user are those in the HistoryCache that pass all Reader specific filters, if any.”

Repo: crates/dcps/src/subscriber.rs (DataReader::read, DataReader::take)

Tests: crates/dcps/tests/sample_info_lifecycle.rs::reader_take_filtered_with_state_mask_filters

Status: done

§8.2.10.2 Table 8.12 DataReader T1 (new DDS DataReader)

Spec: §8.2.10.2, S. 34, Table 8.12 T1 — “the_rtps_reader = new RTPS::Reader; the_dds_reader.related_rtps_reader := the_rtps_reader;”

Repo: crates/dcps/src/subscriber.rs (Subscriber::create_datareader); crates/dcps/src/runtime.rs (register_user_reader)

Tests: crates/dcps/tests/entity_lifecycle.rs::datawriter_and_datareader_follow_their_factories_entity_factory_policy

Status: done

§8.2.10.2 Table 8.12 DataReader T2 (read)

Repo: crates/rtps/src/submessage_header.rs (SubmessageId); crates/rtps/src/header_extension.rs (SUBMESSAGE_ID_HEADER_EXTENSION)

Status: done

§8.3.2 Table 8.13 Time_t

Spec: §8.3.2, S. 36, Table 8.13 — “Type used to hold a timestamp. Should have at least nano-second resolution. The following values are reserved by the protocol: TIME_ZERO, TIME_INVALID, TIME_INFINITE”.

Repo: crates/rtps/src/header_extension.rs (HeTimestamp, TIME_INVALID, TIME_INFINITE); crates/dcps/src/time.rs

Tests: crates/rtps/src/submessages.rs::validity_tests::time_t_seconds_are_unsigned, crates/dcps/src/time.rs::tests::the_reserved_time_t_values_cross_the_wire_as_the_spec_gives_them

Status: done — seconds ist vorzeichenlos (u32, §9.3.2.1), die drei reservierten Werte TIME_ZERO, TIME_INVALID und TIME_INFINITE sind Konstanten und gehen mit den Werten der Spec auf die Leitung. Das DCPS-Time zählt Sekunden als long; die Oktette sind dieselben.

§8.3.2 Table 8.13 Count_t

Spec: §8.3.2, S. 36, Table 8.13 — “Type used to hold a count that is incremented monotonically, used to identify message duplicates.”

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::count, AckNackSubmessage::count, HeartbeatFragSubmessage::count, NackFragSubmessage::count, jeweils i32)

Tests: crates/rtps/src/reliable_writer.rs::tests::heartbeat_count_increments, crates/rtps/src/reliable_writer.rs::tests::heartbeat_count_wraps_around_at_i32_max_per_spec_8_4_15_7

Status: done — die Auswertung des Zählers beim Empfänger ist unter §8.3.8.1, §8.3.8.6 und §8.4.15.7 geführt.

§8.3.2 Table 8.13 Checksum_t

Spec: §8.3.2, S. 36, Table 8.13 — “Type used to hold a checksum. Used to detect RTPS message corruption by the underlying transport. The following values are reserved by the protocol: CHECKSUM_INVALID.”

Spec: §8.3.3.2, S. 39 — “versions of the protocol that do not understand the HeaderExtension will treat it as ‘unknown messge kind’, skip it, and continue processing the submessages that follow it”.

Repo: crates/rtps/src/datagram.rs (decode_datagram)

Tests: crates/rtps/src/datagram.rs::tests::rtps_2_1_treats_0x80_as_vendor_specific_not_header_extension

Status: n/a (informative) — beschreibt das Verhalten älterer Implementierungen; für ZeroDDS selbst gilt §8.3.4.1.

Spec: §8.3.3.2, S. 39, Table 8.15 — “ParametersFlag … Indicates the parameters field is present.”

Repo: crates/rtps/src/header_extension.rs (HE_FLAG_P)

Tests: crates/rtps/src/header_extension.rs::tests::roundtrip_with_parameter_list, crates/rtps/src/datagram.rs::tests::decode_data_after_header_extension

Status: done

§8.3.3.2 Table 8.15 HE messageLength

Spec: §8.3.3.2, S. 39–40 — “The messageLength indicates the length of the complete RTPS Message, starting from the beginning of the RTPS Header.”

Status: done — der Decoder weist ein messageLength ab, das kleiner ist als Header und HeaderExtension, und eines, das von der Länge der empfangenen Nachricht ab dem RTPS-Header abweicht. Eine Nachricht, die der Empfänger nach dem Öffnen geschützter Submessages neu zusammensetzt, wird wie empfangen geprüft und bekommt dann die HeaderExtension mit ihrer eigenen Länge und ohne Prüfsumme (restate_for_rebuilt_message); unverändert wurde jede geöffnete Nachricht von CoreDX 6.14.1 abgewiesen, das ein messageLength sendet, ihre Krypto-Tokens eingeschlossen (OMG dds-security, Linux-Testhost).

§8.3.3.2 Table 8.15 HE rtpsSendTimestamp

Spec: §8.3.3.2, S. 40 — “The rtpsSendTimestamp indicates the time when the RTPS message was sent by the originating Participant. … shall collected as close as possible to the moment when the RTPS Message is sent … The time origin … shall be the same as the one used in the Timestamp Submessage Element”.

Repo: crates/rtps/src/header_extension.rs, crates/rtps/src/receiver_state.rs (apply_header_extension)

Status: done — Feld kodiert und gelesen; beim Empfang setzt es Receiver.rtpsSendTimestamp (§8.3.7.4), nicht den Quellzeitstempel. ZeroDDS sendet keine HeaderExtension (sie ist optional, §8.3.3.2); die Vorgabe für den Erfassungszeitpunkt gilt für einen Sender, der sie schreibt.

§8.3.3.2 Table 8.15 HE uExtension4

Spec: §8.3.3.2, S. 40 — “The uExtension4 is undefined in this version of the protocol.”

Repo: crates/rtps/src/header_extension.rs (HeaderExtension::uextension4)

Tests: crates/rtps/src/header_extension.rs::tests::roundtrip_with_uextension4_be, crates/rtps/src/datagram.rs::tests::decode_data_after_header_extension

Status: done

§8.3.3.2 Table 8.15 HE wExtension8

Spec: §8.3.3.2, S. 40 — “The wExtension8 is undefined in this version of the protocol.”

Repo: crates/rtps/src/header_extension.rs (HeaderExtension::wextension8)

Tests: crates/rtps/src/header_extension.rs::tests::roundtrip_with_wextension8_le, crates/rtps/src/datagram.rs::tests::decode_data_after_header_extension

Status: done

§8.3.3.2 Table 8.15 HE messageChecksum

Spec: §8.3.3.2, S. 40 — “The messageChecksum provides a checksum computed over the complete of the RTPS Message, which includes the RTPS Header, the HeaderExtension, and all Submessages that may follow.”

Status: done — die Prüfsumme der ganzen Nachricht mit genulltem Feld wird berechnet (seal_message) und beim Empfang geprüft; ein Fehler verwirft die Nachricht und wird gezählt (refused_messages). Einen Sendepfad, der eine HeaderExtension mit Prüfsumme schreibt, gibt es in der Runtime nicht.

Spec: §8.3.3.3, S. 42 — “In case submessageLength==0, the Submessage is the last Submessage in the Message and extends up to the end of the Message.”

Repo: crates/rtps/src/datagram.rs (decode_datagram, SubmessageFrame::octets_elided, encode_datagram)

Status: done — die Ausnahme für PAD und INFO_TS steht in §9.4.5.1.3.

§8.3.3.3 Submessage-Struktur in Version 2 unveränderlich

Spec: §8.3.3.3, S. 41 — “The structure of the RTPS Submessage cannot be changed in this major version (2) of the protocol.”

Repo: crates/rtps/src/submessage_header.rs (SubmessageHeader::WIRE_SIZE = 4)

Tests: crates/rtps/src/submessage_header.rs::tests::submessage_header_layout_be

Status: done

§8.3.4 Receiver-Zustand je Nachricht zurückgesetzt

Spec: §8.3.4, S. 42 — “This state is modeled as the state of an RTPS Receiver that is reset each time a new message is processed and provides context for the interpretation of each Submessage.”

Repo: crates/rtps/src/datagram.rs (ParsedDatagram::receiver_walk legt je Datagramm einen neuen ReceiverState an)

Tests: crates/rtps/src/datagram.rs::tests::receiver_walk_attributes_submessages_after_info_source_to_the_new_prefix

Status: done

§8.3.4 Table 8.17 Anfangswert sourceVersion

Spec: §8.3.4, S. 43, Table 8.17 — “sourceVersion: PROTOCOLVERSION”.

Repo: crates/rtps/src/receiver_state.rs (ReceiverState::new, source_version)

Tests: crates/rtps/src/receiver_state.rs::tests::the_initial_source_values_and_parameters_are_those_of_table_8_17

Status: done — Anfangswert PROTOCOLVERSION (2.5).

§8.3.4 Table 8.17 Anfangswert sourceVendorId

Spec: §8.3.4, S. 43, Table 8.17 — “sourceVendorId: VENDORID_UNKNOWN”.

Repo: crates/rtps/src/receiver_state.rs (ReceiverState::new, source_vendor_id)

Tests: crates/rtps/src/receiver_state.rs::tests::the_initial_source_values_and_parameters_are_those_of_table_8_17

Status: done — Anfangswert VENDORID_UNKNOWN.

§8.3.4 Table 8.17 Anfangswert sourceGuidPrefix

Spec: §8.3.4, S. 43, Table 8.17 — “sourceGuidPrefix: GUIDPREFIX_UNKNOWN”.

Repo: crates/rtps/src/receiver_state.rs (ReceiverState::new, source_guid_prefix)

Tests: crates/rtps/src/receiver_state.rs::tests::the_initial_source_values_and_parameters_are_those_of_table_8_17

Status: done — Anfangswert GUIDPREFIX_UNKNOWN.

§8.3.4 Table 8.17 Anfangswert destGuidPrefix

Spec: §8.3.4, S. 43, Table 8.17 — “destGuidPrefix: GUID prefix of the participant receiving the message”.

Repo: crates/rtps/src/receiver_state.rs (ReceiverState::new); crates/rtps/src/datagram.rs (ParsedDatagram::receiver_walk)

Tests: crates/rtps/src/receiver_state.rs::tests::new_state_has_default_fields, crates/rtps/src/datagram.rs::tests::receiver_walk_without_info_source_attributes_to_header_prefix

Status: done

§8.3.4 Table 8.17 Anfangswert unicastReplyLocatorList

Spec: §8.3.4, S. 43, Table 8.17 — “The list is initialized to contain a single Locator_t with the LocatorKind, Address, and Port fields specified below: The LocatorKind is set to the kind that identifies the transport that received the message … The Address is set to the Address of the source of the message … The port is set to LOCATOR_PORT_INVALID.”

Spec: §8.3.4.1, S. 43 — “The submessageLength field defines where the next Submessage starts … If this field is invalid, the rest of the Message is invalid.”

Repo: crates/rtps/src/datagram.rs (decode_datagram: body_end > bytes.len() ergibt UnexpectedEof)

Tests: crates/rtps/src/datagram.rs::tests::a_submessage_length_past_the_end_invalidates_the_rest, crates/rtps/tests/fuzz_smoke.rs::fuzz_decode_datagram_does_not_panic

Status: done — wie Regel 1: der Rest wird verworfen, die vorangehenden Submessages bleiben.

§8.3.4.1 Regel 3: unbekannte SubmessageId ignorieren

Spec: §8.3.4.1, S. 43 — “A Submessage with an unknown SubmessageId must be ignored and parsing must continue with the next Submessage. … SubmessageIds in the vendor-specific range coming from a vendorId that is unknown must also be ignored”.

Repo: crates/rtps/src/datagram.rs (decode_datagram, ParsedSubmessage::Unknown)

Status: done

§8.3.4.1 Regel 3: kein Must-Understand auf Submessage-Ebene

Spec: §8.3.4.1, S. 43–44 — Regeln 3 und 4: unbekannte Submessages und unbekannte Flags werden ignoriert; RTPS 2.5 kennt ein Must-Understand nur je ParameterId (Table 9.6, S. 165).

Repo: crates/rtps/src/datagram.rs (decode_datagram, ParsedSubmessage::Unknown)

Tests: crates/rtps/src/datagram.rs::tests::decode_skips_an_unknown_submessage_whatever_its_flags

Status: done — eine unbekannte Submessage wird übersprungen, gleich welche Flags sie trägt.

§8.3.4.1 Regel 4: unbekannte Flags ignorieren

Spec: §8.3.4.1, S. 44 — “The receiver of a Submessage should ignore unknown flags. An implementation of RTPS 2.5 should skip all flags that are marked as ‘X’ (unused) in the protocol.”

Repo: crates/rtps/src/datagram.rs (decode_datagram)

Tests: crates/rtps/src/datagram.rs::tests::unknown_flags_of_a_known_submessage_are_ignored, crates/rtps/src/datagram.rs::tests::decode_skips_an_unknown_submessage_whatever_its_flags

Status: done — bei bekannten Submessages ändern die oberen drei Flag-Bits, die keine Submessage definiert, nichts am Gelesenen; eine unbekannte Submessage wird übersprungen, gleich welche Flags sie trägt.

§8.3.4.1 Regel 5: submessageLength auch bei bekannten Kennungen

Spec: §8.3.4.1, S. 44 — “A valid submessageLength field must always be used to find the next Submessage, even for Submessages with known IDs.”

Repo: crates/rtps/src/datagram.rs (decode_datagram: pos = body_end für jede Submessage)

Tests: crates/rtps/src/datagram.rs::tests::pad_submessage_is_skipped_and_the_data_behind_it_still_decodes, crates/rtps/tests/vendor_frames.rs::rti_datagrams_re_encode_byte_for_byte

Status: done

§8.3.4.1 Regel 6: bekannte, ungültige Submessage

Spec: §8.3.4.1, S. 44 — “A known but invalid Submessage invalidates the rest of the Message.”

Repo: crates/rtps/src/datagram.rs (decode_datagram, ParsedDatagram::invalid_rest)

Status: done — eine Submessage, die ihr Decoder nicht lesen kann oder deren „Validity“-Bedingung (§8.3.8) verletzt ist, macht den Rest der Nachricht ungültig; die Submessages davor bleiben (invalid_rest, gezählt). Die eine Bedingung, die der Definition von currentGSN widerspricht, steht unter §8.3.8.6 „Heartbeat ungültig: Group-Felder“.

§8.3.4.1 Gültige Submessages vor einer ungültigen

Spec: §8.3.4.1, S. 43–44 — Regeln 1, 2 und 6 erklären nur „the rest of the Message“ für ungültig.

Repo: crates/rtps/src/datagram.rs (decode_datagram, ParsedDatagram::invalid_rest)

Tests: crates/rtps/src/datagram.rs::tests::the_submessages_before_an_invalid_one_stand, crates/rtps/src/datagram.rs::tests::a_submessage_length_past_the_end_invalidates_the_rest

Status: done — decode_datagram liefert die gültig gelesenen Submessages vor einer ungültigen und vermerkt den Fehler in invalid_rest; die Empfangspfade verarbeiten sie.

Spec: §8.3.5.5, S. 46 — “a valid SequenceNumberSet must verify that: maximum(SequenceNumberSet) - minimum(SequenceNumberSet) < 256, minimum(SequenceNumberSet) >= 1”.

Repo: crates/rtps/src/submessages.rs (SequenceNumberSet::read_from: numBits <= 256, bitmapBase >= 1; from_missing kappt das Fenster bei 256)

Status: done — die Spannweite ist auf 256 begrenzt, minimum >= 1 prüft der Decoder. Vendor-Form: OpenDDS 3.34.0 und RTI Connext 7.7.0 senden als ACKNACK eines Readers ohne Samples readerSNState 0/0: (bitmapBase 0, numBits 0; gemessen in tools/wire-capture/rtps-sessions: 40 und 8 ACKNACK). Standard: ungültig. Die Einstellung wire.accept_empty_acknack_base_zero (Env ZERODDS_WIRE_ACCEPT_EMPTY_ACKNACK_BASE_ZERO, Standard false) nimmt genau diese leere Menge in einem ACKNACK an, prozessweit.

§8.3.5.6 Table 8.24 FragmentNumber

Spec: §8.3.5.6, S. 46 — “A fragment number is a 32-bit unsigned integer … Fragment numbers start at 1.”

Repo: crates/rtps/src/wire_types.rs (FragmentNumber(u32)); crates/rtps/src/reliable_writer.rs (Fragmentierung ab Nummer 1)

Tests: crates/rtps/src/wire_types.rs::tests::fragment_number_roundtrip_le_be, crates/rtps/src/reliable_writer.rs::tests::write_above_fragment_size_packs_the_fragments_a_message_carries

Status: done

§8.3.5.7 Table 8.25 FragmentNumberSet

Spec: §8.3.5.7, S. 46, Table 8.25 — “base: FragmentNumber_t … set: FragmentNumber_t[*] — A set of fragment numbers, each verifying that: base <= element(set) <= base+255”. Gültig nur mit “maximum - minimum < 256, minimum >= 1”.

Repo: crates/rtps/src/submessages.rs (FragmentNumberSet, from_missing, read_from)

Status: done — Spannweite auf 256 begrenzt, bitmapBase >= 1 wird geprüft.

§8.3.5.8 Table 8.26 Timestamp

Spec: §8.3.5.8, S. 47 — “Timestamp is used to represent time. The representation should be capable of having a resolution of nano-seconds or better.” Sonderwerte TIME_ZERO, TIME_INVALID, TIME_INFINITE.

Repo: crates/rtps/src/header_extension.rs (HeTimestamp); crates/rtps/src/submessages.rs (InfoTimestampSubmessage); crates/dcps/src/time.rs

Status: done — Auflösung 2⁻³² s, vorzeichenlose Sekunden, TIME_INVALID und TIME_INFINITE als Konstanten.

Spec: §8.3.5.9, S. 47 — “A range of 2^15 values is reserved for vendor-defined parameters.”

Repo: crates/rtps/src/parameter_list.rs (VENDOR_SPECIFIC_BIT, pid::SHM_LOCATOR, pid::ZERODDS_TYPE_ID)

Status: done

§8.3.5.9 Parameterlänge höchstens 2^16 Oktette

Spec: §8.3.5.9, S. 47 — “The maximum length of any parameter is limited to 2^16 octets.”

Repo: crates/rtps/src/parameter_list.rs (length als u16)

Tests: crates/rtps/tests/user_data_propagation.rs::user_data_large_payload_32kib

Status: done

§8.3.5.10 Table 8.29 Count

Spec: §8.3.5.10, S. 47–48 — “Count is used by several Submessages and enables a receiver to detect duplicates of the same Submessage.”

Repo: crates/rtps/src/submessages.rs (count-Felder)

Tests: crates/rtps/src/reliable_writer.rs::tests::heartbeat_count_increments

Status: done — das Element ist vorhanden; die Auswertung beim Empfänger ist unter §8.3.8.1 und §8.3.8.6 geführt.

§8.3.5.11 Table 8.30 ChangeCount

Spec: §8.3.5.11, S. 48 — “ChangeCount is used in the Gap Submessage and enables the sender to indicate the number of changes within the Gap that belong to a certain category.”

Repo: crates/rtps/src/submessages.rs (GapSubmessage::filtered_count)

Tests: crates/rtps/src/submessages.rs::tests::gap_filtered_count_is_eight_octets_high_then_low, crates/rtps/src/submessages.rs::tests::gap_with_filtered_count_roundtrip_le

Status: done — in der GAP-Submessage 64 Bit (acht Oktette, high und low).

Repo: crates/rtps/src/header_extension.rs (HeaderExtension::decode_body)

Status: done

§8.3.7.3 HE ungültig: messageLength zu klein

Spec: §8.3.7.3, S. 51 — “The messageLength is too small to fit the RTPS Header and the HeaderExtension.”

Repo: crates/rtps/src/datagram.rs (decode_datagram)

Tests: crates/rtps/src/datagram.rs::tests::a_header_extension_message_length_too_small_for_header_and_extension_is_invalid

Status: done — ein messageLength unter Header und HeaderExtension (28 Oktette) macht die Nachricht ungültig.

§8.3.7.3 HE ungültig: parameters fehlerhaft

Spec: §8.3.7.3, S. 51 — “The parameters are malformed.”

Repo: crates/rtps/src/header_extension.rs (HeaderExtension::decode_body über ParameterList::from_bytes)

Tests: crates/rtps/src/header_extension.rs::tests::decode_rejects_malformed_parameter_list_when_p_flag_set, crates/rtps/src/datagram.rs::tests::decode_data_after_header_extension

Status: done

§8.3.7.4 LengthFlag: Receiver.messageLength

Spec: §8.3.7.4, S. 51 — “IF ( LengthFlag ) { Receiver.messageLength = HeaderExtension.messageLength }”.

Repo: crates/rtps/src/receiver_state.rs (ReceiverState::apply_header_extension)

Tests: crates/rtps/src/receiver_state.rs::tests::apply_header_extension_updates_fields, crates/rtps/src/datagram.rs::tests::decode_data_after_header_extension

Spec: §8.3.7.5, S. 51 — “The rtpsSendTimestamp represents the time the RTPS message was sent. It is measured using the clock of the sending Participant. The rtpsReceptionTimestamp represents the time when the RTPS message was received.”

Repo: —

Tests: —

Status: n/a (informative) — Begriffsbestimmung; die Zuweisungen sind unter §8.3.7.4 TimestampFlag geführt.

§8.3.7.5 CLOCK_SKEW_DETECTED

Spec: §8.3.7.5, S. 51–52 — “The function CLOCK_SKEW_DETECTED() represents an implementation-specific function used to determine whether the sending and receiving participant clocks are not synchronized or have too large a skew.”

Repo: crates/rtps/src/receiver_state.rs (note_reception, note_clock_skew); crates/dcps/src/runtime.rs (receive_context, wire.clock_skew_threshold_s)

Status: done — die Spec nennt die Funktion implementierungsspezifisch; ZeroDDS vergleicht Empfangs- und Sendezeit gegen die Schwelle wire.clock_skew_threshold_s (Vorgabe 0 = aus, keine Vorgabeschwelle).

§8.3.7.5 messageChecksum mit genulltem Prüfsummenfeld

Spec: §8.3.7.5, S. 52 — “It shall be computed over the entire RTPS Message. For the purpose of computing the checksum, the value of the messageChecksum field in the RTPS HeaderExtension shall be set to zero.”

Status: done — message_checksum rechnet über die ganze Nachricht mit genulltem Feld.

§8.3.7.5 uExtension4, wExtension8, parameters ohne Bedeutung

Spec: §8.3.7.5, S. 52 — “The uExtension4 and wExtension8 may be useful to communicate additional data on the header in a future version … This version of the specification does not define any parameters in the HeaderExtension.”

Repo: —

Tests: —

Status: n/a (informative) — keine Anforderung an diese Version.

§8.3.8 Entity- und Interpreter-Submessages

Spec: §8.3.8, S. 52–53, Table 8.39 — Einteilung in Entity-Submessages (Data, DataFrag, Heartbeat, HeartbeatFrag, Gap, AckNack, NackFrag) und Interpreter-Submessages (HeaderExtension, InfoSource, InfoDestination, InfoReply, InfoTimestamp, Pad); Gliederung jeder Beschreibung.

Repo: —

Tests: —

Status: n/a (informative) — Übersicht; die Submessages sind unter §8.3.8.1–§8.3.8.13 einzeln geführt.

§8.3.8.1 AckNack: Purpose

Spec: §8.3.8.1, S. 54 — “This Submessage is used to communicate the state of a Reader to a Writer. … This Submessage can be used to do both positive and negative acknowledgments.”

Repo: —

Tests: —

Status: n/a (informative) — Zweckangabe; die Inhalte folgen.

§8.3.8.1 Table 8.40 AckNack EndiannessFlag

Spec: §8.3.8.1, S. 54, Table 8.40 — “EndiannessFlag … Indicates endianness.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::write_body, AckNackSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::tests::acknack_submessage_roundtrip_le, crates/rtps/tests/vendor_frames.rs::fastdds_datagrams_re_encode_byte_for_byte

Status: done

§8.3.8.1 Table 8.40 AckNack FinalFlag

Spec: §8.3.8.1, S. 54, Table 8.40 — “FinalFlag … Indicates to the Writer whether a response is mandatory.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::final_flag, ACKNACK_FLAG_FINAL); crates/rtps/src/reliable_reader.rs (build_acknack_datagram)

Tests: crates/rtps/src/submessages.rs::tests::acknack_submessage_with_final_flag, crates/rtps/src/datagram.rs::tests::decode_acknack_preserves_final_flag

Status: done — die Antwortpflicht des Writers ist unter §9.4.5.3 geführt.

§8.3.8.1 Table 8.40 AckNack readerId

Spec: §8.3.8.1, S. 54, Table 8.40 — “readerId: EntityId — Identifies the Reader entity that acknowledges receipt of certain sequence numbers and/or requests to receive certain sequence numbers.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::reader_id)

Tests: crates/rtps/src/submessages.rs::tests::acknack_submessage_roundtrip_le

Status: done

§8.3.8.1 Table 8.40 AckNack writerId

Spec: §8.3.8.1, S. 54, Table 8.40 — “writerId: EntityId — Identifies the Writer entity that is the target of the AckNack message.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::writer_id); crates/dcps/src/runtime.rs (handle_user_datagram_from: rt.writer_slot(ack.writer_id))

Tests: crates/rtps/src/submessages.rs::tests::acknack_submessage_roundtrip_le, crates/rtps/src/reliable_writer.rs::tests::acknack_dispatches_to_matching_proxy_only

Status: done

§8.3.8.1 Table 8.40 AckNack readerSNState

Spec: §8.3.8.1, S. 54, Table 8.40 — “All sequence numbers up to the one prior to readerSNState.base are confirmed as received by the reader. The sequence numbers that appear in the set indicate missing sequence numbers on the reader side.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::reader_sn_state); crates/rtps/src/reliable_writer.rs (handle_acknack_set_at)

Tests: crates/rtps/src/reliable_writer.rs::tests::handle_acknack_updates_proxy_state, crates/rtps/src/reliable_writer.rs::tests::handle_acknack_with_lower_base_leaves_requested

Status: done

§8.3.8.1 Table 8.40 AckNack count

Spec: §8.3.8.1, S. 54, Table 8.40 — “count: Count — A counter that is incremented each time a new AckNack message is sent.”

Repo: crates/rtps/src/reliable_reader.rs (build_acknack_datagram)

Tests: crates/rtps/src/reliable_reader.rs::tests::the_counts_of_acknack_and_nack_frag_rise_with_each_message

Status: done — aufeinanderfolgende ACKNACKs tragen die Zähler 1, 2, 3.

§8.3.8.1 AckNack ungültig: submessageLength zu klein

Spec: §8.3.8.1, S. 54 — “submessageLength in the Submessage header is too small.”

Repo: crates/rtps/src/submessages.rs (AckNackSubmessage::read_body)

Status: done — die Kürzung wird erkannt; die Submessage ist ungültig und mit ihr der Rest der Nachricht, die Submessages davor bleiben (ParsedDatagram::invalid_rest, gezählt).

Spec: §8.3.8.2, S. 55, Table 8.41 — “EndiannessFlag … Indicates endianness.”

Repo: crates/rtps/src/submessages.rs (DataSubmessage::write_body, DataSubmessage::read_body_with_flags)

Tests: crates/rtps/src/submessages.rs::tests::data_submessage_roundtrip_be_with_empty_payload, crates/rtps/src/submessages.rs::tests::data_submessage_roundtrip_le

Status: done

Spec: §8.3.8.2, S. 56 — “If the KeyFlag is set and the DataFlag is not set, the serializedPayload element is interpreted as the value of the key that identifies the registered instance of the data-object.”

Repo: crates/rtps/src/reliable_reader.rs (handle_data_into: schlüsselinhaltige DATA ohne Lebenszyklus als Registrierung)

Tests: crates/rtps/src/reliable_reader.rs::tests::key_only_alive_registration_is_acked_but_not_delivered, crates/rtps/src/reliable_reader.rs::tests::dispose_data_yields_not_alive_disposed

Status: done

§8.3.8.2 Data: Inline-QoS überschreibt die Writer-QoS

Spec: §8.3.8.2, S. 56 — “If the InlineQosFlag is set, the inlineQos element contains QoS values that override those of the RTPS Writer and should be used to process the update. For a complete list of possible in-line QoS parameters, see Table 8.85.”

Status: done — OWNERSHIP_STRENGTH und LIFESPAN, die ein DATA in-line trägt, gelten für diese Probe statt der angekündigten Werte des Writers. Die übrigen Policies von Table 8.85 wirken nicht auf eine einzelne Probe (sie gehen in den Abgleich beim Match ein: DURABILITY, RELIABILITY, PRESENTATION, PARTITION, DEADLINE, LATENCY_BUDGET, DESTINATION_ORDER, LIVELINESS), TRANSPORT_PRIORITY ist Sache des Senders.

§8.3.8.2 Data: NonStandardPayloadFlag nur informativ

Spec: §8.3.8.2, S. 56 — “This flag is informational. It indicates that the SerializedPayload has been transformed as described in another specification. For example, this flag should be set when the SerializedPayload is transformed as described in the DDS-Security specification.”

Repo: crates/rtps/src/submessages.rs (DataSubmessage::non_standard_flag wird gelesen, nicht interpretiert)

Tests: crates/rtps/src/submessages.rs::tests::data_submessage_non_standard_flag_roundtrip

Status: done — ob ZeroDDS das Flag bei DDS-Security-transformierten Nutzdaten setzt, ist nicht geprüft.

Spec: §8.3.8.3, S. 58, Table 8.42 — “A consecutive series of fragments, starting at fragmentStartingNum for a total of fragmentsInSubmessage. … If the KeyFlag is set, then it contains a consecutive set of fragments of the key”.

Repo: crates/rtps/src/submessages.rs (DataFragSubmessage::serialized_payload); crates/rtps/src/fragment_assembler.rs (FragmentAssembler::insert)

Tests: crates/rtps/src/fragment_assembler.rs::tests::fragments_complete_out_of_order, crates/rtps/src/fragment_assembler.rs::tests::last_fragment_shorter_than_fragment_size

Status: done

§8.3.8.3 DataFrag ungültig: submessageLength zu klein

Spec: §8.3.8.3, S. 58 — “submessageLength in the Submessage header is too small.”

Repo: crates/rtps/src/submessages.rs (DataFragSubmessage::read_body)

Status: done — die Kürzung wird erkannt; die Submessage ist ungültig und mit ihr der Rest der Nachricht, die Submessages davor bleiben (ParsedDatagram::invalid_rest, gezählt).

§8.3.8.3 DataFrag ungültig: writerSN ≤ 0 oder SEQUENCENUMBER_UNKNOWN

Spec: §8.3.8.3, S. 58 — “writerSN.value is not strictly positive (1, 2, …) or is SEQUENCENUMBER_UNKNOWN.”

Repo: crates/rtps/src/submessages.rs (DataFragSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::data_frag_validity_rules

Status: done — wie bei DATA.

§8.3.8.3 DataFrag ungültig: fragmentStartingNum außerhalb

Spec: §8.3.8.3, S. 58 — “fragmentStartingNum.value is not strictly positive (1, 2, …) or exceeds the total number of fragments”.

Repo: crates/rtps/src/submessages.rs (DataFragSubmessage::read_body); crates/rtps/src/fragment_assembler.rs (FragmentAssembler::insert: FragmentIndexZero, FragmentIndexOutOfRange)

Status: done — fragmentStartingNum unter 1 oder über der Zahl der Fragmente (dataSize / fragmentSize, aufgerundet) macht die Submessage und den Rest der Nachricht ungültig.

§8.3.8.3 DataFrag ungültig: fragmentSize > dataSize

Spec: §8.3.8.3, S. 58 — “fragmentSize exceeds dataSize.”

Repo: crates/rtps/src/submessages.rs (DataFragSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::data_frag_validity_rules

Status: done — fragmentSize über dataSize und fragmentSize 0 werden abgewiesen.

§8.3.8.3 DataFrag ungültig: serializedData zu groß

Spec: §8.3.8.3, S. 58 — “The size of serializedData exceeds fragmentsInSubmessage * fragmentSize.”

Repo: crates/rtps/src/submessages.rs (DataFragSubmessage::read_body); crates/rtps/src/fragment_assembler.rs (FragmentAssembler::insert: PayloadSizeMismatch)

Status: done — mehr Oktette als fragmentsInSubmessage * fragmentSize machen die Submessage ungültig. Das letzte Fragment des Samples ist so lang, wie das Sample es lässt, auf 4 Oktette aufgerundet: Cyclone DDS und Fast DDS füllen es auf die Ausrichtung der Submessage auf (72 Oktette für 71, gemessen).

§8.3.8.3 DataFrag ungültig: inlineQos ungültig

Spec: §8.3.8.3, S. 58 — “inlineQos is invalid.”

Repo: crates/rtps/src/submessages.rs (DataFragSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::data_frag_with_an_invalid_inline_qos_is_invalid

Status: done — eine Parameterliste, die über den Rumpf hinausläuft oder keinen Sentinel hat, macht die Submessage ungültig.

§8.3.8.3 DataFrag: Zusammensetzen, Offset und Fragmentanzahl

Spec: §8.3.8.3, S. 58–59 — Offset “(fragmentStartingNum - 1) * fragmentSize”; “The data is fully re-assembled when all fragments have been received. The total number of fragments to expect equals: (dataSize / fragmentSize) + ((dataSize % fragmentSize) ? 1 : 0)”.

Repo: crates/rtps/src/fragment_assembler.rs (FragmentAssembler::insert: byte_start, total_fragments = sample_size.div_ceil(fragment_size))

Status: done

§8.3.8.3 DataFrag: zusammengesetzt wie Data zu interpretieren

Spec: §8.3.8.3, S. 58 — “Once the serializedData is re-assembled by the RTPS Reader, the interpretation of the DataFrag Submessages is identical to that of the Data Submessage.”

Repo: —

Status: done

§8.3.8.3 DataFrag: Fragmentgröße nach kleinstem Transport

Spec: §8.3.8.3, S. 59 — “An RTPS Writer will select fragmentSize based on the smallest message size supported across all underlying transports. … the RTPS Writer can pack multiple fragments into a single DataFrag Submessage or may even send a regular Data Submessage if fragmentation is no longer required.”

Status: done — die Fragmentgröße eines Writers folgt der kleinsten Nachrichtengröße seiner Transporte (Transport::max_message_size, Item unter §8.4.14.1); mehrere Fragmente gehen in ein DATA_FRAG, wo die Nachricht sie trägt; ein Pfad, der ohne Fragmentierung auskommt, erhält ein DATA.

§8.3.8.3 DataFrag: Inline-QoS nur im ersten Fragment nötig

Spec: §8.3.8.3, S. 59 — “When sending inlineQos with DataFrag Submessages, it is only required to send the inlineQos with the first DataFrag Submessage for a given Writer sequence number.”

Repo: crates/rtps/src/reliable_writer.rs (Inline-QoS mit PID_KEY_HASH an den DATA_FRAG eines Samples)

Tests: crates/rtps/src/reliable_writer.rs::tests::keyed_alive_preserves_inline_hash_on_data_fragments_and_rebuilds

Status: done — die Inline-QoS eines Coherent-Set-Mitglieds auf dem ersten DATA_FRAG ist unter §8.7.6 geführt.

§8.3.8.4 Gap: Purpose und gefilterte Changes

Spec: §8.3.8.4, S. 59 — “indicates to the RTPS Reader that a set of changes in the RTPS Writer HistoryCache are not available to one or more RTPS Reader endpoints and will not be sent to them. … Filtered changes should not be treated as samples lost by the RTPS Reader.”

Repo: crates/rtps/src/reliable_reader.rs (handle_gap: irrelevant_change_set)

Tests: crates/rtps/src/writer_proxy.rs::tests::gap_marks_irrelevant, crates/rtps/src/writer_proxy.rs::tests::lost_changes_update_counts_what_was_neither_received_nor_irrelevant

Status: done

§8.3.8.4 Table 8.43 Gap EndiannessFlag

Spec: §8.3.8.4, S. 59, Table 8.43 — “EndiannessFlag … Indicates endianness.”

Repo: crates/rtps/src/submessages.rs (GapSubmessage::write_body, GapSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::tests::gap_submessage_roundtrip_le, crates/rtps/src/submessages.rs::tests::gap_with_group_info_roundtrip_be

Status: done

Spec: §8.3.8.4, S. 60, Table 8.43 — “gapStartGSN: SequenceNumber — Present only if the GroupInfoFlag is set in the header.”

Repo: —

Status: done

§8.3.8.4 Table 8.43 Gap gapEndGSN

Spec: §8.3.8.4, S. 60, Table 8.43 — “gapEndGSN: SequenceNumber — Present only if the GroupInfoFlag is set in the header. … It shall be greater than or equal to the group sequence number corresponding to the sample identified by gapList.bitmapBase.”

Repo: —

Status: done

§8.3.8.4 Table 8.43 Gap filteredCount

Spec: §8.3.8.4, S. 60, Table 8.43 — “filteredCount: ChangeCount — Present only if the FilteredCountFlag is set in the header. Indicates the number of changes corresponding to the set of sequence numbers in the Gap that are still present in the Writer cache but are being filtered for the RTPS Reader.”

Repo: crates/rtps/src/submessages.rs (GapSubmessage::filtered_count)

Tests: crates/rtps/src/submessages.rs::tests::gap_filtered_count_is_eight_octets_high_then_low, crates/rtps/src/submessages.rs::tests::gap_with_filtered_count_roundtrip_le

Status: done

Spec: §8.3.8.4, S. 61 — “readerGUID = { Receiver.destGuidPrefix, Gap.readerId }”.

Repo: crates/dcps/src/runtime.rs (handle_user_datagram_from)

Tests: crates/dcps/src/runtime.rs::tests::the_submessages_after_an_info_destination_for_another_participant_are_not_ours

Status: done

Spec: §8.3.8.6, S. 62, Table 8.44 — “LivelinessFlag … Indicates that the DDS DataWriter associated with the RTPS Writer of the message has manually asserted its LIVELINESS.”

Repo: crates/rtps/src/submessages.rs (HEARTBEAT_FLAG_LIVELINESS); crates/rtps/src/reliable_writer.rs (ReliableWriter::liveliness_heartbeat)

Status: done

Spec: §8.3.8.6, S. 62, Table 8.44 — “currentGSN … Identifies the last (highest) group sequence number written by any DataWriter in the Writer’s Group at the time that the HeartBeat was sent.”

Repo: —

Status: done

§8.3.8.6 Table 8.44 Heartbeat firstGSN

Spec: §8.3.8.6, S. 62, Table 8.44 — “firstGSN … Identifies the group sequence number corresponding to the sample identified by sequence number firstSN.”

Repo: —

Status: done

§8.3.8.6 Table 8.44 Heartbeat lastGSN

Spec: §8.3.8.6, S. 62, Table 8.44 — “lastGSN … Identifies the group sequence number corresponding to the sample identified by sequence number lastSN.”

Repo: —

Status: done

§8.3.8.6 Table 8.44 Heartbeat writerSet

Spec: §8.3.8.6, S. 62, Table 8.44 — “writerSet: GroupDigest … Identifies the subset of Writers that belong to the Writer’s Group at the time the sample with currentGSN was written.”

Status: done — mit G=1 sendet der Writer nach lastGSN writerSet als GroupDigest (vier Oktette, §9.4.2.19; die ersten vier Oktette des MD5 über das EntityIdSet_t, sortiert, §9.3.2.5; leere Gruppe: Null). Der Reader liest beide, wenn die submessageLength Platz lässt, und nimmt ihr Fehlen an (Bild §9.4.5.7); die Commit-Regel §8.7.5 vergleicht sie mit den entdeckten Writern. wire.omit_heartbeat_group_digests lässt sie beim Senden weg. Widerspruch PIM/PSM: siehe „Widersprüche innerhalb der Spec“.

§8.3.8.6 Table 8.44 Heartbeat secureWriterSet

Spec: §8.3.8.6, S. 62, Table 8.44 — “secureWriterSet: GroupDigest … Reserved for use by the DDS-Security Specification.”

Status: done — mit G=1 sendet der Writer nach lastGSN secureWriterSet als GroupDigest (vier Oktette, §9.4.2.19; die ersten vier Oktette des MD5 über das EntityIdSet_t, sortiert, §9.3.2.5; leere Gruppe: Null; secureWriterSet ist für DDS-Security reserviert und wird als Null gesendet). Der Reader liest beide, wenn die submessageLength Platz lässt, und nimmt ihr Fehlen an (Bild §9.4.5.7); die Commit-Regel §8.7.5 vergleicht sie mit den entdeckten Writern. wire.omit_heartbeat_group_digests lässt sie beim Senden weg. Widerspruch PIM/PSM: siehe „Widersprüche innerhalb der Spec“.

§8.3.8.6 Heartbeat Beispiel 1: nie geschrieben

Spec: §8.3.8.6, S. 63 — “A Writer that has never written any samples before sending a Heartbeat will send a Heartbeat with firstSN.value = 1, lastSN.value = 0.”

Repo: crates/rtps/src/reliable_writer.rs (append_heartbeat)

Tests: crates/rtps/src/reliable_writer.rs::tests::an_empty_writer_heartbeats_a_reader_until_it_answers

Status: done

§8.3.8.6 Heartbeat Beispiel 2: ein Sample im Cache

Spec: §8.3.8.6, S. 63 — “A Writer that has only one sample in its cache with sequence number SN will send a Heartbeat with firstSN.value = lastSN.value = SN.”

Repo: crates/rtps/src/reliable_writer.rs (append_heartbeat)

Tests: crates/rtps/src/reliable_writer.rs::tests::heartbeat_carries_cache_range

Status: done

§8.3.8.6 Heartbeat Beispiel 3: Teil der Historie im Cache

Spec: §8.3.8.6, S. 63 — “A Writer that has written 10 samples and still has the last 5 samples in its cache will send a Heartbeat with firstSN.value = 6, lastSN.value = 10.”

Repo: crates/rtps/src/reliable_writer.rs (append_heartbeat)

Tests: crates/rtps/src/reliable_writer.rs::tests::keep_last_evicts_oldest_on_overflow

Status: done

§8.3.8.6 Heartbeat Beispiel 4: Cache leer nach Schreiben

Spec: §8.3.8.6, S. 63 — “A Writer that has written 10 samples before sending a Heartbeat but does not have any samples available at the time of the Heartbeat will send a Heartbeat with firstSN.value = 11, lastSN.value = 10.”

Repo: crates/rtps/src/reliable_writer.rs (append_heartbeat: first_sn.min(last + 1))

Tests: crates/rtps/src/reliable_writer.rs::tests::a_heartbeat_after_the_cache_emptied_announces_the_last_sn_written

Status: done

§8.3.8.6 Heartbeat ungültig: submessageLength zu klein

Spec: §8.3.8.6, S. 63 — “submessageLength in the Submessage header is too small”.

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::read_body)

Status: done — die Kürzung wird erkannt; die Submessage ist ungültig und mit ihr der Rest der Nachricht, die Submessages davor bleiben (ParsedDatagram::invalid_rest, gezählt).

§8.3.8.6 Heartbeat ungültig: firstSN ≤ 0

Spec: §8.3.8.6, S. 63 — “firstSN.value is zero or negative”.

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::heartbeat_validity_rules

Status: done — firstSN unter 1 wird abgewiesen.

§8.3.8.6 Heartbeat ungültig: lastSN < 0

Spec: §8.3.8.6, S. 63 — “lastSN.value is negative”.

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::heartbeat_validity_rules

Status: done — ein negatives lastSN wird abgewiesen.

§8.3.8.6 Heartbeat ungültig: lastSN < firstSN − 1

Spec: §8.3.8.6, S. 63 — “lastSN.value < firstSN.value - 1”.

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::heartbeat_validity_rules

Status: done — lastSN < firstSN - 1 wird abgewiesen; lastSN = firstSN - 1 (leere Historie) ist gültig.

§8.3.8.6 Heartbeat ungültig: Group-Felder

Spec: §8.3.8.6, S. 63 — sechs Bedingungen für currentGSN, firstGSN und lastGSN bei gesetztem GroupInfoFlag.

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::read_body)

Status: done — fünf der sechs Bedingungen werden geprüft. Die sechste, currentGSN > lastGSN, widerspricht der Definition von currentGSN (S. 62–63: die Nummer des zuletzt geschriebenen Samples, das bei lastGSN noch nicht eingerechnet sein kann) und wird nicht angewandt; der Test a_current_gsn_past_the_writers_last_is_accepted hält das fest. Die gewählte Lesart steht unter „Widersprüche innerhalb der Spec“. Cyclone DDS, Fast DDS und OpenDDS senden keine Group-HEARTBEATs; erwartet: keine Wirkung.

§8.3.8.6 Heartbeat: Verfügbarkeit melden

Spec: §8.3.8.6, S. 63 — “It informs the Reader of the sequence numbers that are available in the writer’s HistoryCache so that the Reader may request (using an AckNack) any that it has missed.”

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat: update_from_heartbeat); crates/rtps/src/writer_proxy.rs

Tests: crates/rtps/src/writer_proxy.rs::tests::heartbeat_sets_available_range, crates/rtps/src/reliable_reader.rs::tests::heartbeat_with_missing_triggers_acknack_after_delay

Status: done

§8.3.8.6 Heartbeat ohne FinalFlag verlangt AckNack

Spec: §8.3.8.6, S. 63 — “if the FinalFlag is not set, then the Reader must send an AckNack message indicating which CacheChange changes it has received, even if the AckNack indicates it has received all CacheChange changes in the writer’s HistoryCache.”

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat, tick_outbound)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_heartbeat_without_the_final_flag_is_answered_when_everything_is_received

Status: done — ein HEARTBEAT ohne FinalFlag löst einen ACKNACK aus, auch wenn alles empfangen ist (bitmapBase hinter der letzten Nummer, nichts fehlt), mit und ohne LivelinessFlag.

§8.3.8.6 Heartbeat LivelinessFlag erneuert die manuelle Lease

Spec: §8.3.8.6, S. 63 — “The RTPS Reader should therefore renew the manual liveliness lease of the corresponding remote DDS DataWriter.”

Repo: crates/dcps/src/runtime.rs (handle_user_datagram_from: liveliness.writer_asserted bei h.liveliness_flag)

Tests: crates/dcps/tests/liveliness_qos.rs::linux::assert_liveliness_keeps_a_manual_writer_alive_at_a_remote_reader

Status: done

Spec: §8.3.8.7, S. 64 — “submessageLength in the Submessage header is too small”.

Repo: crates/rtps/src/submessages.rs (HeartbeatFragSubmessage::read_body)

Status: done — die Kürzung wird erkannt; die Submessage ist ungültig und mit ihr der Rest der Nachricht, die Submessages davor bleiben (ParsedDatagram::invalid_rest, gezählt).

§8.3.8.7 HeartbeatFrag ungültig: writerSN ≤ 0

Spec: §8.3.8.7, S. 64 — “writerSN.value is zero or negative”.

Repo: crates/rtps/src/submessages.rs (HeartbeatFragSubmessage::read_body)

Status: done — writerSN unter 1 wird abgewiesen.

§8.3.8.7 HeartbeatFrag ungültig: lastFragmentNum ≤ 0

Spec: §8.3.8.7, S. 64 — “lastFragmentNum.value is zero or negative”.

Repo: crates/rtps/src/submessages.rs (HeartbeatFragSubmessage::read_body)

Status: done — lastFragmentNum unter 1 wird abgewiesen.

§8.3.8.7 HeartbeatFrag: Reader antwortet mit NackFrag

Spec: §8.3.8.7, S. 65 — “The RTPS Reader will respond by sending a NackFrag message, but only if it is missing any of the available fragments.”

Repo: crates/rtps/src/reliable_reader.rs (ReliableReader::handle_heartbeat_frag), crates/dcps/src/runtime.rs (handle_user_datagram_from)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_heartbeat_frag_is_answered_when_an_available_fragment_is_missing

Status: done

§8.3.8.7 HeartbeatFrag: writerGUID/readerGUID

Spec: §8.3.8.7, S. 65 — “writerGUID = { Receiver.sourceGuidPrefix, HeartbeatFrag.writerId } … readerGUID = { Receiver.destGuidPrefix, HeartbeatFrag.readerId } … can be ENTITYID_UNKNOWN”.

Repo: crates/dcps/src/runtime.rs (handle_user_datagram_from: readerId oder ENTITYID_UNKNOWN), crates/rtps/src/reliable_reader.rs (proxy_index_by_writer)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_heartbeat_frag_is_answered_when_an_available_fragment_is_missing

Status: done

§8.3.8.8 InfoDestination: Purpose

Spec: §8.3.8.8, S. 65 — “This message is sent from an RTPS Writer to an RTPS Reader to modify the GuidPrefix used to interpret the Reader entityIds appearing in the Submessages that follow it.”

Repo: —

Tests: —

Status: n/a (informative) — Zweckangabe.

§8.3.8.8 Table 8.46 InfoDestination EndiannessFlag

Spec: §8.3.8.8, S. 65, Table 8.46 — “EndiannessFlag … Indicates endianness.”

Repo: crates/rtps/src/datagram.rs (decode_datagram, encode_datagram für InfoDestination)

Tests: crates/rtps/src/datagram.rs::tests::info_dst_decodes_to_typed_destination_prefix

Status: done

§8.3.8.8 Table 8.46 InfoDestination guidPrefix

Spec: §8.3.8.8, S. 65, Table 8.46 — “guidPrefix: GuidPrefix — Provides the GuidPrefix that should be used to reconstruct the GUIDs of all the RTPS Reader entities whose EntityIds appears in the Submessages that follow.”

Repo: crates/rtps/src/datagram.rs (ParsedSubmessage::InfoDestination); crates/rtps/src/reliable_reader.rs (wrap_to_writer sendet INFO_DST vor ACKNACK/NACK_FRAG)

Status: done

Spec: §8.3.8.9, S. 66, Table 8.47 — “multicastLocatorList … Only present when the MulticastFlag is set.”

Repo: crates/rtps/src/submessages.rs (InfoReplySubmessage::multicast_locators)

Tests: crates/rtps/src/submessages.rs::tests::info_reply_with_multicast_roundtrip_le

Status: done

Spec: §8.3.8.10, S. 67 — “submessageLength in the Submessage header is too small.”

Repo: crates/rtps/src/submessages.rs (InfoSourceSubmessage::read_body)

Status: done — die Kürzung wird erkannt; die Submessage ist ungültig und mit ihr der Rest der Nachricht, die Submessages davor bleiben (ParsedDatagram::invalid_rest, gezählt).

Spec: §8.3.8.11, S. 67, Table 8.49 — “timestamp: Timestamp — Present only if the InvalidateFlag is not set in the header.”

Repo: crates/rtps/src/submessages.rs (InfoTimestampSubmessage::timestamp, InfoTimestampSubmessage::timestamp_body)

Tests: crates/rtps/src/submessages.rs::tests::info_timestamp_roundtrip_le, crates/rtps/src/reliable_writer.rs::tests::write_stamped_prepends_info_ts_before_data

Status: done

§8.3.8.11 InfoTimestamp ungültig: submessageLength zu klein

Spec: §8.3.8.11, S. 68 — “submessageLength in the Submessage header is too small.”

Repo: crates/rtps/src/submessages.rs (InfoTimestampSubmessage::read_body)

Status: done — die Kürzung wird erkannt; die Submessage ist ungültig und mit ihr der Rest der Nachricht, die Submessages davor bleiben (ParsedDatagram::invalid_rest, gezählt).

§8.3.8.11 InfoTimestamp: haveTimestamp und timestamp setzen

Spec: §8.3.8.11, S. 68 — “if ( !InfoTimestamp.InvalidateFlag ) { Receiver.haveTimestamp = true; Receiver.timestamp = InfoTimestamp.timestamp … } else { Receiver.haveTimestamp = false }”.

Repo: crates/rtps/src/receiver_state.rs (ReceiverState::apply_info_timestamp)

Status: done

§8.3.8.11 InfoTimestamp: Korrektur bei clockSkewDetected

Spec: §8.3.8.11, S. 68 — “if ( Receiver.clockSkewDetected ) { Receiver.timestamp += Receiver.rtpsReceptionTime - Receiver.rtpsSendTimestamp }”.

Status: done — apply_info_timestamp addiert bei clockSkewDetected Empfangs- minus Sendezeit; in jedem Empfangspfad wirkt das, sobald wire.clock_skew_threshold_s gesetzt ist (Vorgabe aus, siehe §8.3.7.4 TimestampFlag).

Spec: §8.3.8.12, S. 69 — “submessageLength in the Submessage header is too small.”

Repo: crates/rtps/src/submessages.rs (NackFragSubmessage::read_body)

Status: done — die Kürzung wird erkannt; die Submessage ist ungültig und mit ihr der Rest der Nachricht, die Submessages davor bleiben (ParsedDatagram::invalid_rest, gezählt).

§8.3.8.12 NackFrag ungültig: writerSN ≤ 0

Spec: §8.3.8.12, S. 69 — “writerSN.value is zero or negative.”

Repo: crates/rtps/src/submessages.rs (NackFragSubmessage::read_body)

Tests: crates/rtps/src/submessages.rs::validity_tests::fragment_submessages_validity_rules

Status: done — writerSN unter 1 wird abgewiesen.

§8.3.8.12 NackFrag ungültig: fragmentNumberState ungültig

Spec: §8.3.8.12, S. 69 — “fragmentNumberState is invalid (as defined in 8.3.5.7).”

Repo: crates/rtps/src/submessages.rs (FragmentNumberSet::read_from)

Tests: crates/rtps/src/submessages.rs::validity_tests::fragment_submessages_validity_rules, crates/rtps/src/submessages.rs::tests::fnset_rejects_num_bits_above_256

Status: done — numBits > 256 und bitmapBase < 1 werden abgewiesen.

§8.3.8.12 NackFrag: writerGUID = {destGuidPrefix, writerId}

Spec: §8.3.8.12, S. 69 — “writerGUID = { Receiver.destGuidPrefix, NackFrag.writerId }”.

Repo: crates/dcps/src/runtime.rs (handle_user_datagram_from: rt.writer_slot(nf.writer_id))

Tests: crates/dcps/src/runtime.rs::tests::the_submessages_after_an_info_destination_for_another_participant_are_not_ours

Status: done

§8.3.8.12 NackFrag: readerGUID = {sourceGuidPrefix, readerId}

Spec: §8.3.8.12, S. 69 — “readerGUID = { Receiver.sourceGuidPrefix, NackFrag.readerId }”.

Repo: crates/dcps/src/runtime.rs (handle_user_datagram_from: Guid::new(src_prefix, nf.reader_id)); crates/rtps/src/reliable_writer.rs (handle_nackfrag)

Tests: crates/rtps/src/reliable_writer.rs::tests::handle_nackfrag_unknown_source_counts

Status: done

§8.3.8.13 Pad: Purpose

Spec: §8.3.8.13, S. 69 — “The purpose of this Submessage is to allow the introduction of any padding necessary to meet any desired memory- alignment requirements. It has no other meaning.”

Repo: —

Tests: —

Status: n/a (informative) — Zweckangabe.

§8.3.8.13 Pad: Länge aus submessageLength, immer gültig

Spec: §8.3.8.13, S. 69 — “This Submessage has no contents. … The amount of padding is determined by the value of submessageLength. … This Submessage is always valid.”

Repo: crates/rtps/src/datagram.rs (decode_datagram: PAD als ParsedSubmessage::Unknown übersprungen, Länge 0 als Länge)

Status: done

§8.4 Behavior Module

§8.4.1 Overview

Spec: §8.4.1, S. 70 — Gliederung des Moduls; §8.4.2 enthält die Pflichten, §8.4.7–§8.4.12 zwei Referenzimplementierungen.

Repo: —

Tests: —

Status: n/a (informative) — Gliederung.

§8.4.1 DataWriter entfernt Changes nur nach Kommunikationsstand und QoS

Spec: §8.4.1, S. 70 — “It is the responsibility of the DDS DataWriter to only remove those CacheChange changes that can be removed based on the communication status and the DDS DataWriter’s QoS. For example, the HISTORY QoS setting of KEEP_LAST with a depth of 1 allows a DataWriter to remove a CacheChange if a more recent change replaces the value of the same data-object.”

Repo: crates/rtps/src/reliable_writer.rs (remove_acknowledged, KEEP_LAST-Verdrängung über HistoryCache::insert_returning_evicted); crates/dcps/src/runtime.rs (await_writer_room für KEEP_ALL)

Status: done

§8.4.1.1 Example Behavior

Spec: §8.4.1.1, S. 70–72 — “The contents of this sub clause are not part of the formal specification of the protocol.”

Repo: —

Tests: —

Status: n/a (informative) — ausdrücklich nicht Teil der formalen Spec.

§8.4.2 Behavior Required for Interoperability: Geltungsbereich

Spec: §8.4.2, S. 72–73 — die Pflichten gelten für den Austausch zwischen Implementierungen verschiedener Hersteller.

Repo: —

Tests: —

Status: n/a (informative) — Geltungsbereich; die Pflichten folgen einzeln.

§8.4.2.1 Nur RTPS-Nachrichten

Spec: §8.4.2.1, S. 73 — “No other messages can be used than the RTPS Messages defined in 8.3. … Vendors may extend Messages for vendor specific needs using the extension mechanisms provided by the protocol (see 8.6).”

Repo: crates/rtps/src/datagram.rs (decode_datagram, encode_datagram); crates/rtps/src/parameter_list.rs (Hersteller-PIDs SHM_LOCATOR, ZERODDS_TYPE_ID)

Tests: crates/rtps/tests/vendor_frames.rs::cyclone_session_re_encodes_byte_for_byte, crates/rtps/tests/vendor_frames.rs::rti_session_re_encodes_byte_for_byte

Status: done — die Abweichung bei der HeaderExtension-Kennung steht unter §9.4.5.1.1.

§8.4.2.1 Message Receiver umgesetzt

Spec: §8.4.2.1, S. 73 — “Implementations must implement the rules followed by the RTPS Message Receiver, as introduced in 8.3.4 … This requirement also includes proper Message formatting by preceding Entity Submessages with Interpreter Submessages when required”.

Repo: crates/rtps/src/datagram.rs (ParsedDatagram::receiver_walk); crates/rtps/src/reliable_writer.rs (INFO_TS und INFO_DST vor DATA, HEARTBEAT); crates/rtps/src/reliable_reader.rs (wrap_to_writer)

Status: done — der Receiver ist umgesetzt; die Items zu §8.3.4, §8.3.4.1 und §8.3.8, in denen er von der Spec abwich („Gültige Submessages vor einer ungültigen“, „destGuidPrefix im Nutzdatenpfad“ u. a.), stehen auf done.

§8.4.2.1 Zeitverhalten einstellbar

Spec: §8.4.2.1, S. 73 — “where the requirements on the protocol behavior allow delayed responses or specify periodic events, implementations must allow the end-user to tune those timing characteristics.”

Status: done — nackResponseDelay, nackSuppressionDuration, heartbeatPeriod, heartbeatResponseDelay, heartbeatSuppressionDuration, SPDP- und WLP-Periode sind einstellbar (writer.*_ms, reader.*_ms, discovery.*_ms, Man-Seite und Beispielkonfiguration).

§8.4.2.1 HEARTBEAT-Zeiten der Nutzer-Endpoints einstellbar

Spec: §8.4.2.1, S. 73 — wie vorheriges Item; §8.4.7.1 Table 8.53 heartbeatPeriod, §8.4.10.1 Table 8.67 heartbeatResponseDelay, heartbeatSuppressionDuration.

Repo: crates/dcps/src/runtime.rs (writer_heartbeat_period, reader_heartbeat_response_delay, reader_heartbeat_suppression_duration)

Tests: crates/dcps/tests/runtime_config_layering.rs::the_protocol_timing_parameters_are_settings

Status: done — writer.heartbeat_period_ms, reader.heartbeat_response_delay_ms, reader.heartbeat_suppression_duration_ms.

§8.4.2.1 SPDP und SEDP umgesetzt

Spec: §8.4.2.1, S. 73 — “For the purpose of interoperability, implementations must implement at least the Simple Participant Discovery Protocol and Simple Endpoint Discovery Protocol (see 8.5.1).”

Repo: crates/discovery/src/spdp.rs; crates/discovery/src/sedp/stack.rs

Tests: crates/discovery/src/spdp.rs::tests::beacon_serializes_to_decodable_datagram, crates/discovery/src/sedp/stack.rs::tests::end_to_end_discovery_between_two_stacks

Status: done — die Einzelpflichten stehen unter §8.5.

§8.4.2.2 Writer senden nicht außer der Reihe

Spec: §8.4.2.2, S. 73 — “A Writer must send out data samples in the order they were added to its HistoryCache.”

Spec: §8.4.2.3, S. 74 — “Upon receiving a HEARTBEAT Message with final flag not set, the Reader must respond with an ACKNACK Message. … The response may be delayed to avoid message storms.”

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat, tick_outbound)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_heartbeat_with_the_liveliness_flag_is_taken_as_a_heartbeat

Status: done

§8.4.2.3 Antwort auf HEARTBEAT mit fehlenden Samples

Spec: §8.4.2.3, S. 74 — “a Reader that is missing some data samples must respond with an ACKNACK Message indicating which data samples are missing. This requirement only applies if the Reader can accommodate these missing samples in its cache … The response is not required when a liveliness HEARTBEAT has both liveliness and final flags set”.

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat, tick_outbound, full_for_the_consumer, build_acknack_datagram)

Status: done

§8.4.2.3 Einmal bestätigt, immer bestätigt (Reader)

Spec: §8.4.2.3, S. 74 — “Once a Reader has positively acknowledged receiving a sample using an ACKNACK Message, it can no longer negatively acknowledge that same sample at a later point.”

Repo: crates/rtps/src/writer_proxy.rs (acknack_base monoton; unreceive_change_set nur oberhalb der Basis)

Tests: crates/rtps/src/writer_proxy.rs::tests::acknack_base_walks_up, crates/rtps/src/reliable_reader.rs::tests::sample_rejected_by_a_full_cache_stays_missing_for_the_acknack

Status: done

§8.4.2.3 Writer sendet erneut bestätigte, wieder angeforderte Samples

Spec: §8.4.2.3, S. 74 — “if a Writer receives a negative acknowledgement to a previously positively acknowledged sample, and the Writer can still service the request, the Writer should send the sample.”

Repo: crates/rtps/src/reader_proxy.rs (requested_changes_set); crates/rtps/src/reliable_writer.rs (handle_acknack_window, tick)

Tests: crates/rtps/src/reader_proxy.rs::tests::a_request_for_an_acknowledged_change_is_kept, crates/rtps/src/reliable_writer.rs::tests::an_acknowledged_change_asked_for_again_is_sent_again

Status: done — eine erneute Anforderung eines bestätigten Samples bleibt stehen; der Writer sendet es, solange es im Cache ist, sonst einen GAP.

§8.4.2.3 ACKNACK nur als Antwort auf HEARTBEAT

Spec: §8.4.2.3, S. 74 — “In steady state, an ACKNACK Message can only be sent as a response to a HEARTBEAT Message from a Writer. ACKNACK Messages can be sent from a Reader when it first discovers a Writer as an optimization.”

Repo: crates/rtps/src/reliable_reader.rs (add_writer_proxy, handle_heartbeat, handle_data_frag_opening, tick_outbound)

Tests: crates/rtps/src/reliable_reader.rs::tests::acknack_and_nack_frag_wait_for_a_heartbeat, crates/rtps/src/reliable_reader.rs::tests::pre_emptive_acknack_emitted_after_add_writer_proxy

Status: done — ein ACKNACK entsteht aus einem HEARTBEAT (Table 8.77 T2) und beim ersten Match eines Writers; weder das erneute add_writer_proxy eines bekannten Writers noch ein DATA_FRAG mit Lücken setzen ihn.

§8.4.3 Implementing the RTPS Protocol

Spec: §8.4.3, S. 75 — “a compliant implementation of the protocol need only satisfy the requirements presented in 8.4.2. … Actual implementations need not necessarily follow the reference implementations.”

Repo: —

Tests: —

Status: n/a (informative) — stellt die Referenzimplementierungen frei. Die Übergänge unter §8.4.8–§8.4.12 werden gegen die ZeroDDS-Typen geprüft, die eine Referenzimplementierung abbilden: ReliableWriter (Stateful Writer, best effort und reliable, Nutzdatenpfad), ReliableReader (Stateful Reader), BestEffortWriter, ReliableStatelessWriter, BestEffortReader (nur in Tests verwendet) und der SPDP-Beacon.

§8.4.4 Zulässige Kombinationen von reliabilityLevel

Spec: §8.4.4, S. 75 — “An RTPS Writer cannot be matched to an RTPS Reader unless either the RTPS Writer has the reliabilityLevel set to RELIABLE, or else both the RTPS Writer and RTPS Reader have the reliabilityLevel set to BEST_EFFORT.”

Repo: crates/qos/src/policies/reliability.rs (ReliabilityKind-Ordnung); QoS-Abgleich beim Match in crates/dcps/src/runtime.rs; der ReaderProxy ist zuverlässig nur bei zuverlässigem Writer und Reader (ReaderProxy::new im SEDP-Match-Pfad von crates/dcps/src/runtime.rs)

Status: done — der Abgleich der angebotenen und verlangten QoS ist im DCPS-Audit geführt.

§8.4.4 Stateful und Stateless verständigen sich

Spec: §8.4.4, S. 75 — “a Stateful Writer is able to communicate with a Stateless Reader and vice versa.”

Repo: —

Tests: —

Status: n/a (informative) — Folgerung aus §8.4.2; keine eigene Anforderung.

§8.4.5 Notational Conventions

Spec: §8.4.5, S. 75–76, Table 8.51 — Abkürzungen DW, DR, W, RP, RL, R, WP, WHC, RHC.

Repo: —

Tests: —

Status: n/a (informative) — Schreibweise.

§8.4.6 Table 8.52 Duration_t

Spec: §8.4.6, S. 76, Table 8.52 — “Duration_t: Type used to hold time differences. Should have at least nano-second resolution.”

Repo: crates/qos/src/duration.rs (Duration {seconds, fraction}, 2⁻³² s)

Tests: crates/dcps/src/time.rs::tests::duration_zero_and_infinite_sentinels, crates/rtps/src/participant_data.rs::tests::duration_roundtrip_le

Status: done

§8.4.6 Table 8.52 ChangeForReaderStatusKind

Spec: §8.4.6, S. 76, Table 8.52 — “UNSENT, UNACKNOWLEDGED, REQUESTED, ACKNOWLEDGED, UNDERWAY”.

Repo: crates/rtps/src/reader_proxy.rs (highest_sent_sn, highest_acked_sn, requested_changes statt eines Status je Change)

Tests: crates/rtps/src/reader_proxy.rs::tests::next_unsent_change_walks_sequentially, crates/rtps/src/reader_proxy.rs::tests::acking_also_prunes_requested_changes

Status: done — als Zählerstände und Mengen abgebildet (§8.4.15.1).

§8.4.6 Table 8.52 ChangeFromWriterStatusKind

Spec: §8.4.6, S. 76, Table 8.52 — “NOT_AVAILABLE, MISSING, RECEIVED, UNKNOWN. There are three sub-kinds of NOT_AVAILABLE: NA_FILTERED, NA_REMOVED, NA_UNSPECIFIED”.

Status: done — UNKNOWN, MISSING, RECEIVED und NOT_AVAILABLE mit den Unterarten NA_FILTERED, NA_REMOVED und NA_UNSPECIFIED werden je Änderung geführt (WriterProxy::change_status). Die NOT_AVAILABLE-Änderungen stehen als Läufe gleicher Unterart (höchstens 4096; älter heißt None). lost_changes_update trägt NA_REMOVED ein und zählt es; eine Änderung mit FilteredFlag trägt NA_FILTERED ein.

§8.4.6 Table 8.52 InstanceHandle_t

Spec: §8.4.6, S. 76, Table 8.52 — “Type used to represent the identity of a data-object whose changes in value are communicated by the RTPS protocol.”

Repo: crates/rtps/src/history_cache.rs (CacheChange::key_hash)

Tests: crates/rtps/src/history_cache.rs::tests::the_instance_index_follows_inserts_evictions_and_removals

Status: done — wie Table 8.2 (§8.2.1.2).

§8.4.6 Table 8.52 ParticipantMessageData

Spec: §8.4.6, S. 76, Table 8.52 — “Type used to hold data exchanged between Participants. The most notable use of this type is for the Writer Liveliness Protocol.”

Repo: crates/rtps/src/participant_message_data.rs (ParticipantMessageData)

Tests: crates/rtps/src/participant_message_data.rs::tests::participant_message_data_roundtrip_le

Status: done — Inhalt und Wire-Format unter §8.4.13.4 und §9.6.3.1.

Spec: §8.4.7.1, S. 78, Table 8.53 — “Optional attribute that indicates the maximum size of any SerializedPayload that may be sent by the Writer.”

Tests: crates/rtps/src/publication_data.rs::tests::the_max_payload_size_and_the_name_of_a_writer_travel

Status: done — das Attribut ist optional. Der Writer kündigt dataMaxSizeSerialized als PID_TYPE_MAX_SIZE_SERIALIZED an, wenn es gesetzt ist: aus DdsType::MAX_SERIALIZED_SIZE oder aus UserWriterConfig::data_max_size_serialized (der Wert steht ohne Encapsulation-Header, angekündigt wird er mit den 4 Oktetten des Headers). Ohne Wert kündigt er nichts an.

§8.4.7.1 Table 8.54 Writer new

Spec: §8.4.7.1, S. 79 — “this.lastChangeSequenceNumber := 0; this.writer_cache := new HistoryCache;” und Übernahme der Attribute aus dem Konstruktor.

Repo: crates/rtps/src/reliable_writer.rs (ReliableWriter::new: next_sn: 0, neuer HistoryCache)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_increments_sn_and_returns_data_datagram

Status: done

§8.4.7.1 Table 8.54 Writer new_change

Spec: §8.4.7.1, S. 79 — “The sequence number of the CacheChange is automatically set to be the sequenceNumber of the previous change plus one. … ++this.lastChangeSequenceNumber; a_change := new CacheChange(kind, this.guid, this.lastChangeSequenceNumber, data, inlineQos, handle);”

Repo: crates/rtps/src/reliable_writer.rs (stage_sample, write_lifecycle)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_increments_sn_and_returns_data_datagram, crates/rtps/src/writer.rs::tests::writer_sn_overflow_is_error

Status: done

§8.4.7.1 Default nackResponseDelay = 200 ms

Spec: §8.4.7.1, S. 79 — “nackResponseDelay.sec = 0; nackResponseDelay.nanosec = 200 * 1000 * 1000; //200 milliseconds”.

Repo: crates/rtps/src/reliable_writer.rs (DEFAULT_NACK_RESPONSE_DELAY, SPEC_NACK_RESPONSE_DELAY); crates/dcps/src/runtime.rs (RuntimeConfig::nack_response_delay)

Status: done — DEFAULT_NACK_RESPONSE_DELAY und RuntimeConfig::nack_response_delay sind 200 ms; ein NACK wird erst nach dieser Zeit mit der Reparatur beantwortet (Test). writer.nack_response_delay_ms: 0 antwortet im nächsten Tick.

§8.4.7.1 Default nackResponseDelay

Spec: §8.4.7.1, S. 79 — “The following timing-related values are used as the defaults in order to facilitate ‘out-of-the-box’ interoperability between implementations.”

Status: done — die Werte der Spec sind die Vorgaben: nackResponseDelay 200 ms, nackSuppressionDuration 0 (Laufzeit, YAML-Vorgabe, Man-Seite, Beispielkonfiguration). Die früheren 0 ms bleiben über writer.nack_response_delay_ms erreichbar; die Tests mit Millisekunden-Uhr setzen 0 ausdrücklich.

§8.4.7.1 Default nackSuppressionDuration = 0

Spec: §8.4.7.1, S. 79 — “nackSuppressionDuration.sec = 0; nackSuppressionDuration.nanosec = 0;”.

Repo: crates/rtps/src/reliable_writer.rs (DEFAULT_NACK_SUPPRESSION_DURATION)

Tests: crates/rtps/src/reliable_writer.rs::tests::nack_response_delay_defaults_to_the_spec_200_ms_and_suppression_to_zero

Status: done

§8.4.7.2 Table 8.55 StatelessWriter reader_locators

Spec: §8.4.7.2, S. 80, Table 8.55 — “The StatelessWriter maintains the list of locators to which it sends the CacheChanges. This list may include both unicast and multicast locators.”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter::reader_locators, ReaderLocator); crates/discovery/src/spdp.rs (SpdpBeacon, Ziel-Locatoren)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::reader_locators_are_added_looked_up_and_removed

Status: done — die Liste besteht aus ReaderLocator-Objekten mit eigenem Zustand (highest_sent_seq_num, angeforderte Changes, expects_inline_qos).

§8.4.7.2 Table 8.56 StatelessWriter new

Spec: §8.4.7.2, S. 80 — “this.reader_locators := ;”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter::new: reader_locators leer)

Status: done

§8.4.7.2 Table 8.56 StatelessWriter reader_locator_add

Spec: §8.4.7.2, S. 80 — “ADD a_locator TO {this.reader_locators};”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator) reader_locator_add

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::reader_locators_are_added_looked_up_and_removed

Status: done — ein Locator wird als ReaderLocator mit expectsInlineQos hinzugefügt, einmal je Locator. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.7.2 Table 8.56 StatelessWriter reader_locator_remove

Spec: §8.4.7.3, S. 81 — “REMOVE a_locator FROM {this.reader_locators};”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter::reader_locator_remove)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::reader_locators_are_added_looked_up_and_removed

Status: done — ein ReaderLocator wird entfernt; ein zweites Entfernen meldet false.

§8.4.7.2 Table 8.56 StatelessWriter unsent_changes_reset

Spec: §8.4.7.2, S. 81 — “This operation resets the ‘highestSentChangeSN’ for all the ReaderLocators … useful when called periodically to cause the StatelessWriter to keep re-sending all available changes”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter::unsent_changes_reset, ReaderLocator)

Status: done — unsent_changes_reset setzt highestSentChangeSN aller ReaderLocatoren auf 0; der nächste Tick sendet alle Changes des Caches erneut an jeden Locator. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.7.3 Table 8.57 ReaderLocator-Attribute

Spec: §8.4.7.3, S. 81, Table 8.57 — highestSentChangeSN, requestedChanges, locator, expectsInlineQos.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Status: done — ReaderLocator führt locator, expects_inline_qos, highest_sent_seq_num und die angeforderten Changes. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

Spec: §8.4.8.2, S. 90 — “[RL::unsent_changes == false] … The transition performs no logical actions”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::unsent_changes_are_pushed_in_order_then_announced

Status: done — ohne ungesendete Changes geht die Push-Maschine nach Announcing. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.8.2 Table 8.64 Reliable-StatelessWriter T4

Spec: §8.4.8.2, S. 91 — nächsten ungesendeten Change als DATA mit readerId := ENTITYID_UNKNOWN senden, GAP für übersprungene Nummern; Nachbedingung higuest_sent_seq_num == a_change_seq_num.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Status: done — der nächste ungesendete Change geht als DATA mit readerId = ENTITYID_UNKNOWN an den Locator, davor ein GAP mit filteredCount = 0 über die fehlenden Nummern; Inline-QoS des zugehörigen DDS-Writers nur bei expectsInlineQos; RL::can_send() ist die Grenze max_per_tick. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.8.2 Table 8.64 Reliable-StatelessWriter T5

Spec: §8.4.8.2, S. 91 — periodisch “HEARTBEAT := new HEARTBEAT(the_rtps_writer.writerGuid, seq_num_min, seq_num_max); HEARTBEAT.FinalFlag := SET; HEARTBEAT.readerId := ENTITYID_UNKNOWN;”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Status: done — HEARTBEAT mit FinalFlag gesetzt und readerId = ENTITYID_UNKNOWN je heartbeatPeriod an einen ankündigenden Locator; ein leerer Cache meldet firstSN = lastSN + 1. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.8.2 Table 8.64 Reliable-StatelessWriter T6

Spec: §8.4.8.2, S. 91–92 — “FOREACH reply_locator_t IN { Receiver.unicastReplyLocatorList, Receiver.multicastReplyLocatorList } reader_locator := the_rtps_writer.reader_locator_lookup(reply_locator_t); reader_locator.requested_changes_set(ACKNACK.readerSNState.set);”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Status: done — ein ACKNACK setzt für jeden Reply-Locator des Receiver-Zustands, der einen Port nennt und ReaderLocator ist, requested_changes_set(readerSNState); ein ACKNACK ohne brauchbaren Reply-Locator (kein InfoReply) wird gezählt (unmatched_acknacks). ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.8.2 Table 8.64 Reliable-StatelessWriter T7

Spec: §8.4.8.2, S. 92 — “[RL::requested_changes() != ] … The transition performs no logical actions”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay

Status: done — angeforderte Changes setzen den Repair-Zustand MustRepair. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.8.2 Table 8.64 Reliable-StatelessWriter T8

Spec: §8.4.8.2, S. 92 — “The transition performs the same logical actions performed by Transition T6”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay

Status: done — ein weiterer ACKNACK in MustRepair verfährt wie T6. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.8.2 Table 8.64 Reliable-StatelessWriter T9

Spec: §8.4.8.2, S. 92 — “triggered by the firing of a timer indicating that the duration of W::nackResponseDelay has elapsed since the state must_repair was entered.”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay

Status: done — nach nackResponseDelay (set_nack_response_delay) geht die Maschine nach Repairing. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.8.2 Table 8.64 Reliable-StatelessWriter T10 (DATA)

Spec: §8.4.8.2, S. 92 — “a_change_seq_num := the_reader_locator.next_requested_change(); … IF ( a_change != ) { DATA = new DATA(a_change); … DATA.readerId := ENTITYID_UNKNOWN; sendto the_reader_locator.locator, DATA; }”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay, crates/rtps/src/reliable_stateless_writer.rs::tests::the_related_qos_goes_out_with_the_data_only_where_it_is_expected

Status: done — next_requested_change geht als DATA mit readerId = ENTITYID_UNKNOWN an den Locator; Inline-QoS des DDS-Writers und des Changes bei expectsInlineQos. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.8.2 Table 8.64 Reliable-StatelessWriter T10 (GAP)

Spec: §8.4.8.2, S. 92 — “ELSE { GAP = new GAP(a_change.sequenceNumber); GAP.readerId := ENTITYID_UNKNOWN; GAP.filteredCount := 0; sendto the_reader_locator.locator, GAP; }”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::a_requested_change_that_left_the_cache_is_answered_by_a_gap

Status: done — ein angeforderter Change, der nicht mehr im Cache ist, wird mit einem GAP (filteredCount = 0) beantwortet. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.8.2 Table 8.64 Reliable-StatelessWriter T11

Spec: §8.4.8.2, S. 93 — “[RL::requested_changes() == ] … The transition performs no logical actions”.

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::an_acknack_is_answered_at_its_reply_locator_after_the_delay

Status: done — ohne angeforderte Changes geht die Maschine nach Waiting. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.8.2 Table 8.64 Reliable-StatelessWriter T12

Spec: §8.4.8.2, S. 93 — “the_rtps_writer.reader_locator_remove( the_reader_locator); delete the_reader_locator;”

Repo: crates/rtps/src/reliable_stateless_writer.rs (ReliableStatelessWriter, ReaderLocator)

Tests: crates/rtps/src/reliable_stateless_writer.rs::tests::reader_locators_are_added_looked_up_and_removed

Status: done — reader_locator_remove löscht den ReaderLocator. ReliableStatelessWriter wird von keinem Produktionspfad verwendet; kein Hersteller ist gemessen.

§8.4.9.1 Table 8.65 Best-Effort-StatefulWriter T1

Spec: §8.4.9.1, S. 94, Table 8.65 T1 — “a_reader_proxy := new ReaderProxy( remoteReaderGuid, remoteGroupEntityId, expectsInlineQos, unicastLocatorList, multicastLocatorList); the_rtps_writer.matched_reader_add(a_reader_proxy);”

Repo: crates/rtps/src/reliable_writer.rs (add_reader_proxy mit ReaderProxy::new(.., is_reliable: false)); crates/rtps/src/reader_proxy.rs (remote_group_entity_id); crates/dcps/src/runtime.rs (Match-Pfad)

Status: done — matched_reader_add nimmt remoteGroupEntityId, expectsInlineQos und beide Locator-Listen.

§8.4.9.1 Table 8.65 Best-Effort-StatefulWriter T2

Spec: §8.4.9.1, S. 94 — “[RP::unsent_changes() == true] … Note that for a Best-Effort Writer, W::pushMode == true … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — Übergang ohne logische Aktion.

§8.4.9.1 Table 8.65 Best-Effort-StatefulWriter T3

Spec: §8.4.9.1, S. 94 — “[RP::unsent_changes() == false] … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — Übergang ohne logische Aktion.

§8.4.9.1 Table 8.65 Best-Effort-StatefulWriter T4

Spec: §8.4.9.1, S. 94–95 — nächster ungesendeter Change; GAP für übersprungene Nummern mit filteredCount 0; DATA bei bestandenem DDS_FILTER, sonst GAP mit filteredCount 1; Inline-QoS bei expectsInlineQos; Nachbedingung higuest_sent_seq_num == a_change_seq_num.

Status: done — ein Proxy im Schritt erhält jeden neuen Change als DATA; ein zurückliegender erhält in tick jeden noch nicht gesendeten Change als DATA, eine Nummer, die der Cache nicht mehr hat, als GAP mit filteredCount 0. Besteht ein Change DDS_FILTER(the_reader_proxy, a_change) nicht (ReaderProxy::with_filter), geht ein GAP mit filteredCount 1 statt des DATA. Die Laufzeit setzt keinen Filter (DDS_FILTER darf eine leere Operation sein, §8.2.10.1); das Verhalten gegenüber Cyclone DDS, Fast DDS und OpenDDS ist nicht gemessen.

§8.4.9.1 Best-Effort-StatefulWriter: zurückliegender Proxy

Spec: §8.4.9.1, S. 95 — T4 sendet next_unsent_change() an jeden Proxy, “if ( a_change_seq_num > the_reader_proxy.higuest_sent_seq_num +1 ) { GAP = … }”.

Repo: crates/rtps/src/reliable_writer.rs (tick: next_unsent_change je Best-Effort-Proxy, append_change)

Tests: crates/rtps/src/reliable_writer.rs::tests::a_best_effort_reader_matched_late_is_pushed_what_the_cache_holds

Status: done — ein zurückliegender Best-Effort-Proxy erhält die noch nicht gesendeten Changes der Reihe nach, ohne Anforderung; eine Nummer, die der Cache nicht mehr hat, als GAP.

§8.4.9.1 Table 8.65 Best-Effort-StatefulWriter T5

Spec: §8.4.9.1, S. 95–96 — “ADD a_change TO the_rtps_writer.writer_cache;” Nachbedingung “FOREACH proxy IN the_rtps_writer.matched_readers proxy.unsent_changes() == true”.

Repo: crates/rtps/src/reliable_writer.rs (stage_sample)

Tests: crates/rtps/src/reliable_writer.rs::tests::write_fans_out_to_all_reader_proxies

Status: done

§8.4.9.1 Table 8.65 Best-Effort-StatefulWriter T6

Spec: §8.4.9.1, S. 96 — “the_rtps_writer.matched_reader_remove( the_reader_proxy); delete the_reader_proxy;”

Repo: crates/rtps/src/reliable_writer.rs (remove_reader_proxy)

Tests: crates/rtps/src/reliable_writer.rs::tests::remove_reader_proxy_by_guid

Status: done

§8.4.9.2 Table 8.66 Reliable-StatefulWriter T1

Spec: §8.4.9.2, S. 98, Table 8.66 T1 — “a_reader_proxy := new ReaderProxy( remoteReaderGuid, remoteGroupEntityId, expectsInlineQos, unicastLocatorList, multicastLocatorList); the_rtps_writer.matched_reader_add(a_reader_proxy);”

Status: done — matched_reader_add nimmt remoteGroupEntityId, expectsInlineQos und beide Locator-Listen.

§8.4.9.2 Table 8.66 Reliable-StatefulWriter T2

Spec: §8.4.9.2, S. 98–99 — “[RP::unsent_changes() != ] … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — Übergang ohne logische Aktion.

§8.4.9.2 Table 8.66 Reliable-StatefulWriter T3

Spec: §8.4.9.2, S. 99 — “[RP::unsent_changes() == false] … The transition performs no logical actions”.

Repo: —

Tests: —

Status: n/a (informative) — Übergang ohne logische Aktion.

Repo: crates/rtps/src/reliable_reader.rs (set_heartbeat_suppression_duration, handle_heartbeat)

Tests: crates/rtps/src/reliable_reader.rs::tests::heartbeat_suppression_duration_ignores_a_heartbeat_that_arrives_too_soon

Status: done

§8.4.10.1 Table 8.67 Reader reader_cache

Spec: §8.4.10.1, S. 103, Table 8.67 — “reader_cache: History Cache — Contains the history of CacheChange changes for this RTPS Reader.”

Repo: crates/rtps/src/reliable_reader.rs (WriterProxyState::received_cache); crates/dcps/src/subscriber.rs (Sample-Speicher des DataReader)

Status: done

§8.4.10.1 Table 8.67 Reader expectsInlineQos

Spec: §8.4.10.1, S. 104, Table 8.67 — “expectsInlineQos: bool — Specifies whether the RTPS Reader expects in-line QoS to be sent along with any data.”

Repo: crates/rtps/src/subscription_data.rs (SubscriptionBuiltinTopicData::expects_inline_qos)

Tests: crates/rtps/src/subscription_data.rs::tests::expects_inline_qos_goes_out_when_set_and_reads_back

Status: done

§8.4.10.1 Default heartbeatResponseDelay = 500 ms

Spec: §8.4.10.1, S. 104 — “heartbeatResponseDelay.sec = 0; heartbeatResponseDelay.nanosec = 500 * 1000 * 1000; // 500 milliseconds”.

Repo: crates/rtps/src/reliable_reader.rs (DEFAULT_HEARTBEAT_RESPONSE_DELAY, SPEC_HEARTBEAT_RESPONSE_DELAY); crates/dcps/src/runtime.rs (RuntimeConfig::reader_heartbeat_response_delay)

Status: done — DEFAULT_HEARTBEAT_RESPONSE_DELAY und RuntimeConfig::reader_heartbeat_response_delay sind 500 ms; reader.heartbeat_response_delay_ms: 0 antwortet im nächsten Tick.

§8.4.10.1 Default heartbeatResponseDelay

Spec: §8.4.10.1, S. 104 — “The following timing-related values are used as the defaults in order to facilitate ‘out-of-the-box’ interoperability between implementations.”

Status: done — die Werte der Spec sind die Vorgaben: heartbeatResponseDelay 500 ms, heartbeatSuppressionDuration 0 (Laufzeit, Man-Seite, Beispielkonfiguration). Die früheren 0 ms bleiben über reader.heartbeat_response_delay_ms erreichbar. §8.4.7.1 nennt keine heartbeatPeriod; sie bleibt 100 ms (writer.heartbeat_period_ms). Die eingebauten Reader von SEDP, Secure-Volatile und TypeLookup nutzen dieselbe Vorgabe.

Spec: §8.4.10.4, S. 106, Table 8.72 — “Optional attribute that indicates the maximum size of any SerializedPayload that may be sent by the matched Writer.”

Repo: crates/rtps/src/reliable_reader.rs (set_writer_data_max_size, oversize_payload_count); crates/dcps/src/runtime.rs (Verdrahtung beim Anlegen des Writer-Proxys, reader.honor_data_max_size_serialized)

Status: done — der Reader übernimmt das Attribut aus der Ankündigung und weist ein SerializedPayload darüber ab (nach dem Öffnen eines geschützten Payloads; die Nummer gilt als nicht verfügbar, der Zähler oversize_payload_count steigt). Ein DATA_FRAG-Sample wird nach dem Zusammensetzen geprüft; AssemblerCaps begrenzt weiter die Größe zusammengesetzter Samples. Die benannte Einstellung reader.honor_data_max_size_serialized=false nimmt den Payload trotzdem an, für einen Writer, der seine eigene Ankündigung überschreitet (Fast DDS 3.6.1: 160 Oktette angekündigt, 100 036 gesendet).

§8.4.10.4 Table 8.72 WriterProxy changes_from_writer

Spec: §8.4.10.4, S. 106, Table 8.72 — “List of CacheChange changes received or expected from the matched RTPS Writer.”

Repo: crates/rtps/src/writer_proxy.rs (known_up_to, received, irrelevant, first_available_sn, last_available_sn)

Tests: crates/rtps/src/writer_proxy.rs::tests::the_known_run_answers_as_the_sets_of_every_sn_did

Status: done — als Zählerstände und Mengen abgebildet (§8.4.15.1).

§8.4.10.4 Table 8.72 WriterProxy remoteGroupEntityId

Spec: §8.4.10.4, S. 107, Table 8.72 — “remoteGroupEntityId: EntityId_t — Identifies the group to which the matched Reader belongs”.

Repo: crates/rtps/src/writer_proxy.rs (WriterProxy::remote_group_entity_id, with_remote_group_entity_id); crates/dcps/src/runtime.rs (Match-Pfad, PID_GROUP_GUID der Publication)

Tests: crates/rtps/src/writer_proxy.rs::tests::the_remote_group_entity_id_is_kept, crates/dcps/src/runtime.rs::tests::the_proxies_of_a_match_carry_the_remote_group_entity_id

Status: done — der Proxy führt remoteGroupEntityId; der Match-Pfad füllt ihn aus PID_GROUP_GUID der SEDP-Ankündigung des Writers, ENTITYID_UNKNOWN ohne Gruppe.

§8.4.10.4 Table 8.73 WriterProxy new

Spec: §8.4.10.4, S. 107 — “this.changes_from_writer := ; … initialized to UNKNOWN”.

Repo: crates/rtps/src/writer_proxy.rs (WriterProxy::new: first_available_sn = 1, last_available_sn = 0)

Tests: crates/rtps/src/writer_proxy.rs::tests::fresh_proxy_has_no_missing

Status: done

§8.4.10.4 Table 8.73 WriterProxy available_changes_max

Spec: §8.4.10.4, S. 108 — “seq_num := MAX { change.sequenceNumber SUCH-THAT ( change IN this.changes_from_writer AND ( change.status == RECEIVED OR change.status == NOT_AVAILABLE) ) }” unter der Bedingung, dass keine kleinere Nummer MISSING oder UNKNOWN ist.

Repo: crates/rtps/src/writer_proxy.rs (available_changes_max)

Tests: crates/rtps/src/writer_proxy.rs::tests::available_changes_max_stops_at_the_first_hole, crates/rtps/src/writer_proxy.rs::tests::available_changes_max_passes_over_an_irrelevant_change

Status: done

§8.4.10.4 Table 8.73 WriterProxy not_available_change_set

Spec: §8.4.10.4, S. 108 — “IF ( filteredCount == COUNT(this. a_seq_num_set) ) THEN change.status := NA_FILTERED; ELSE IF ( filteredCount == 0) change.status := NA_REMOVED; ELSE change.status := NA_UNSPECIFIED;”

Status: done — filteredCount gleich der Größe der Menge ergibt NA_FILTERED, 0 ergibt NA_REMOVED, dazwischen NA_UNSPECIFIED; der Status steht je Änderung. Ein GAP ohne FilteredCountFlag zählt als 0 (Annahme: das Feld fehlt bei Peers vor 2.5, deren GAP nur entfernte Änderungen meldet; nicht gegen einen Hersteller gemessen). Eine bereits bekannte Nummer wird nicht erneut gezählt oder umgesetzt.

Spec: §8.4.12.1, S. 112, Table 8.76 T1 — “a_writer_proxy := new WriterProxy(remoteWriterGuid, remoteGroupEntityId, unicastLocatorList, multicastLocatorList); the_rtps_reader.matched_writer_add(a_writer_proxy);”

Repo: crates/rtps/src/reliable_reader.rs (add_writer_proxy, set_best_effort); crates/rtps/src/writer_proxy.rs (remote_group_entity_id)

Status: done — matched_writer_add nimmt remoteGroupEntityId und beide Locator-Listen.

§8.4.12.2 Table 8.77 Reliable-StatefulReader T4

Spec: §8.4.12.2, S. 115 — “[W::missing_changes() != ] … The transition performs no logical actions.”

Repo: crates/rtps/src/reliable_reader.rs (handle_heartbeat: has_missing setzt pending_acknack_since)

Tests: crates/rtps/src/reliable_reader.rs::tests::final_heartbeat_from_unknown_to_data_writer_requests_the_missing_sn

Status: done

§8.4.12.2 Table 8.77 Reliable-StatefulReader T5

Spec: §8.4.12.2, S. 115–116 — nach heartbeatResponseDelay “missing_seq_num_set.base := the_writer_proxy.available_changes_max() + 1; … send ACKNACK(missing_seq_num_set);” — bei zu vielen fehlenden Nummern “the subset with smallest value of the sequence number”.

Repo: crates/rtps/src/reliable_reader.rs (tick_outbound, build_acknack_datagram); crates/rtps/src/submessages.rs (SequenceNumberSet::from_missing)

Status: done — Basis und kleinste Teilmenge stimmen; die Menge enthält nur Nummern, von denen kein Fragment vorliegt (die übrigen fordert NACK_FRAG an, §8.4.14.1).

§8.4.12.2 Table 8.77 Reliable-StatefulReader T6

Spec: §8.4.12.2, S. 116 — “Similar to T1 … The transition performs no logical actions in the virtual machine.”

Repo: —

Tests: —

Status: n/a (informative) — Übergang ohne logische Aktion.

§8.4.12.2 Table 8.77 Reliable-StatefulReader T7

Spec: §8.4.12.2, S. 116 — “the_writer_proxy.missing_changes_update( HEARTBEAT.lastSN); the_writer_proxy.lost_changes_update(HEARTBEAT.firstSN, true);”

Repo: crates/rtps/src/writer_proxy.rs (update_from_heartbeat)

Tests: crates/rtps/src/reliable_reader.rs::tests::a_heartbeat_with_the_liveliness_flag_is_taken_as_a_heartbeat

Status: done

§8.4.12.2 Table 8.77 Reliable-StatefulReader T8

Spec: §8.4.12.2, S. 116 — “a_change := new CacheChange(DATA); the_reader.reader_cache.add_change(a_change); the_writer_proxy.received_change_set(a_change.sequenceNumber);”

Repo: crates/rtps/src/reliable_reader.rs (handle_data_into, store_received)

Tests: crates/rtps/src/reliable_reader.rs::tests::in_order_data_delivered_immediately, crates/rtps/src/reliable_reader.rs::tests::out_of_order_data_buffered_until_gap_filled

Status: done

§8.4.12.2 Table 8.77 Reliable-StatefulReader T9

Spec: §8.4.12.2, S. 116 — “the_writer_proxy.not_available_change_set(GAP. sequence_number_set, GAP.filteredCount);”

Repo: crates/rtps/src/reliable_reader.rs (handle_gap)

Status: done — filteredCount wird ausgewertet (Item unter §8.4.10.4 Table 8.73 WriterProxy not_available_change_set); die Nummern stehen je Änderung als NOT_AVAILABLE.

§8.4.12.2 Table 8.77 Reliable-StatefulReader T10

Spec: §8.4.12.2, S. 116 — “the_rtps_reader.matched_writer_remove( the_writer_proxy); delete the_writer_proxy;”

Repo: crates/rtps/src/reliable_reader.rs (remove_writer_proxy, depart_writer_proxy)

Status: done

§8.4.12.3 ChangeFromWriter illustrated

Spec: §8.4.12.3, S. 117–118, Figure 8.25 — Zustände Unknown, Missing, NotRequested, Requested, Received, NotAvailable (Filtered, Removed, Unspecified) und die auslösenden Ereignisse.

Repo: —

Tests: —

Status: n/a (informative) — Veranschaulichung der Übergänge aus §8.4.10.4 und §8.4.12.2 (“It is illustrative”); keine eigene Anforderung.

§8.4.13 Writer Liveliness Protocol: Unterstützung verpflichtend

Spec: §8.4.13, S. 118 — “All implementations must support the Writer Liveliness Protocol in order to be interoperable.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint); crates/dcps/src/runtime.rs (DcpsRuntime::wlp)

Status: done — Writer und Reader des Protokolls laufen in jedem Teilnehmer; der Writer hat die QoS aus §8.4.13.3 und behandelt den Reader nach builtinEndpointQos. Die Wire-Änderung des Writers ist gegen Cyclone, Fast DDS, OpenDDS und RTI nicht gemessen.

§8.4.13.1 Assoziation mit den Builtin-Endpunkten eines entdeckten Teilnehmers

Spec: §8.4.13.1, S. 118 — “once a Participant knows of the presence of another Participant, it can assume the presence of the built-in Endpoints made available by the remote Participant and establish the association with the locally matching built-in Endpoints.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::add_peer_reader); crates/dcps/src/runtime.rs (spdp_announced, wlp_unicast_targets, answer_wlp_heartbeats)

Status: done — aus jeder SPDP-Ankündigung entsteht (unverändert: bleibt) ein Reader-Proxy für den BuiltinParticipantMessageReader des Teilnehmers, wenn dessen availableBuiltinEndpoints ihn nennen; Ziel sind seine Metatraffic-Locatoren.

§8.4.13.1 Dasselbe Protokoll wie für Anwendungs-Endpunkte

Spec: §8.4.13.1, S. 118 — “The protocol used to communicate between built-in Endpoints is the same as used for application-defined Endpoints.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint: make_writer, write_pulse, add_peer_reader, handle_reader_messages, tick); crates/dcps/src/runtime.rs (WLP-Tick, spdp_announced)

Status: done — der WLP-Writer ist ein ReliableWriter mit einem Reader-Proxy je Teilnehmer: DATA mit Piggyback-HEARTBEAT, periodische HEARTBEATs bis zur Bestätigung, Wiederholung nur des Angeforderten, GAP für überholte Nummern. Der Reader beantwortet HEARTBEATs (heartbeat_responses) und führt je Writer die höchste empfangene Sequenznummer.

§8.4.13.2 Builtin-Endpunkte BuiltinParticipantMessageWriter und -Reader

Spec: §8.4.13.2, S. 118 — “The RTPS Protocol reserves the following values of the EntityId_t for these built-in Endpoints: ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER”

Repo: crates/rtps/src/wire_types.rs (EntityId::BUILTIN_PARTICIPANT_MESSAGE_WRITER, EntityId::BUILTIN_PARTICIPANT_MESSAGE_READER); crates/dcps/src/wlp.rs (WlpEndpoint::handle_datagram)

Tests: crates/dcps/src/wlp.rs::tests::wlp_handle_datagram_updates_peer_state, crates/dcps/src/wlp.rs::tests::wlp_handle_datagram_ignores_non_wlp_traffic

Status: done — die Werte sind unter §9.3.1.3 geführt.

§8.4.13.3 Writer durability.kind = TRANSIENT_LOCAL

Spec: §8.4.13.3, S. 118 — “both the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader shall use the following QoS values: durability.kind = TRANSIENT_LOCAL_DURABILITY”.

Repo: crates/dcps/src/wlp.rs (WlpEndpoint: make_writer, write_pulse, add_peer_reader, handle_reader_messages, tick); crates/dcps/src/runtime.rs (WLP-Tick, spdp_announced)

Tests: crates/dcps/src/wlp.rs::tests::a_late_reader_is_told_by_heartbeat_and_gets_the_held_samples_on_request

Status: done — ein später hinzukommender Reader erhält die gehaltenen Proben mit dem ersten Tick, ohne sie anzufordern (die Historie hält eine Probe je Art, eine Anforderung träfe sonst eine neuere Probe), und ein HEARTBEAT sagt, was die Historie hält; fordert er sie erneut an, erhält er sie noch einmal.

§8.4.13.3 Writer history KEEP_LAST, depth 1

Spec: §8.4.13.3, S. 118–119 — “history.kind = KEEP_LAST_HISTORY_QOS”, “history.depth = 1”.

Repo: crates/dcps/src/wlp.rs (WlpEndpoint: make_writer, write_pulse, add_peer_reader, handle_reader_messages, tick); crates/dcps/src/runtime.rs (WLP-Tick, spdp_announced)

Tests: crates/dcps/src/wlp.rs::tests::the_history_holds_the_last_sample_of_each_kind

Status: done — die Historie hält die letzte Probe je Instanz (participantGuidPrefix, kind; PID_KEY_HASH in der In-line-QoS); überholte Proben werden nicht wiederholt.

§8.4.13.3 Reader durability.kind = TRANSIENT_LOCAL

Spec: §8.4.13.3, S. 118 — “both the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader shall use the following QoS values: durability.kind = TRANSIENT_LOCAL_DURABILITY”.

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::heartbeat_responses: die Anforderung beginnt bei firstSN des HEARTBEAT, nicht beim Match)

Tests: crates/dcps/src/wlp.rs::tests::a_heartbeat_announcing_a_pulse_not_received_is_answered_with_a_request_for_it, crates/dcps/tests/cyclone_live_wlp.rs::cyclone_live_wlp_handshake

Status: done

§8.4.13.3 Reader history KEEP_LAST, depth 1

Spec: §8.4.13.3, S. 118–119 — “history.kind = KEEP_LAST_HISTORY_QOS”, “history.depth = 1”.

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::peers: je Teilnehmer der zuletzt empfangene Stand)

Tests: crates/dcps/src/wlp.rs::tests::wlp_handle_datagram_updates_peer_state

Status: done — der Reader hält keine Proben, sondern übergibt jede empfangene Probe sofort an die Liveliness-Verwaltung der DataReader und merkt sich je Teilnehmer last_seen und last_kind.

§8.4.13.3 Writer reliability.kind = RELIABLE

Spec: §8.4.13.3, S. 119 — “The BuiltinParticipantMessageWriter shall use reliability.kind = RELIABLE_RELIABILITY_QOS.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint: make_writer, write_pulse, add_peer_reader, handle_reader_messages, tick); crates/dcps/src/runtime.rs (WLP-Tick, spdp_announced)

Status: done — der Writer führt Zustand je Reader (Reader-Proxy), sendet HEARTBEATs bis zur Bestätigung und wiederholt auf ACKNACK (handle_reader_messages).

§8.4.13.3 Reader RELIABLE oder BEST_EFFORT

Spec: §8.4.13.3, S. 119 — “The BuiltinParticipantMessageReader may be configured to use either RELIABLE_RELIABILITY_QOS or BEST_EFFORT_RELIABILITY_QOS. If the BuiltinParticipantMessageReader is configured to use BEST_EFFORT_RELIABILITY_QOS then the BEST_EFFORT_PARTICIPANT_MESSAGE_DATA_READER flag in ParticipantProxy::builtinEndpointQos shall be set.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::heartbeat_responses)

Status: done — der Reader beantwortet HEARTBEATs wie ein RELIABLE-Reader; das Flag entfällt, ZeroDDS sendet kein PID_BUILTIN_ENDPOINT_QOS.

§8.4.13.3 Writer behandelt den Reader nach builtinEndpointQos

Spec: §8.4.13.3, S. 119 — “If the ParticipantProxy::builtinEndpointQos is included in the SPDPdiscoveredParticipantData, then the BuiltinParticipantMessageWriter shall treat the BuiltinParticipantMessageReader as indicated by the flags. If the ParticipantProxy::builtinEndpointQos is not included then the BuiltinParticipantMessageWriter shall treat the BuiltinParticipantMessageReader as if it is configured with RELIABLE_RELIABILITY_QOS.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::add_peer_reader, sync_proxy); crates/dcps/src/runtime.rs (spdp_announced)

Tests: crates/dcps/src/wlp.rs::tests::the_reader_is_treated_as_builtin_endpoint_qos_says

Status: done — mit builtinEndpointQos und dem Flag ist der Reader ein Best-Effort-Proxy (keine HEARTBEATs), sonst RELIABLE.

§8.4.13.4 Figure 8.26 ParticipantMessageData

Spec: §8.4.13.4, S. 119, Figure 8.26 — “Figure 8.26 defines the ParticipantMessageData datatype associated with the RTPS built-in Endpoint for the DCPSParticipantMessage Topic.” Attribute participantGuidPrefix, kind, data.

Repo: crates/rtps/src/participant_message_data.rs (ParticipantMessageData, to_cdr, from_cdr)

Status: done

§8.4.13.5 AUTOMATIC: Probe schneller als die kürzeste Lease

Spec: §8.4.13.5, S. 119 — “If the Participant contains one or more Writers with a liveliness of AUTOMATIC_LIVELINESS_QOS, then one sample is written at a rate faster than the smallest lease duration among the Writers sharing this QoS.”

Repo: crates/dcps/src/runtime.rs (refresh_wlp_period: ein Drittel der kürzesten endlichen Lease eines AUTOMATIC-Writers, höchstens ein Drittel der Teilnehmer-Lease); crates/dcps/src/wlp.rs (WlpEndpoint::tick)

Status: done — die AUTOMATIC-Probe geht auch ohne AUTOMATIC-Writer aus.

§8.4.13.5 MANUAL_BY_PARTICIPANT: eigene Probe

Spec: §8.4.13.5, S. 119 — “Similarly, a separate sample is written if the Participant contains one or more Writers with a liveliness of MANUAL_BY_PARTICIPANT_LIVELINESS_QOS at a rate faster than the smallest lease duration among these Writers.”

Repo: crates/dcps/src/runtime.rs (DcpsRuntime::assert_liveliness, refresh_manual_by_participant); crates/dcps/src/wlp.rs (WlpEndpoint::assert_participant, refresh_participant)

Status: done — die Probe wird bei DomainParticipant::assert_liveliness und bei write, assert_liveliness, dispose und unregister_instance eines MANUAL_BY_PARTICIPANT-Writers geschrieben; Aufrufe vor dem Tick teilen sich eine Probe.

§8.4.13.5 Zwei Instanzen, Schlüssel participantGuidPrefix und kind

Spec: §8.4.13.5, S. 119 — “The instances are distinguished using their DDS key, which is comprised of the participantGuidPrefix and kind fields. Each of the two types of liveliness QoS handled through this protocol will result in a unique kind field and therefore form two distinct instances in the HistoryCache.”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::write_pulse)

Status: done — die Instanz ist (participantGuidPrefix, kind); der KeyHash (12 Oktette Prefix, 4 Oktette kind, Big-Endian) steht als PID_KEY_HASH in der In-line-QoS jeder DATA, die Historie hält eine Probe je Instanz.

§8.4.13.5 participantGuidPrefix des schreibenden Teilnehmers

Spec: §8.4.13.5, S. 119 — “In both liveliness cases the participantGuidPrefix field contains the GuidPrefix_t of the Participant that is writing the data (and therefore asserting the liveliness of its Writers).”

Repo: crates/dcps/src/wlp.rs (WlpEndpoint::encode_pulse: ParticipantMessageData::automatic(self.own_prefix))

Tests: crates/dcps/src/wlp.rs::tests::wlp_handle_datagram_updates_peer_state, crates/rtps/src/participant_message_data.rs::tests::participant_message_data_automatic_default_data_empty

Status: done

§8.4.13.5 MANUAL_BY_TOPIC nicht über den BuiltinParticipantMessageWriter

Spec: §8.4.13.5, S. 119 — “The DDS liveliness kind MANUAL_BY_TOPIC_LIVELINESS_QOS is not implemented using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. It is discussed in 8.7.2.2.3.”

Repo: crates/dcps/src/publisher.rs (DataWriter::assert_liveliness → DcpsRuntime::assert_writer_liveliness_eid: HEARTBEAT mit LivelinessFlag)

Status: done — DcpsRuntime::assert_writer_liveliness schreibt zusätzlich eine Probe mit der Herstellerart 0x80000001; die DCPS-API ruft diese Funktion nicht auf.

§8.4.14 Optionales Verhalten

Spec: §8.4.14, S. 119 — “Optional features may not be supported by all RTPS implementations. An optional feature does not affect basic interoperability, but is only available if all implementations involved support it.”

Repo: —

Tests: —

Status: n/a (informative) — Einordnung der folgenden Unterabschnitte, keine Anforderung.

§8.4.14.1 Large Data: Transportgrenzen und Fragment-Submessages

Spec: §8.4.14.1, S. 120 — “a transport may impose its own limitations. For example, it may limit the maximum packet size (e.g., 64K for UDP) … 8.3.8 introduces the following Submessages to enable fragmenting large data: DataFrag, HeartbeatFrag, NackFrag”.

Repo: —

Tests: —

Status: n/a (informative) — Begründung, keine Anforderung; die Submessages sind unter §8.3.8 geführt.

§8.4.14.1 Fragmentgröße aus den Transporten des Writers

Spec: §8.4.14.1, S. 120 — “All transports available to the Writer must be able to accommodate DataFrag Submessages containing at least one fragment. This means the transport with the smallest maximum message size determines the fragment size.” “Note the fragment size is determined by all transports available to the Writer, not simply the subset of transports required to reach all currently known Readers.”

Repo: crates/transport/src/lib.rs (Transport::max_message_size, DEFAULT_MAX_MESSAGE_SIZE); crates/transport-udp/src/udp_transport.rs (UdpTransportConfig::max_message_size); crates/transport-shm, transport-uds, transport-tcp, transport-tsn (je max_message_size); crates/dcps/src/layered_transport.rs (Minimum der Legs); crates/rtps/src/reliable_writer.rs (fragment_size_for_message_size); crates/dcps/src/runtime.rs (Writer-Anlage)

Status: done — jeder Transport nennt seine größte Nachricht (Transport::max_message_size; UDP einstellbar mit transport.udp.max_message_size, Vorgabe 1472; SHM und UDS ihr Datagramm-Limit, TCP die Rahmengrenze, TSN 1500; der Schichten-Transport das Minimum seiner Legs). Die Fragmentgröße eines Writers ist die Nachricht des kleinsten Transports abzüglich 128 Oktette, fest für das Leben des Writers: 1344 bei der Vorgabe.

§8.4.14.1 Fragmentgröße fest je Writer

Spec: §8.4.14.1, S. 120 — “The fragment size must be fixed for a given Writer and is identical for all remote Readers. By fixing the fragment size, the data a fragment number refers to does not depend on a particular remote Reader.”

Repo: crates/rtps/src/reliable_writer.rs (ReliableWriter::fragment_size_for, needs_fragmentation); crates/rtps/src/reader_proxy.rs (ReaderProxy::message_limit)

Status: done — die Fragmentgröße wird nach dem Anlegen des Writers nicht mehr geändert (set_fragmentation entfällt) und ist für alle Reader dieselbe; die In-line-QoS, die ein Fragment kürzt, wird mit ihrer größten Länge für irgendeinen Reader gezählt, sodass auch expectsInlineQos eines Readers sie nicht ändert.

§8.4.14.1 Fragmentgröße ≤ 65536

Spec: §8.4.14.1, S. 120 — “The fragment size must satisfy: fragment size <= 65536 bytes.”

Repo: crates/rtps/src/reliable_writer.rs (MAX_FRAGMENT_SIZE, ReliableWriter::try_new, ReliableWriter::new, fragment_size_for)

Tests: crates/rtps/src/reliable_writer.rs::tests::the_fragment_size_is_bounded_by_what_the_field_holds

Status: done — fragmentSize des DATA_FRAG ist ein unsigned short; 65536 hat keine Kodierung, die Grenze ist 65535. try_new weist größere Werte mit einem Fehler ab (new bricht ab). Ein DATA_FRAG hält seine 32 festen Oktette, die Inline-QoS und das Fragment in den 65535 Oktetten von octetsToNextHeader; die Fragmentgröße liegt entsprechend höchstens bei 65503.

§8.4.14.1 DataFrag in aufsteigender Fragmentnummer

Spec: §8.4.14.1, S. 120 — “DataFrag Submessages are sent in order, where ordering is defined by increasing fragment numbers.”

Spec: §8.4.14.1, S. 121 — “If a Writer wants to inform a Reader on the partial availability of fragments for a given sequence number, a HeartbeatFrag Submessage can be used instead.”

Repo: —

Tests: —

Status: n/a (informative) — keine Anforderung; die Antwort des Readers auf HeartbeatFrag ist unter §8.3.8.7 geführt.

Spec: §8.5.3.1, S. 125 — “The pre-configured list of locators may include both unicast and multicast locators. Port numbers are defined by each PSM.”

Repo: crates/dcps/src/runtime.rs (send_spdp_multicast, send_spdp_unicast, expand_initial_peer)

Tests: crates/dcps/src/runtime.rs::tests::multicast_free_discovery_via_initial_peers, crates/dcps/src/runtime.rs::tests::expand_initial_peer_ip_only_yields_well_known_port_range

Status: done

§8.5.3.1 SPDPbuiltinParticipantReader und Wahl des EDP

Spec: §8.5.3.1, S. 125 — “The contained information includes what Endpoint Discovery Protocols the remote Participant supports. The proper Endpoint Discovery Protocol is then used for exchanging Endpoint information with the remote Participant.”

Repo: crates/discovery/src/sedp/stack.rs (on_participant_discovered: nach builtin_endpoint_set)

Status: done

§8.5.3.1 Optional: Ankündigung an einen bisher unbekannten Teilnehmer

Spec: §8.5.3.1, S. 125 — “Implementations can minimize any start-up delays by sending an additional SPDPdiscoveredParticipantData in response to receiving this data-object from a previously unknown Participant, but this behavior is optional.”

Repo: crates/dcps/src/runtime.rs (directed_spdp_targets, SpdpResponseTargets)

Tests: crates/dcps/src/runtime.rs::tests::the_spdp_response_axis_decides_the_targets, crates/rtps/src/dialect.rs::tests::the_spdp_response_default_answers_the_beacon_source

Status: done

§8.5.3.1 Optional: Locatorliste um entdeckte Teilnehmer erweitern

Spec: §8.5.3.1, S. 125 — “Implementations may also enable the user to choose whether to automatically extend the pre-configured list of locators with new locators from newly discovered Participants. … These last two features are optional and not required for the purpose of interoperability.”

Repo: crates/dcps/src/runtime.rs (send_spdp_unicast: periodische Ankündigung auch an die Metatraffic-Locatoren entdeckter Teilnehmer)

Tests: crates/dcps/src/runtime.rs::tests::an_initial_peer_a_discovered_participant_covers_is_left_to_the_fan_out

Status: done — die Erweiterung ist nicht abschaltbar.

Spec: §8.5.3.2, S. 126, Table 8.78 — “expectsInlineQos: bool — Describes whether the Readers within the Participant expect that the QoS values that apply to each data modification are encapsulated included with each Data.”

Repo: crates/rtps/src/participant_data.rs (expects_inline_qos, PID_EXPECTS_INLINE_QOS)

Tests: crates/rtps/src/participant_data.rs::tests::expects_inline_qos_goes_out_when_set_and_reads_back

Status: done

Spec: §8.5.3.2, S. 127, Table 8.78 — “manualLivelinessCount: Count_t — Used to implement MANUAL_BY_PARTICIPANT liveliness QoS. When liveliness is asserted, the manualLivelinessCount is incremented and a new SPDPdiscoveredParticipantData is sent.”

Status: done — wird eine MANUAL_BY_PARTICIPANT-Probe geschrieben, steigt der Zähler (höchstens einmal je Tick) und eine neue Ankündigung geht hinaus; ein Empfänger, bei dem sich der Zähler eines bekannten Teilnehmers ändert, wertet das als manuelle Liveliness-Zusicherung dieses Teilnehmers (Test: n, n + 1 erneuert die MANUAL_BY_PARTICIPANT-Writer des Teilnehmers am Reader).

§8.5.3.2 Table 8.78 builtinEndpointQos

Spec: §8.5.3.2, S. 127, Table 8.78 — “builtinEndpointQos: BuiltinEndpointQos_t — Provides additional information on the QoS of the built-in Endpoints supported by the Participant.”

Repo: crates/rtps/src/participant_data.rs (builtin_endpoint_qos); crates/dcps/src/wlp.rs (WlpEndpoint::add_peer_reader)

Status: done — das Feld wird gelesen und geschrieben; der WLP-Writer behandelt den Reader danach (§8.4.13.3). ZeroDDS selbst kündigt keines an: sein Reader ist RELIABLE.

§8.5.3.2 Weitere EDP über die Erweiterungsmechanismen

Spec: §8.5.3.2, S. 127 — “There are currently no other Endpoint Discovery Protocols defined by the RTPS specification. In order to extend SPDPdiscoveredParticipantData to include additional EDPs, the standard RTPS extension mechanisms can be used.”

Repo: —

Tests: —

Status: n/a (informative) — keine Anforderung.

Spec: §8.5.3.3, S. 128, Table 8.79 — “resendPeriod: Defaults to a PSM-specified value.”

Repo: crates/dcps/src/runtime.rs (RuntimeConfig::spdp_period, ZERODDS_SPDP_PERIOD_MS)

Tests: crates/dcps/src/runtime.rs::tests::a_short_lease_without_a_period_beacons_three_times_a_lease, crates/dcps/tests/runtime_config_layering.rs::the_protocol_timing_parameters_are_settings

Status: done — einstellbar (discovery.spdp_period_ms); die Vorgabe ist 30 s, die PSM-Vorgabe.

Spec: §8.5.4.1, S. 130 — “The protocol used to communicate between built-in Endpoints is the same as used for application-defined Endpoints.”

Repo: crates/discovery/src/sedp/writer.rs (make_sedp_writer: ReliableWriter); crates/discovery/src/sedp/reader.rs (ReliableReader)

Status: done

§8.5.4.2 SEDP-Endpunkte zuverlässig

Spec: §8.5.4.2, S. 130 — “The SEDP therefore maps each corresponding built-in DDS DataWriter or DataReader into corresponding reliable RTPS Writer and Reader Endpoints.” “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.”

Repo: crates/discovery/src/sedp/writer.rs (make_sedp_writer); crates/discovery/src/sedp/reader.rs

Status: done — die Abweichungen der zuverlässigen Writer und Reader von §8.4.2 sind dort geführt.

§8.5.4.2 EntityIds der SEDP-Endpunkte

Spec: §8.5.4.2, S. 130–131 — “The RTPS Protocol reserves the following values of the EntityId_t for the built-in Endpoints: ENTITYID_SEDP_BUILTIN_PUBLICATIONS_ANNOUNCER … ENTITYID_SEDP_BUILTIN_TOPICS_DETECTOR”

Repo: crates/rtps/src/wire_types.rs (EntityId::SEDP_BUILTIN_PUBLICATIONS_WRITER, EntityId::SEDP_BUILTIN_SUBSCRIPTIONS_READER und die übrigen)

Tests: crates/rtps/src/wire_types.rs::tests::sedp_publications_writer_layout, crates/rtps/src/wire_types.rs::tests::sedp_subscriptions_reader_layout

Status: done — die Werte sind unter §9.3.1.3 geführt.

§8.5.4.3 Topics-Endpunkte optional

Spec: §8.5.4.3, S. 131 — “it is not required to implement the SEDPbuiltinTopicsReader and SEDPbuiltinTopicsWriter built-in Endpoints and for the purpose of interoperability, implementations should not rely on their presence in remote Participants.”

Repo: crates/discovery/src/sedp/stack.rs (on_participant_discovered: Topics-Proxies nur bei gesetzten Bits)

Tests: crates/discovery/src/sedp/stack.rs::tests::the_topics_bits_wire_the_topics_writer_and_reader, crates/discovery/src/sedp/stack.rs::tests::partial_endpoint_set_wires_only_matching_sides

Status: done

§8.5.4.3 Nur die benötigten Builtin-Endpunkte

Spec: §8.5.4.3, S. 131 — “a Participant is only required to provide the built-in Endpoints required for matching up local and remote Endpoints.”

Repo: —

Tests: —

Status: n/a (informative) — keine Anforderung; ZeroDDS stellt alle SEDP-Endpunkte bereit.

§8.5.4.4 Table 8.82 Publications: Einfügen

Spec: §8.5.4.4, S. 133, Table 8.82 — “Data-Object insertion: Each time a DataWriter is created in the DomainParticipant.”

Repo: crates/dcps/src/runtime.rs (announce_publication beim Anlegen des Writers)

Tests: crates/dcps/tests/builtin_topic_readers.rs::linux_e2e::sedp_pub_sub_populates_dcps_publication_and_subscription_readers

Status: done

§8.5.4.4 Table 8.82 Publications: Ändern

Spec: §8.5.4.4, S. 133, Table 8.82 — “Data-Object modification: Each time the QoS of an existing DataWriter is modified.”

Repo: crates/dcps/src/runtime.rs (reannounce_publication)

Status: done

§8.5.4.4 Table 8.82 Publications: Löschen

Spec: §8.5.4.4, S. 133, Table 8.82 — “Data-Object deletion: Each time an existing DataWriter belonging to the DomainParticipant is deleted.”

Repo: crates/discovery/src/sedp/writer.rs (SedpPublicationsWriter::dispose); crates/dcps/src/runtime.rs (dispose_publication beim Löschen)

Tests: crates/dcps/tests/endpoint_delete_unmatch_e2e.rs::linux_e2e::dropping_a_writer_unmatches_the_remote_reader

Status: done

§8.5.4.4 Table 8.83 Subscriptions: DataType

Spec: §8.5.4.4, S. 134, Table 8.83 — “DataType: DiscoveredReaderData”.

Repo: crates/discovery/src/sedp/writer.rs (SedpSubscriptionsWriter::announce)

Tests: crates/discovery/tests/sedp_loopback.rs::subscription_announce_then_reader_fills_cache

Status: done

§8.5.4.4 Table 8.83 Subscriptions: Cardinality

Spec: §8.5.4.4, S. 134, Table 8.83 — “Cardinality: The number of DataReaders contained by the DomainParticipant. There is a one-to-one correspondence between each DataReaders in the Participant and a data-object that describes the DataReaders stored in the WriterHistoryCache for the SEDPbuiltinSubscriptionsWriter.”

Repo: —

Tests: crates/discovery/src/sedp/writer.rs::tests::every_endpoint_keeps_one_change_for_a_reader_that_matches_later

Status: done — derselbe Writer-Aufbau (make_sedp_writer) wie unter Table 8.82 Cardinality, Ankündigung mit der GUID als Schlüssel.

§8.5.4.4 Table 8.83 Subscriptions: Einfügen

Spec: §8.5.4.4, S. 134, Table 8.83 — “Data-Object insertion: Each time a DataReader is created in the DomainParticipant.”

Repo: crates/dcps/src/runtime.rs (announce_subscription beim Anlegen des Readers)

Tests: crates/dcps/tests/builtin_topic_readers.rs::linux_e2e::sedp_pub_sub_populates_dcps_publication_and_subscription_readers

Status: done

Spec: §8.5.5.1, S. 135–136 — “IF ( PUBLICATIONS_DETECTOR IS_IN participant_data.availableEndpoints ) THEN … writer.matched_reader_add(proxy);” und entsprechend für PUBLICATIONS_ANNOUNCER, SUBSCRIPTIONS_DETECTOR, SUBSCRIPTIONS_ANNOUNCER, TOPICS_DETECTOR, TOPICS_ANNOUNCER.

Repo: crates/discovery/src/sedp/stack.rs (on_participant_discovered)

Status: done — die Proxies erhalten die Metatraffic-Unicast-Locatoren (ersatzweise die Default-Unicast-Locatoren), keine Multicast-Locatoren.

§8.5.5.2 Teilnehmer entfernt: Proxies der SEDP-Endpunkte entfernen

Spec: §8.5.5.2, S. 136 — “Based on the remote Participant’s leaseDuration, a local Participant ‘local_participant’ concludes that a previously discovered Participant with GUID_t participant_guid is no longer present. The Participant ‘local_participant’ must reconfigure any local Endpoints that were communicating with Endpoints in the Participant”.

Repo: crates/discovery/src/sedp/stack.rs (on_participant_lost); crates/dcps/src/runtime.rs (Lease-Ablauf und Abmeldung)

Status: done

§8.5.6 Andere Entdeckungsprotokolle

Spec: §8.5.6, S. 136 — “Remote Participants using a different vendor’s RTPS implementation must be contacted using at least the SPDP to ensure interoperability. There is no such requirement when the remote Participant uses the same RTPS implementation.”

Repo: crates/dcps/src/runtime.rs (SPDP läuft in jedem Teilnehmer; Abkürzung im selben Prozess über inproc_announce_publication)

Tests: crates/dcps/src/runtime.rs::tests::handle_spdp_registers_real_fastdds_participant, crates/discovery/tests/fastdds_spdp_repro.rs::zerodds_parses_real_fastdds_spdp

Status: done

§8.5.6 Gemeinsames EDP

Spec: §8.5.6, S. 137 — “All Participants must support at least the SEDP, so they always have at least one EDP in common. However, if two Participants both support another EDP, this alternative protocol can be used instead.”

Repo: —

Tests: —

Status: n/a (informative) — die Pflicht zu SEDP ist unter §8.5.1 geführt; der Rest ist eine Erlaubnis.

§8.6 Versioning and Extensibility

§8.6 Höhere Minor-Versionen verarbeiten

Spec: §8.6, S. 137 — “Implementations of this version of the RTPS protocol should be able to process RTPS Messages not only with the same major version but possibly higher minor versions.”

Repo: crates/rtps/src/datagram.rs (decode_datagram: nur eine höhere Major-Version wird abgewiesen)

Tests: crates/rtps/src/datagram.rs::tests::decode_accepts_minor_version_above_supported, crates/rtps/src/datagram.rs::tests::decode_rejects_major_version_above_supported

Status: done

§8.6.1 Unbekannte Submessages überspringen

Spec: §8.6.1, S. 137 — “Additional Submessages with other submessageIds can be introduced and used anywhere in an RTPS Message. An implementation should skip over unknown Submessages using the submessageLength field in the SubmessageHeader.”

Repo: crates/rtps/src/datagram.rs (decode_datagram, ParsedSubmessage::Unknown)

Tests: crates/rtps/src/datagram.rs::tests::decode_skips_unknown_submessage_without_must_understand, crates/rtps/src/datagram.rs::tests::decode_skips_an_unknown_submessage_whatever_its_flags

Status: done — eine Submessage mit unbekannter SubmessageId wird nach submessageLength übersprungen, auch mit gesetztem Flag-Bit 7 (§8.3.4.1 Regel 3 kennt kein Must-Understand auf Submessage-Ebene).

§8.6.1 Zusätzliche Felder am Ende einer Submessage überspringen

Spec: §8.6.1, S. 137 — “Additional fields can be added to the end of a Submessage that was already defined in the current minor version. An implementation should skip over additional fields using the submessageLength field in the SubmessageHeader.”

Repo: crates/rtps/src/datagram.rs (decode_submessage); die read_body der Submessages in crates/rtps/src/submessages.rs

Tests: crates/rtps/src/datagram.rs::tests::additional_fields_at_the_end_of_a_known_submessage_are_skipped

Status: done — HEARTBEAT, ACKNACK, GAP, HEARTBEAT_FRAG, NACK_FRAG, INFO_TS, INFO_SRC, INFO_REPLY, INFO_REPLY_IP4 und INFO_DST ergeben mit acht Oktetten mehr am Ende des Körpers denselben Wert wie ohne. Bei DATA und DATA_FRAG endet der Körper mit den Nutzdaten; neue Felder davor überspringt octetsToInlineQos.

§8.6.1 Unbekannte Builtin-Endpunkte ignorieren

Spec: §8.6.1, S. 137 — “Additional built-in Endpoints with new IDs can be added. An implementation should ignore any unknown built-in Endpoints.”

Repo: crates/discovery/src/sedp/stack.rs (Zuordnung nur bekannter EntityIds); crates/discovery/src/sedp/stack.rs (on_participant_discovered: nur bekannte Bits)

Tests: crates/discovery/src/sedp/stack.rs::tests::routing_unknown_with_wrong_writer_does_not_match, crates/discovery/src/sedp/stack.rs::tests::partial_endpoint_set_wires_only_matching_sides

Status: done

§8.6.1 Unbekannte Parameter ignorieren

Spec: §8.6.1, S. 137 — “Additional parameters with new parameterIds can be added. An implementation should ignore any unknown parameters.”

Repo: crates/rtps/src/parameter_list.rs (ParameterList::from_bytes); crates/rtps/src/publication_data.rs (Decoder übergehen unbekannte PIDs)

Tests: crates/rtps/src/publication_data.rs::tests::unknown_pids_are_skipped, crates/rtps/src/parameter_list.rs::tests::validate_must_understand_in_data_pipeline_optional_unknown_pid_passes

Status: done — unbekannte PIDs mit Must-Understand-Bit sind unter §9.4.2.11 geführt.

§8.6.1 Erweiterungen erhöhen die Minor-Version

Spec: §8.6.1, S. 137 — “All such changes require an increase of the minor version number.”

Repo: —

Tests: —

Status: n/a (informative) — Anforderung an künftige Fassungen der Spezifikation.

§8.6.2 Unveränderliches innerhalb der Major-Version

Spec: §8.6.2, S. 137 — “A Submessage cannot be deleted. A Submessage cannot be modified except as described in 8.6.1. The meaning of submessageIds cannot be modified.”

Repo: —

Tests: —

Status: n/a (informative) — Anforderung an künftige Fassungen der Spezifikation.

§8.7 Implementing DDS QoS and advanced DDS features using RTPS

§8.7 DDS-QoS und erweiterte Funktionen über RTPS

Spec: §8.7, S. 137 — “This sub clause defines how to use RTPS to implement the DDS QoS parameters.” “This sub clause forms a normative part of the specification for the purpose of interoperability.”

Repo: —

Tests: —

Status: n/a (informative) — Einleitung; die Anforderungen stehen in §8.7.1 bis §8.7.10.

Spec: §8.7.2.2.3, S. 139 — “DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. … implementations must refresh the Participant’s liveliness (i.e., send the ParticipantMessageData, see (8.4.13.5) at a rate faster than the smallest lease duration among the Writers.”

Repo: crates/dcps/src/runtime.rs (refresh_wlp_period); crates/dcps/src/wlp.rs (WlpEndpoint::tick)

Tests: crates/dcps/tests/liveliness_qos.rs::linux::an_automatic_writer_that_never_writes_stays_alive_at_a_remote_reader

Status: done

§8.7.2.2.3 LIVELINESS MANUAL_BY_PARTICIPANT

Spec: §8.7.2.2.3, S. 139 — “If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant’s liveliness (i.e., send the ParticipantMessageData, see 8.4.13.5).”

Repo: crates/dcps/src/runtime.rs (refresh_manual_by_participant, Aufrufe in write_user_sample_*, write_user_lifecycle_with, assert_writer_liveliness_eid, bump_manual_liveliness_count); crates/dcps/src/wlp.rs

Status: done — write, assert_liveliness, dispose und unregister_instance eines MANUAL_BY_PARTICIPANT-Writers veranlassen eine ParticipantMessageData mit MANUAL_LIVELINESS_UPDATE beim nächsten Tick (statt einer Prüfung im Takt der kleinsten Lease) und erhöhen den manualLivelinessCount der SPDP-Ankündigung.

§8.7.2.2.3 LIVELINESS MANUAL_BY_TOPIC

Spec: §8.7.2.2.3, S. 140 — “The standard RTPS Messages that result from calling write(), dispose(), or unregister_instance() on a Writer Entity suffice to assert the liveliness of a Writer with LIVELINESS QoS set to MANUAL_BY_TOPIC. When assert_liveliness() is called, the Writer must send a Heartbeat Message with final flag and liveliness flag set.”

Repo: crates/rtps/src/reliable_writer.rs (liveliness_heartbeat); crates/dcps/src/runtime.rs (assert_writer_liveliness_eid)

Status: done

§8.7.2.2.4 TIME_BASED_FILTER auf der Writer-Seite

Spec: §8.7.2.2.4, S. 140 — “Implementations may optimize bandwidth usage by applying a time-based filter on the Writer side. … When one or more data updates are filtered out on the Writer side, implementations must send a Gap Submessage instead, indicating which samples were filtered out. This Submessage must be sent before the next update”.

Repo: —

Tests: —

Status: open — eine optionale Funktion; ZeroDDS wendet TIME_BASED_FILTER nur auf der Reader-Seite an (tbf_should_deliver) und sendet kein GAP für zeitgefilterte Samples.

§8.7.2.2.5 RELIABILITY

Spec: §8.7.2.2.5, S. 140 — “Implementations must meet the reliable RTPS protocol requirements for interoperability, defined in 8.4.2.”

Repo: —

Tests: —

Status: n/a (informative) — Verweis; die Anforderungen sind unter §8.4.2 geführt.

§8.7.2.2.6 DESTINATION_ORDER BY_SOURCE_TIMESTAMP

Spec: §8.7.2.2.6, S. 140 — “In order to implement the DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS policy, implementations must include an InfoTimestamp Submessage with every update from a Writer.”

Repo: crates/rtps/src/reliable_writer.rs (append_info_ts vor jeder DATA und jedem DATA_FRAG); crates/dcps/src/runtime.rs (jeder write erhält einen Quellzeitstempel)

Status: done

Spec: §8.7.3.3, S. 142, Table 8.87 — “filterSignatures: FilterSignature_t[] — A list of filters that were applied to the sample.”

Repo: —

Tests: —

Status: open — Teil der optionalen Filterung auf der Writer-Seite (§8.7.3), die ZeroDDS nicht ausführt; PID_CONTENT_FILTER_INFO wird nicht gesendet.

§8.7.3.4 Reader filtern, wenn der Writer nicht filtert

Spec: §8.7.3.4, S. 142 — “Samples will always be filtered on the Reader side if: The Writer side did not apply any filtering. The Writer side did not apply the filter expected by the Reader. … The Reader side does not support Writer side filtering”.

Repo: crates/dcps/src/subscriber.rs (Filter je empfangenem Sample)

Status: done

§8.7.3.4 Filterklasse DDSSQL

Spec: §8.7.3.4, S. 143 — “If an implementation supports Content-filtered Topics, it must at least recognize the “DDSSQL” filter class, as mandated by the DDS specification.”

Repo: crates/dcps/src/topic.rs (ContentFilteredTopic, SQL-Filter); crates/rtps/src/subscription_data.rs (filter_class::DDSSQL)

Spec: §8.7.4, S. 143–144 — “This so called “dispose/unregister message” shall be sent if any of the following conditions is met: 1. The Reader does not have a Content Filter. 2. The Writer has previously sent a Data message to the Reader for that same instance. 3. The Reader has OWNERSHIP QosPolicy kind EXCLUSIVE …”

Repo: crates/dcps/src/runtime.rs (write_user_lifecycle: an jeden gematchten Reader)

Status: done — ZeroDDS sendet die Nachricht in jedem Fall.

§8.7.6 DataReader: Gruppen-Coherent-Set übergeben

Spec: §8.7.6, S. 147 — “The group coherent set becomes ready to be committed to the DDS DataReader once an ECS sample is committed to the Subscriber and the ECS sample meets the criteria for being committed to the DDS DataReader. Once the group coherent set becomes ready to be committed the Subscriber shall determine if the subscriber-relevant coherent set is complete and if so, make it available to the application.”

Repo: —

Status: done

§8.7.6 Inline-QoS eines Coherent-Set-Mitglieds auf dem ersten DataFrag

Spec: §8.7.6, S. 146 — “The remainder of the discussion only refers to Data Submessages, but the same approach is followed for DataFrag Submessages.”

Repo: —

Status: done

§8.7.7 Directed Write: PID_DIRECTED_WRITE

Spec: §8.7.7, S. 147 — “RTPS supports directed writes by using the in-line QoS parameter extension mechanism. The serialized information denotes the GUIDs of the targeted reader(s).”

Status: done — Kodierung und Lesen des Parameters; der Empfangspfad liest jeden PID_DIRECTED_WRITE einer DATA, nicht nur den ersten. Kein Writer von ZeroDDS sendet einen gerichteten Write; die Spec bietet ihn dem Writer an, sie verlangt ihn nicht.

§8.7.7 Directed Write: nur der adressierte Reader übernimmt

Spec: §8.7.7, S. 147 — “When a writer sends a directed sample, only recipients with a matching GUID accept the sample; all other recipients acknowledge but absorb the sample, as if it were a GAP message.”

Repo: crates/rtps/src/reliable_reader.rs (addressed_elsewhere, irrelevant_change_set); crates/rtps/src/inline_qos.rs (directed_write_accepts)

Status: done — ein Reader, den kein PID_DIRECTED_WRITE der DATA nennt, bestätigt die Probe und verwirft sie wie nach einem GAP; ein genannter nimmt sie an. Gemessen: grün auf dem Linux-Testhost.

§8.7.8 Property Lists

Spec: §8.7.8, S. 147 — “The RTPS protocol supports Property Lists as in-line parameters. Properties can then be propagated during Discovery or as in-line QoS.”

Repo: crates/rtps/src/property_list.rs (WirePropertyList); crates/rtps/src/participant_data.rs (properties, PID_PROPERTY_LIST)

Tests: crates/rtps/src/property_list.rs::tests::multi_property_roundtrip_be, crates/rtps/src/participant_data.rs::tests::participant_data_properties_roundtrip

Status: done — ZeroDDS überträgt Property Lists in SPDP; in SEDP und als Inline-QoS nicht.

§8.7.9 Original Writer Info: Weiterleitung kennzeichnen

Spec: §8.7.9, S. 147 — “This service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source … it can treat them as duplicates.”

Status: done — ein Writer sendet eine Probe, ein Dispose oder ein Unregister im Namen eines anderen mit PID_ORIGINAL_WRITER_INFO, beim ersten Senden und bei jeder Reparatur. Der Durability-Service sendet gespeicherte Proben so, der Routing-Service im Relay-Modus (Route::relay) jede Probe und jede Lebenszyklus-Marke. Gemessen: grün auf dem Linux-Testhost.

§8.7.9 Original Writer Info: Übergabe an den Reader des Originals

Spec: §8.7.9, S. 147 — “When a RTPS Reader receives this information, it will treat it as a normal CacheChange, but once the CacheChange is ready to be committed to the DDS DataReader, it will not commit it. Instead, it will hand if off to the HistoryCache of the RTPS Reader that is communicating with the RTPS Writer indicated in the ORIGINAL_WRITER_INFO in-line QoS”.

Repo: crates/rtps/src/reliable_reader.rs (original_writer_of, commit_released, commit_forwarded, set_forwarder_trusted)

Status: done — eine Änderung mit PID_ORIGINAL_WRITER_INFO geht als die des Original-Writers hinaus, mit dessen Sequenznummer, auch wenn der Reader zum Original keinen Proxy hat; eine, die der Reader vom Original oder einem anderen Weiterleiter schon hat, ist ein Duplikat. Ein Writer, dem der Reader nicht als Weiterleiter traut, liefert als er selbst (unter DDS-Security nur mit <relay> im Grant, dds-security-1.2 §7.1.1.4). Gemessen: grün auf dem Linux-Testhost.

§8.7.9 Table 8.89 originalWriterGUID

Spec: §8.7.9, S. 147, Table 8.89 — “originalWriterGUID: GUID_t — The GUID of the RTPS Writer that first generated the message.”

Repo: crates/rtps/src/inline_qos.rs (original_writer_info_param)

Tests: crates/rtps/src/inline_qos.rs::tests::original_writer_info_param_24_byte_layout_le, crates/rtps/src/inline_qos.rs::tests::original_writer_info_roundtrip_be

Status: done — kodiert, gesendet und beim Empfang ausgewertet (Items unter §8.7.9).

§8.7.9 Table 8.89 originalWriterSN

Spec: §8.7.9, S. 147, Table 8.89 — “originalWriterSN: SequenceNumber_t — The Sequence Number of the CacheChange as sent from the original writer.”

Repo: crates/rtps/src/inline_qos.rs (original_writer_info_param)

Tests: crates/rtps/src/inline_qos.rs::tests::original_writer_info_roundtrip_le

Status: done — kodiert, gesendet und beim Empfang ausgewertet (Items unter §8.7.9).

§8.7.10 KeyHash aus den Daten berechnen

Spec: §8.7.10, S. 148 — “When the key hash is not received by a DataReader, it should be computed from the data itself. If there is no data in the submessage, then a default zero-valued key hash should be used by the DataReader.”

Repo: crates/dcps/src/runtime.rs (reader_key_hash_context); crates/dcps/src/key_hash.rs

Status: done

§8.7.10 KeyHash nach §9.6.4.8 berechnen

Spec: §8.7.10, S. 148 — “A Key Hash, if present, shall be computed as described in 9.6.4.3.”

Repo: crates/rtps/src/header_extension.rs (HeTimestamp); crates/rtps/src/submessages.rs (InfoTimestampSubmessage)

Status: done — seconds und fraction sind je ein unsigned long (HeTimestamp::seconds: u32), 4 + 4 Oktette in der Byte-Reihenfolge der Submessage; Sekundenwerte ab 2^31 bleiben positiv (der Test roundtrip_all_fields_set_be nutzt 0xFFFF_FFFD). §9.4.2.9 zeigt long seconds; es gilt die Struktur aus §9.3.2.1.

§9.3.2.1 Time_t: reservierte Werte und vorzeichenlose Sekunden

Spec: §9.3.2.1, S. 153 — “TIME_ZERO: seconds = 0, fraction = 0; TIME_INVALID: seconds = 0xffffffff, fraction = 0xffffffff; TIME_INFINITE: seconds = 0xffffffff, fraction = 0xfffffffe”.

Repo: crates/dcps/src/time.rs (time_to_he_timestamp, he_timestamp_to_time); crates/rtps/src/header_extension.rs (HeTimestamp, TIME_INVALID)

Status: done — Time::INVALID geht als {0xffffffff, 0xffffffff} und Time::INFINITE als {0xffffffff, 0xfffffffe} auf die Leitung und wird so zurückgelesen; HeTimestamp::seconds ist u32, TIME_INVALID hat Sekunden 0xFFFFFFFF. Die Aufrufer in dcps, xrce-agent und opcua-bridge sind angepasst (cargo check --tests und clippy grün). Ob ein anderer Hersteller die Sonderwerte als Quellzeitstempel sendet, ist nicht geprüft.

§9.3.2.1 Duration_t, DURATION_ZERO, DURATION_INFINITE

Spec: §9.3.2.1, S. 153 — “DURATION_ZERO: seconds = 0, fraction = 0; DURATION_INFINITE: seconds = 0x7fffffff, fraction = 0xffffffff; struct Duration_t { long seconds; unsigned long fraction; };”

Repo: crates/qos/src/duration.rs (Duration::INFINITE, Duration::ZERO)

Tests: crates/qos/src/duration.rs::tests::infinite_constant_matches_spec, crates/qos/src/duration.rs::tests::zero_is_default_and_zero

Status: done

§9.3.2.1 VendorId_t und VENDORID_UNKNOWN

Spec: §9.3.2.1, S. 153 — “VENDORID_UNKNOWN: VendorId_t[0] = 0, VendorId_t[1] = 0; typedef octet VendorId_t[2];”

Repo: crates/rtps/src/wire_types.rs (VendorId, VendorId::UNKNOWN)

Tests: crates/rtps/src/wire_types.rs::tests::vendor_id_unknown_is_two_zero_octets, crates/rtps/src/wire_types.rs::tests::vendor_id_roundtrip

Status: done

§9.3.2.1 SEQUENCENUMBER_UNKNOWN

Spec: §9.3.2.1, S. 153 — “SEQUENCENUMBER_UNKNOWN: high = -1, low = 0”.

Repo: crates/rtps/src/wire_types.rs (SequenceNumber::UNKNOWN)

Tests: crates/rtps/src/wire_types.rs::tests::sequence_number_unknown_high_minus_one_low_zero

Status: done

§9.3.2.1 FragmentNumber_t

Spec: §9.3.2.1, S. 153 — “typedef unsigned long FragmentNumber_t;”

Repo: crates/rtps/src/wire_types.rs (FragmentNumber(u32))

Tests: crates/rtps/src/wire_types.rs::tests::fragment_number_roundtrip_le_be, crates/rtps/src/wire_types.rs::tests::fragment_number_wire_size_is_four

Status: done

Spec: §9.3.2.1, S. 154 — “struct Property_t { string name; string value; }; typedef string EntityName_t;”

Repo: crates/rtps/src/property_list.rs (WirePropertyList)

Tests: crates/rtps/src/property_list.rs::tests::single_property_roundtrip_le, crates/rtps/src/property_list.rs::tests::multi_property_roundtrip_be

Status: done — EntityName_t (PID_ENTITY_NAME) ist unter §9.6.3.2 geführt.

§9.3.2.1 OriginalWriterInfo_t

Spec: §9.3.2.1, S. 154 — “struct OriginalWriterInfo_t { GUID_t originalWriterGUID; SequenceNumber_t originalWriterSN; ParameterList originalWriterQos; };”

Repo: crates/rtps/src/inline_qos.rs (original_writer_info_param, find_original_writer_info)

Status: done — das Leitungsbild des Parameters sind originalWriterGUID und originalWriterSN, 24 Oktette (§9.6.4.7, Table 8.89 nennt dieselben zwei Attribute); originalWriterQos aus der IDL-Struktur hat in Leitungsbild und Table 8.89 keine Entsprechung. Sende- und Empfangspfad sind unter §8.7.9 done.

§9.3.2.1 GroupDigest_t

Spec: §9.3.2.1, S. 155 — “typedef octet GroupDigest_t[4];”

Repo: crates/rtps/src/group_digest.rs (GroupDigest, GroupDigest::of_entities)

Status: done

§9.3.2.1 BuiltinEndpointSet_t (IDL)

Spec: §9.3.2.1, S. 155 — “bitmask BuiltinEndpointSet_t { @position(0) DISC_BUILTIN_ENDPOINT_PARTICIPANT_ANNOUNCER, … @position(29) DISC_BUILTIN_ENDPOINT_TOPICS_DETECTOR };”

Repo: crates/rtps/src/participant_data.rs (endpoint_flag)

Tests: crates/rtps/src/participant_data.rs::tests::endpoint_flag_bit_positions_match_spec

Status: done — die Positionen sind unter §9.3.2.12 einzeln geführt.

§9.3.2.1 BuiltinEndpointQos_t

Spec: §9.3.2.1, S. 155 — “bitmask BuiltinEndpointQos_t { @position(0) BEST_EFFORT_PARTICIPANT_MESSAGE_DATA_READER };”

Repo: crates/rtps/src/participant_data.rs (builtin_endpoint_qos::BEST_EFFORT_PARTICIPANT_MESSAGE_DATA_READER)

Status: done — Bitmaske mit @position(0) BEST_EFFORT_PARTICIPANT_MESSAGE_DATA_READER.

§9.3.2.1 ProtocolId_t (PROTOCOL_RTPS)

Spec: §9.3.2.1, S. 155 — “PROTOCOL_RTPS: ProtocolId_t[0] = ‘R’ … ProtocolId_t[3] = ‘S’; typedef octet ProtocolId_t[4];”

Repo: crates/rtps/src/header.rs (RTPS_MAGIC)

Tests: crates/rtps/src/header.rs::tests::header_layout_first_four_bytes_are_rtps_magic

Status: done

Spec: §9.3.2.4, S. 156 — “0x00000003 - 0x01ffffff (inclusive) are reserved for vendor-specific Locator_t kinds … 0x02000000 - 0x02ffffff (inclusive) are reserved for future use by the RTPS specification … 0x03000000 and greater are reserved for Locator_t kinds that identify a transport developed by a third-party”.

Status: done — alle Arten außer UDPv4 (1) und UDPv6 (2) liegen im Herstellerbereich 3 bis 0x01ffffff: Shm, Uds, Tsn (0x01F0_0001 bis 0x01F0_0003) und jetzt auch Tcpv4 (0x01F0_0004) und Tcpv6 (0x01F0_0005). Die Werte 4 und 8 von Fast DDS (und der DDS-TCP-PSM) sendet ZeroDDS nur mit der benannten Einstellung transport.tcp_locator_kinds: fast-dds (Umgebung ZERODDS_TCP_LOCATOR_KINDS, Man-Seite, Beispielkonfiguration); gelesen werden beide Werte. Eine Art, die der Empfänger nicht kennt, macht eine INFO_REPLY nicht ungültig, der Locator entfällt. Erwartetes Verhalten von Fast DDS: mit fast-dds erkennt es die TCP-Locatoren von ZeroDDS (Art 4 und 8); ohne die Einstellung ignoriert es die Arten im Herstellerbereich und baut keine TCP-Verbindung zu ZeroDDS auf. Nicht gemessen.

Repo: crates/rtps/src/wire_types.rs (SequenceNumber::to_bytes_le, to_bytes_be)

Tests: crates/rtps/src/wire_types.rs::tests::sequence_number_roundtrip_le, crates/rtps/src/wire_types.rs::tests::sequence_number_roundtrip_be

Status: done

§9.4.2.6 SequenceNumberSet: Struktur und Leitungsbild

Spec: §9.4.2.6, S. 160–161 — “struct SequenceNumberSet { SequenceNumber_t bitmapBase; LongSeq8 bitmap; };” Leitungsbild: bitmapBase, unsigned long numBits, long bitmap[M] mit “M = (numBits+31)/32”. “The numBits field encodes both the number of significant bits and the number of bitmap elements.”

Repo: crates/rtps/src/submessages.rs (SequenceNumberSet::write_to, read_from)

Status: done

§9.4.2.6 SequenceNumberSet: Zugehörigkeit nach Bitposition

Spec: §9.4.2.6, S. 160 — “(bitmap[deltaN/ 32] & (1 << (31 - deltaN%32))) == (1 << (31 - deltaN%32)) where deltaN = seqNum - seqNumSet.bitmapBase”; “In the bitmap, the bit corresponding to sequence number bitmapBase is on the left.”

Repo: crates/rtps/src/submessages.rs (SequenceNumberSet::from_missing, iter_set: Bit 31 - offset % 32)

Tests: crates/rtps/tests/proptest_roundtrip.rs::seqnum_set_iter_matches_missing, crates/rtps/src/submessages.rs::tests::snset_roundtrip_le

Status: done

§9.4.2.6 SequenceNumberSet: Gültigkeit

Spec: §9.4.2.6, S. 160 — “A valid SequenceNumberSet must satisfy the following conditions: bitmapBase >= 1; 0 <= numBits <= 256; there are M=(numBits+31)/32 longs containing the pertinent bits”.

Repo: crates/rtps/src/submessages.rs (SequenceNumberSet::read_from)

Tests: crates/rtps/src/submessages.rs::validity_tests::gap_and_sequence_number_set_validity_rules, crates/rtps/src/submessages.rs::tests::seqnumset_rejects_num_bits_above_256, crates/rtps/src/submessages.rs::tests::snset_decode_rejects_truncated_bitmap, crates/rtps/tests/vendor_frames.rs::the_empty_acknack_of_opendds_and_rti_is_invalid_by_default, crates/rtps/tests/vendor_frames.rs::opendds_session_re_encodes_byte_for_byte, crates/rtps/tests/vendor_frames.rs::rti_session_re_encodes_byte_for_byte, crates/rtps/src/submessages.rs::validity_tests::the_empty_set_with_base_zero_is_accepted_only_on_request

Status: done — bitmapBase >= 1, numBits <= 256 und die Zahl der Bitmap-Wörter werden geprüft. Vendor-Form: OpenDDS 3.34.0 und RTI Connext 7.7.0 senden als ACKNACK eines Readers ohne Samples readerSNState 0/0: (bitmapBase 0, numBits 0; gemessen in tools/wire-capture/rtps-sessions: 40 und 8 ACKNACK). Standard: ungültig. Die Einstellung wire.accept_empty_acknack_base_zero (Env ZERODDS_WIRE_ACCEPT_EMPTY_ACKNACK_BASE_ZERO, Standard false) nimmt genau diese leere Menge in einem ACKNACK an, prozessweit.

§9.4.2.6 Table 9.5 Beispiel 1234/12:00110

Spec: §9.4.2.6, S. 161, Table 9.5 — “Example of bitmap: meaning of “1234/12:00110””.

Repo: crates/rtps/src/submessages.rs (SequenceNumberSet: iter_set, write_to, read_from)

Tests: crates/rtps/src/submessages.rs::tests::the_bitmap_1234_12_00110_of_table_9_5_names_1236_and_1237

Status: done — bitmapBase 1234, numBits 12, Bits 00110: die Nummern 1236 und 1237 sind gesetzt, 1234, 1235 und 1238 bis 1245 nicht; das Bit für bitmapBase steht links (höchstwertiges Bit des ersten Worts). Der Test schreibt und liest das Beispiel in beiden Byte-Reihenfolgen.

§9.4.2.7 FragmentNumber

Spec: §9.4.2.7, S. 161 — “typedef FragmentNumber_t FragmentNumber;” Leitungsbild unsigned long value.

Repo: crates/rtps/src/wire_types.rs (FragmentNumber::to_bytes_le)

Tests: crates/rtps/src/wire_types.rs::tests::fragment_number_roundtrip_le_be

Status: done

§9.4.2.8 FragmentNumberSet: Struktur und Leitungsbild

Spec: §9.4.2.8, S. 161–162 — “struct FragmentNumberSet { FragmentNumber_t bitmapBase; LongSeq8 bitmap; };” “The interpretation matches that of a SequenceNumberSet.” Leitungsbild: bitmapBase, numBits, long bitmap[M].

Repo: crates/rtps/src/submessages.rs (FragmentNumberSet::write_to, read_from)

Status: done

§9.4.2.8 FragmentNumberSet: Gültigkeit

Spec: §9.4.2.8, S. 162 — “The interpretation matches that of a SequenceNumberSet.” (§9.4.2.6: “bitmapBase >= 1”, “0 <= numBits <= 256”).

Repo: crates/rtps/src/submessages.rs (FragmentNumberSet::read_from)

Tests: crates/rtps/src/submessages.rs::validity_tests::fragment_submessages_validity_rules, crates/rtps/src/submessages.rs::tests::fnset_rejects_num_bits_above_256

Status: done — bitmapBase >= 1 und numBits <= 256 werden geprüft.

§9.4.2.9 Timestamp

Spec: §9.4.2.9, S. 162 — “typedef Time_t Timestamp;” Leitungsbild long seconds, unsigned long fraction.

Repo: crates/rtps/src/submessages.rs (InfoTimestampSubmessage, timestamp_body)

Tests: crates/rtps/src/submessages.rs::tests::info_timestamp_roundtrip_le, crates/rtps/src/submessages.rs::tests::info_timestamp_roundtrip_be

Status: done — HeTimestamp::seconds ist i32 wie im Leitungsbild; §9.3.2.1 nennt unsigned long seconds (open-Item unter §9.3.2.1 Time_t).

Spec: §9.4.2.11, S. 165, Table 9.7 — “DDS-XTypes 1.2 — 0x0069; 0x0072-0x0075; 0x3f01-0x3fff; 0x7f01-0x7fff”.

Repo: crates/rtps/src/parameter_list.rs (pid::IGNORE = 0x3F03, PID_DATA_REPRESENTATION, PID_TYPE_CONSISTENCY, PID_TYPE_INFORMATION)

Tests: crates/rtps/src/parameter_list.rs::tests::pid_ignore_skipped_in_pl_cdr_decode, crates/discovery/tests/vendor_discovery_frames.rs::cyclone_announcements_read_and_write_back

Status: done

§9.4.2.11 Fehlender PID: Vorgabewert; unbekannter PID nach Table 9.6

Spec: §9.4.2.11, S. 165 — “If a ParameterId is expected, but not present, the protocol will assume the default value. Similarly, if a ParameterId is present but not recognized, the protocol will either skip and ignore the parameter or treat the parameter as an incompatible QoS.”

Repo: crates/rtps/src/publication_data.rs, crates/rtps/src/subscription_data.rs, crates/rtps/src/participant_data.rs

Status: done — die Vorgabe je PID ist unter §9.6.3.2 geführt, das Must-Understand-Verhalten unter Table 9.6.

§9.4.2.12 SerializedPayload

Spec: §9.4.2.12, S. 165 — “For the purpose of interoperability, all implementations must however use a consistent representation (See, 10 Serialized Payload Representation).”

Repo: —

Tests: —

Status: n/a (informative) — Verweis; die Darstellung ist unter §10 geführt.

§9.4.2.13 Count

Spec: §9.4.2.13, S. 166 — “typedef Count_t Count;” Leitungsbild long value.

Repo: crates/rtps/src/submessages.rs (count: i32)

Tests: crates/rtps/src/submessages.rs::tests::acknack_submessage_roundtrip_le, crates/rtps/src/submessages.rs::tests::nack_frag_roundtrip_be

Status: done

§9.4.2.14 ChangeCount

Spec: §9.4.2.14, S. 166 — “typedef ChangeCount_t ChangeCount;” Leitungsbild long high, unsigned long low (8 Oktette).

Repo: —

Tests: crates/rtps/src/submessages.rs::tests::gap_filtered_count_is_eight_octets_high_then_low, crates/rtps/src/submessages.rs::tests::gap_with_filtered_count_roundtrip_le

Status: done

§9.4.2.15 Table 9.8 ChecksumFlags (0,0)

Spec: §9.4.2.15, S. 166, Table 9.8 — “0, 0 — N/A — The messageChecksum is not included in the HeaderExtension”.

Repo: crates/rtps/src/header_extension.rs (ChecksumKind::None)

§9.4.5.1.2 X-Flags: null senden, beim Empfang ignorieren

Spec: §9.4.5.1.2, S. 172 — “Implementations of RTPS version 2.5 should set these to zero when sending and ignore these when receiving.”

Repo: crates/rtps/src/submessages.rs (die Encoder setzen nur die definierten Flags; die Decoder lesen nur diese); crates/rtps/src/datagram.rs

Status: done — die Encoder von HEARTBEAT, ACKNACK, GAP, HEARTBEAT_FRAG, NACK_FRAG, INFO_TS, INFO_SRC, INFO_REPLY, INFO_REPLY_IP4 und DATA setzen nur E und die für die Submessage definierten Flags; die Decoder geben mit allen übrigen Flag-Bits gesetzt denselben Wert. Bei unbekannten Submessages gilt §8.3.4.1 Regel 3.

§9.4.5.1.3 octetsToNextHeader als ushort

Spec: §9.4.5.1.3, S. 172 — “The representation of this field is a CDR unsigned short (ushort).”

Repo: crates/rtps/src/submessage_header.rs (octets_to_next_header: u16)

Tests: crates/rtps/src/submessage_header.rs::tests::submessage_header_roundtrip_le

Status: done

§9.4.5.1.3 octetsToNextHeader > 0

Spec: §9.4.5.1.3, S. 172 — “In case octetsToNextHeader > 0, it is the number of octets from the first octet of the contents of the Submessage until the first octet of the header of the next Submessage … OR it is the number of octets remaining in the Message”.

Repo: crates/rtps/src/datagram.rs (decode_datagram: body_end)

Tests: crates/rtps/src/datagram.rs::tests::encode_decode_two_data_submessages, crates/rtps/src/datagram.rs::tests::pad_submessage_is_skipped_and_the_data_behind_it_still_decodes

Status: done

§9.4.5.1.3 octetsToNextHeader == 0 außer PAD und INFO_TS

Spec: §9.4.5.1.3, S. 172 — “In case octetsToNextHeader==0 and the kind of Submessage is NOT PAD or INFO_TS, the Submessage is the last Submessage in the Message and extends up to the end of the Message.”

Repo: crates/rtps/src/datagram.rs (decode_datagram)

Tests: crates/rtps/src/datagram.rs::tests::decode_handles_last_submessage_zero_length

Status: done

§9.4.5.1.3 octetsToNextHeader == 0 bei PAD und INFO_TS

Spec: §9.4.5.1.3, S. 172 — “In case the octetsToNextHeader==0 and the kind of Submessage is PAD or INFO_TS, the next Submessage header starts immediately after the current Submessage header OR the PAD or INFO_TS is the last Submessage in the Message.”

Repo: crates/rtps/src/datagram.rs (decode_datagram)

Tests: crates/rtps/src/datagram.rs::tests::an_info_ts_without_a_body_is_not_the_last_submessage, crates/rtps/src/datagram.rs::tests::pad_submessage_is_skipped_and_re_encoded_byte_for_byte

Status: done

Spec: §9.4.5.4, S. 175 — “D = SubmessageHeader.flags & 0x04”.

Repo: crates/rtps/src/submessages.rs (DATA_FLAG_DATA = 0x04)

Status: done

§9.4.5.4 Data KeyFlag (0x08)

Spec: §9.4.5.4, S. 175 — “K = SubmessageHeader.flags & 0x08”.

Repo: crates/rtps/src/submessages.rs (DATA_FLAG_KEY = 0x08)

Tests: crates/rtps/src/submessages.rs::tests::data_submessage_key_flag_roundtrip, crates/discovery/src/sedp/reader.rs::tests::handle_data_reports_a_cyclone_dispose_without_key_hash_as_removed

Status: done

§9.4.5.4 Data NonStandardPayloadFlag (0x10)

Spec: §9.4.5.4, S. 175 — “N = SubmessageHeader.flags & 0x10”.

Repo: crates/rtps/src/submessages.rs (DATA_FLAG_NON_STANDARD = 0x10)

Tests: crates/rtps/src/submessages.rs::tests::data_submessage_non_standard_flag_roundtrip

Status: done

Spec: §9.4.5.6, S. 177 — “F = SubmessageHeader.flags & 0x04”.

Repo: crates/rtps/src/submessages.rs (GAP_FLAG_FILTERED_COUNT = 0x04)

Tests: crates/rtps/src/submessages.rs::tests::the_gap_flags_are_those_of_9_4_5_6

Status: done

§9.4.5.6 Gap gapStartGSN und gapEndGSN

Spec: §9.4.5.6, S. 177 — “G=1 means the Gap also includes a gapStartGSN and a gapEndGSN.”

Repo: —

Status: done

§9.4.5.7 Heartbeat: Leitungsbild

Spec: §9.4.5.7, S. 178 — HEARTBEAT |X|X|X|X|G|L|F|E|, readerId, writerId, firstSN, lastSN, Count count, currentGSN/firstGSN/lastGSN [G].

Repo: crates/rtps/src/submessages.rs (HeartbeatSubmessage::write_body, read_body)

Tests: crates/rtps/src/submessages.rs::tests::heartbeat_submessage_roundtrip_le, crates/rtps/tests/cyclone_compliance.rs::cyclone_heartbeat_decodes

Status: done — der Teil nach count ist unter „Heartbeat: Group-Felder“ geführt.

§9.4.5.7 Heartbeat FinalFlag (0x02)

Spec: §9.4.5.7, S. 178 — “F = SubmessageHeader.flags & 0x02”.

Repo: crates/rtps/src/submessages.rs (HEARTBEAT_FLAG_FINAL = 0x02)

Tests: crates/rtps/src/datagram.rs::tests::decode_heartbeat_preserves_final_and_liveliness_flags

Status: done

§9.4.5.7 Heartbeat LivelinessFlag (0x04)

Spec: §9.4.5.7, S. 178 — “L = SubmessageHeader.flags & 0x04”.

Repo: crates/rtps/src/submessages.rs (HEARTBEAT_FLAG_LIVELINESS = 0x04)

Tests: crates/rtps/src/submessages.rs::tests::heartbeat_submessage_liveliness_flag_roundtrip, crates/rtps/src/datagram.rs::tests::decode_heartbeat_preserves_final_and_liveliness_flags

Status: done

§9.4.5.7 Heartbeat GroupInfoFlag (0x08)

Spec: §9.4.5.7, S. 178 — “G = SubmessageHeader.flags & 0x08”.

Repo: crates/rtps/src/submessages.rs (HEARTBEAT_FLAG_GROUP_INFO = 0x08)

Tests: crates/rtps/src/submessages.rs::tests::heartbeat_with_group_info_roundtrip_le, crates/rtps/src/submessages.rs::tests::the_group_info_is_the_three_sequence_numbers_of_9_4_5_7

Status: done

Spec: §9.4.5.12, S. 180 — “I = SubmessageHeader.flags & 0x02”.

Repo: crates/rtps/src/submessages.rs (INFO_TIMESTAMP_FLAG_INVALIDATE = 0x02)

Status: done

§9.4.5.13 Pad: Leitungsbild

Spec: §9.4.5.13, S. 180–181 — PAD |X|X|X|X|X|X|X|E| octetsToNextHeader.

Repo: crates/rtps/src/datagram.rs (decode_datagram: PAD wird übersprungen)

Tests: crates/rtps/src/datagram.rs::tests::pad_submessage_is_skipped_and_re_encoded_byte_for_byte

Status: done

§9.4.5.14 NackFrag: Leitungsbild

Spec: §9.4.5.14, S. 181 — NACK_FRAG |X|X|X|X|X|X|X|E|, readerId, writerId, writerSN, FragmentNumberSet fragmentNumberState, count.

Repo: crates/rtps/src/submessages.rs (NackFragSubmessage)

Tests: crates/rtps/src/submessages.rs::tests::nack_frag_roundtrip_le, crates/rtps/src/datagram.rs::tests::decode_nack_frag_roundtrip

Status: done

§9.4.5.15 InfoReplyIp4: Leitungsbild

Spec: §9.4.5.15, S. 181 — INFO_REPLY_IP4 |X|X|X|X|X|X|M|E|, LocatorUDPv4 unicastLocator, LocatorUDPv4 multicastLocator [M]. “Its use and interpretation are identical to those of an InfoReply Submessage containing a single unicast and possibly a single multicast locator”.

Repo: crates/rtps/src/submessages.rs (InfoReplyIp4Submessage)

Status: done — Aufbau (Unicast-LocatorUDPv4, mit M-Flag ein Multicast-LocatorUDPv4), Flags (E, M) und Wirkung stimmen; die Adresse folgt LocatorUDPv4 (Item unter §9.4.3.1).

§9.4.5.15 InfoReplyIp4 MulticastFlag (0x02)

Spec: §9.4.5.15, S. 182 — “M = SubmessageHeader.flags & 0x02”.

Repo: crates/rtps/src/submessages.rs (InfoReplyIp4Submessage::write_body, read_body)

Tests: crates/rtps/src/submessages.rs::tests::info_reply_ip4_with_multicast_roundtrip_be

Status: done

§9.5 Eine Nachricht je UDP-Datagramm

Spec: §9.5, S. 182 — “When RTPS is used over UDP/IP, a Message is the contents (payload) of exactly one UDP/IP Datagram.”

Repo: crates/transport-udp/src/udp_transport.rs (UdpTransport)

Tests: crates/transport-udp/tests/e2e.rs::e2e_write_udp_read_single_datagram, crates/transport-udp/src/udp_transport.rs::tests::without_the_cache_a_largest_datagram_arrives

Status: done

Spec: §9.6.2.3, S. 183 — “Implementations must expose these parameters so they can be customized by the user.”

Status: done — PB, DG, PG und d0 bis d3 sind Einstellungen (Datei und Umgebung, 0..=65535, Vorgabe die Spec-Werte). Der Runtime bindet die Discovery-Ports (d0, d1) und den Nutzer-Unicast-Socket auf PB + DG * domainId + d3 + PG * participantId mit der participantId des SPDP-Unicast-Sockets; ist der Port belegt, nimmt der Socket einen flüchtigen Port, das wird gezählt (user_port_fallbacks) und als Ereignis transport.user_unicast.port_taken protokolliert. Der Nutzer-Multicast-Port d2 wird mit transport.user_multicast gebunden (Beitritt zur SPDP-Gruppe, Empfang, Ankündigung als Default-Multicast-Locator); Vorgabe an (die Default-Locators von §9.6.2.3 enthalten d2), false für einen Host ohne Multicast. Gemessen in tools/wire-capture/rtps-sessions (Locators der SPDP-Ankündigungen): Fast DDS 2.6.10 und RTI 7.7.0 binden d1/d3 + PG * participantId (Fast DDS 23160/23161, 23162/23163; RTI 22910/22911, 22912/22913); Cyclone 11.0.1 nimmt flüchtige Ports für Metatraffic und Nutzerdaten (derselbe Port) und kündigt Default-Multicast 239.255.0.1 auf d2 an; OpenDDS 3.34.0 nimmt einen flüchtigen Metatraffic-Port und kündigt als Nutzer-Locator 127.0.0.1:12345 an (kein d3-Port). Nicht gemessen: ein Lauf gegen die Hersteller mit der Port-Änderung und das Verhalten von ZeroDDS-Writern gegenüber angekündigten Multicast-Locators (sie senden nur an Unicast-Locators).

§9.6.2.4 Default-Multicast-Adresse 239.255.0.1

Spec: §9.6.2.4, S. 183 — “DefaultMulticastLocator = {LOCATOR_KIND_UDPv4, “239.255.0.1”, PB + DG * domainId + d0}. All Participants must announce and listen on this multicast address.”

Repo: crates/rtps/src/wire_types.rs (SPDP_DEFAULT_MULTICAST_ADDRESS); crates/dcps/src/runtime.rs (spdp_multicast_group, Beitritt und Ankündigung)

Tests: crates/rtps/src/wire_types.rs::tests::spdp_default_multicast_is_239_255_0_1, crates/discovery/tests/spdp_loopback_e2e.rs::loopback_multicast_self_discovery

Status: done — die Gruppe ist einstellbar; ohne Multicast arbeitet ZeroDDS mit Initial-Peers.

§9.6.2.4 Default-Ankündigungsrate 30 Sekunden

Spec: §9.6.2.4, S. 183 — “The default rate by which SPDP periodic announcements are sent equals 30 seconds. SPDPbuiltinParticipantWriter. resendPeriod = {30, 0};”

Spec: §9.6.3.2, S. 185 — “As this is a vendor-specific parameterId, other vendors’ implementations would simply ignore the parameter and the information it contains.”

Repo: crates/rtps/src/publication_data.rs (Herstellerparameter nach VendorId)

Tests: crates/rtps/src/publication_data.rs::tests::a_foreign_vendors_0x8002_is_not_read_as_a_type_identifier

Status: done

§9.6.3.2 Keine redundanten Parameter

Spec: §9.6.3.2, S. 185 — “For optimization, implementations of the protocol shall not include a parameter in the Data submessage if it contains information that is redundant with other parameters already present in that same Data submessage.”

Repo: crates/rtps/src/participant_data.rs, crates/rtps/src/publication_data.rs, crates/rtps/src/subscription_data.rs

Tests: crates/rtps/src/participant_data.rs::tests::participant_data_roundtrip_full, crates/rtps/src/publication_data.rs::tests::roundtrip_le

Status: done — die einzelnen Fälle stehen unter Table 9.17.

§9.6.3.2 Table 9.17 SPDPdiscoveredParticipantData: ParticipantProxy::guidPrefix

Spec: §9.6.3.2, S. 185, Table 9.17 — “SPDPdiscoveredParticipantData — ParticipantProxy::guidPrefix — ParticipantBuiltinTopicData::key”.

Repo: crates/rtps/src/participant_data.rs (to_pl_cdr_le: nur PID_PARTICIPANT_GUID)

Tests: crates/rtps/src/participant_data.rs::tests::participant_data_decode_requires_guid_pid

Status: done

§9.6.3.2 Table 9.17 DiscoveredReaderData: ReaderProxy::remoteReaderGuid

Spec: §9.6.3.2, S. 185, Table 9.17 — “DiscoveredReaderData — ReaderProxy::remoteReaderGuid — SubscriptionBuiltinTopicData::key”.

Repo: crates/rtps/src/subscription_data.rs (to_pl_cdr_le: nur PID_ENDPOINT_GUID)

Tests: crates/rtps/src/subscription_data.rs::tests::roundtrip_le

Status: done

§9.6.3.2 Table 9.17 DiscoveredWriterData: WriterProxy::remoteWriterGuid

Spec: §9.6.3.2, S. 186, Table 9.18 — “PID_TYPE_NAME — 0x0007 — string<256>”; Table 9.19, S. 187 — TopicBuiltinTopicData, Publication/Subscription type_name, Vorgabe N/A.

Repo: crates/rtps/src/parameter_list.rs (pid::TYPE_NAME); crates/rtps/src/publication_data.rs, crates/rtps/src/subscription_data.rs, crates/rtps/src/topic_data.rs

Status: done

§9.6.3.2 string<256> für Namen und domainTag

Spec: §9.6.3.2, S. 186, Table 9.18 — PID_TOPIC_NAME, PID_TYPE_NAME, PID_DOMAIN_TAG: “string<256>”.

Status: done — Topic-, Typ- und domainTag-Namen sind auf 256 Oktette begrenzt: Senden und Lesen weisen mehr ab (die Ankündigung eines Peers mit längerem Namen wird abgewiesen und gezählt), create_topic und DcpsRuntime::start lehnen sie ab.

§9.6.3.2 Table 9.18/9.19 PID_GROUP_DATA

Spec: §9.6.3.2, S. 186, Table 9.18 — “PID_GROUP_DATA — 0x002d — GroupDataQosPolicy”; Table 9.19, S. 187 — Publication/Subscription group_data.

Repo: crates/qos/src/pid.rs (Pid::GROUP_DATA); crates/rtps/src/publication_data.rs, crates/rtps/src/subscription_data.rs

Status: done

Spec: §9.6.3.2, S. 186, Table 9.18 — “PID_DEADLINE — 0x0023 — DeadlineQosPolicy”; Table 9.19, S. 188 — Topic, Publication, Subscription deadline.

Repo: crates/qos/src/pid.rs (Pid::DEADLINE)

Status: done

§9.6.3.2 Table 9.18/9.19 PID_LATENCY_BUDGET

Spec: §9.6.3.2, S. 186, Table 9.18 — “PID_LATENCY_BUDGET — 0x0027 — LatencyBudgetQosPolicy”; Table 9.19, S. 188 — Topic, Publication, Subscription latency_budget.

Repo: crates/qos/src/pid.rs (Pid::LATENCY_BUDGET)

Status: done

§9.6.3.2 Table 9.18/9.19 PID_LIVELINESS

Spec: §9.6.3.2, S. 186, Table 9.18 — “PID_LIVELINESS — 0x001b — LivelinessQosPolicy”; Table 9.19, S. 188 — Topic, Publication, Subscription liveliness.

Repo: crates/qos/src/pid.rs (Pid::LIVELINESS)

Status: done

Spec: §9.6.3.2, S. 186, Table 9.18 — “PID_OWNERSHIP — 0x001f — OwnershipQosPolicy”; Table 9.19, S. 188 — Topic, Publication, Subscription ownership.

Repo: crates/qos/src/pid.rs (Pid::OWNERSHIP)

Status: done

§9.6.3.2 Table 9.18/9.19 PID_OWNERSHIP_STRENGTH

Spec: §9.6.3.2, S. 186, Table 9.18 — “PID_OWNERSHIP_STRENGTH — 0x0006 — OwnershipStrengthQosPolicy”; Table 9.19, S. 188 — PublicationBuiltinTopicData::ownership_strength.

Repo: crates/qos/src/pid.rs (Pid::OWNERSHIP_STRENGTH)

Tests: crates/rtps/tests/sedp_qos_roundtrip.rs::publication_data_roundtrip_preserves_all_new_qos_policies

Status: done

§9.6.3.2 Table 9.18/9.19 PID_PRESENTATION

Spec: §9.6.3.2, S. 186, Table 9.18 — “PID_PRESENTATION — 0x0021 — PresentationQosPolicy”; Table 9.19, S. 188 — Publication, Subscription presentation.

Repo: crates/qos/src/pid.rs (Pid::PRESENTATION)

Status: done

Repo: crates/rtps/src/parameter_list.rs (pid::EXPECTS_INLINE_QOS); crates/rtps/src/participant_data.rs, crates/rtps/src/subscription_data.rs

Status: done

Spec: §9.6.3.2, S. 187, Table 9.18 — “PID_BUILTIN_ENDPOINT_QOS — 0x0077 — BuiltinEndpointQos_t”; Table 9.19, S. 189 — ParticipantProxy::builtinEndpointQos.

Repo: crates/rtps/src/parameter_list.rs (pid::BUILTIN_ENDPOINT_QOS); crates/rtps/src/participant_data.rs

Status: done — gelesen, geschrieben und in is_standard_pid.

§9.6.3.2 Table 9.18 PID_PROPERTY_LIST

Spec: §9.6.3.2, S. 187, Table 9.18 — “PID_PROPERTY_LIST — 0x0059 — sequence”. Table 9.19 führt keine Zeile dafür.

Repo: crates/rtps/src/parameter_list.rs (pid::PROPERTY_LIST); crates/rtps/src/participant_data.rs (properties); crates/rtps/src/property_list.rs (WirePropertyList::decode)

Status: done — gesendet in SPDP und, wo ein Endpoint Properties hat, in SEDP, in der Form von DDS-Security 1.2 §7.5.1.4 (mit binary_value). Gelesen werden beide Formen; eine Liste, die nach ihren Properties endet (diese Zeile), hat keine binären Einträge.

§9.6.3.2 Table 9.18/9.19 PID_TYPE_MAX_SIZE_SERIALIZED

Spec: §9.6.3.2, S. 187, Table 9.18 — “PID_TYPE_MAX_SIZE_SERIALIZED — 0x0060 — long”; Table 9.19, S. 189 — “PID_DATA_MAX_SIZE_SERIALIZED — WriterProxy::dataMaxSizeSerialized”.

Repo: crates/rtps/src/publication_data.rs (data_max_size_serialized)

Status: done — Publications senden und lesen den PID als long (PublicationBuiltinTopicData::data_max_size_serialized); in vendor_discovery_frames.rs ist 0x0060 nicht mehr unter den verworfenen PIDs. Gemessen in tools/wire-capture/rtps-sessions/rti: RTI 7.7.0 kündigt den Wert 8 an, und das DATA seines Writers trägt ein SerializedPayload von 8 Oktetten, den Encapsulation-Header eingerechnet; der Wert zählt also wie die Spec mit Header. Fast DDS 2.6.10 kündigt 12, 32 und 52 an (kein Nutzer-DATA im Mitschnitt); Cyclone und OpenDDS kündigen den PID nicht an. Ein Reader weist ein Payload ab, das den genannten Wert überschreitet. Nicht gemessen: ein Lauf gegen die Hersteller mit diesem Abweis.

§9.6.3.2 Table 9.18 PID_ENTITY_NAME

Spec: §9.6.3.2, S. 187, Table 9.18 — “PID_ENTITY_NAME — 0x0062 — EntityName_t”. Table 9.19 führt keine Zeile dafür.

Status: done — Participant, Writer und Reader senden und lesen PID_ENTITY_NAME als EntityName_t (CDR-String). Die DCPS-API hat keine EntityName-QoS; die Namen sind gebaut: Participant zerodds: und das GUID-Präfix in Hex (überschreibbar mit discovery.participant_name), Writer und Reader DataWriter:<Topic>:<EntityId hex> bzw. DataReader:…. UserWriterConfig::entity_name und UserReaderConfig::entity_name nehmen einen gesetzten Namen. Ein nicht lesbarer Name (kein gültiger CDR-String) verwirft die Ankündigung wie ein nicht lesbarer domainTag.

§9.6.3.2 Table 9.18/9.19 PID_ENDPOINT_GUID

Spec: §9.6.3.2, S. 187, Table 9.18 — “PID_ENDPOINT_GUID — 0x005a — GUID_t”; Table 9.19, S. 189 — Topic-, Subscription-, PublicationBuiltinTopicData::key.

Repo: crates/rtps/src/parameter_list.rs (pid::ENDPOINT_GUID); crates/rtps/src/publication_data.rs, crates/rtps/src/topic_data.rs

Tests: crates/rtps/src/publication_data.rs::tests::decode_rejects_missing_endpoint_guid, crates/discovery/src/sedp/stack.rs::tests::two_stacks_exchange_a_topic_its_new_qos_and_its_dispose

Status: done

Spec: §9.6.4, S. 190, Table 9.20 — “PID_COHERENT_SET — 0x0056 — SequenceNumber_t”.

Repo: crates/rtps/src/parameter_list.rs (pid::COHERENT_SET); crates/rtps/src/inline_qos.rs (coherent_set_inline_qos, find_coherent_set)

Tests: crates/rtps/src/inline_qos.rs::tests::coherent_set_param_is_pid_0x0056_with_sequence_number_layout, crates/rtps/src/inline_qos.rs::tests::coherent_set_roundtrip_both_endiannesses

Status: done

Spec: §9.6.4, S. 190, Table 9.20 — “PID_KEY_HASH — 0x0070 — KeyHash_t”.

Repo: crates/rtps/src/parameter_list.rs (pid::KEY_HASH); crates/rtps/src/inline_qos.rs (find_key_hash)

Tests: crates/rtps/src/submessages.rs::tests::data_frag_key_hash_roundtrips_both_byte_orders, crates/dcps/src/runtime.rs::tests::alive_sample_without_key_hash_gets_the_types_computed_hash

Status: done

§9.6.4 Table 9.20 PID_STATUS_INFO (0x0071)

Spec: §9.6.4, S. 190, Table 9.20 — “PID_STATUS_INFO — 0x0071 — StatusInfo_t”.

Repo: crates/rtps/src/parameter_list.rs (pid::STATUS_INFO); crates/rtps/src/inline_qos.rs (status_info_param, find_status_info)

Tests: crates/dcps/tests/lifecycle_wire_decode.rs::reader_push_lifecycle_disposed_sets_instance_state, crates/dcps/tests/lifecycle_wire_e2e.rs::linux::dispose_propagates_over_wire_to_reader

Status: done

§9.6.4.1 PID_CONTENT_FILTER_INFO: Leitungsbild, Bitmap, Signatur

Spec: §9.6.4.1, S. 191 — Leitungsbild numBitmaps, bitmaps, numSignatures, FilterSignature_t; “The content filter info in-line QoS is invalid unless numBitmaps == ([numSignatures/32] + (numSignatures%32 ? 1 : 0))”; “A filter’s signature is calculated as the 128-bit MD5 checksum of all strings in the filter’s ContentFilterProperty_t.”

Repo: —

Tests: —

Status: open — Teil der optionalen Filterung auf der Writer-Seite (§8.7.3), die ZeroDDS nicht ausführt.

§9.6.4.1 Table 9.21 filterResult

Spec: §9.6.4.1, S. 191, Table 9.21 — “0 — Sample was filtered by the corresponding filter and did not pass. 1 — Sample was filtered by the corresponding filter and passed.”

Spec: §9.6.4.5, S. 193 — “for DataWriters belonging to a Publisher with Presentation access scope GROUP, the Data submessages and the first DataFrag submessage of each sample shall contain the publisher writer info in-line QoS parameter. The End Coherent Set Data submessage … shall also contain the publisher writer info in-line QoS parameter.”

Repo: —

Status: done

§9.6.4.6 PID_SECURE_WRITER_GROUP_INFO

Spec: §9.6.4.6, S. 193 — “The secure publisher writer info in-line QoS is reserved for DDS Security. In the cases when it is used it shall be added anywhere that the PID_WRITER_GROUP_INFO in-line QoS is required.”

Status: done — unter DDS-Security (RuntimeConfig::security) senden Writer eines GROUP-Publishers PID_SECURE_WRITER_GROUP_INFO überall dort, wo sonst PID_WRITER_GROUP_INFO steht; ein Reader nimmt beide. Der Test mit Security-Laufzeit steht nicht in diesem Lauf (nur die Writer-Einstellung ist getestet).

§9.6.4.7 PID_ORIGINAL_WRITER_INFO: Leitungsbild

Spec: §9.6.4.7, S. 193 — Leitungsbild GUID_t originalWriterGUID, SequenceNumber originalWriterSN. “The original writer info parameter may appear in the Data or in the DataFrag submessages.”

Repo: crates/rtps/src/inline_qos.rs (original_writer_info_param, find_original_writer_info)

Tests: crates/rtps/src/inline_qos.rs::tests::original_writer_info_param_24_byte_layout_le, crates/rtps/src/inline_qos.rs::tests::original_writer_info_roundtrip_be, crates/rtps/src/inline_qos.rs::tests::table_9_20_directed_write_original_writer_info_and_secure_group_info

Status: done — das Leitungsbild stimmt (GUID_t, SequenceNumber_t); der Parameter wird in DATA und DATA_FRAG gesendet und ausgewertet (Items unter §8.7.9).

§9.6.4.8 KeyHash: 16 Oktette

Spec: §9.6.4.8, S. 193 — “The KeyHash_t is defined as a 16-Byte octet array (see 9.3.2) therefore the key hash inline parameter just copies those 16 Bytes.”

Repo: crates/dcps/src/key_hash.rs (KEY_HASH_LEN); crates/rtps/src/inline_qos.rs (find_key_hash)

Tests: crates/dcps/src/key_hash.rs::tests::a_holder_of_exactly_sixteen_is_the_hash, crates/rtps/src/submessages.rs::tests::data_frag_key_hash_roundtrips_both_byte_orders

Status: done

§9.6.4.8 KeyHash Schritt 1: FooKeyHolder

Spec: §9.6.4.8, S. 193–194 — “FooKeyHolder shall have extensibility kind ‘FINAL’ … If there are any key members, then remove the non-key members … Reorder the members in ascending order of their memberId values.”

Repo: crates/dcps/src/key_hash.rs (keyhash_cdr2_be: Sortierung nach member_id)

Tests: crates/dcps/src/key_hash.rs::tests::the_member_order_does_not_reach_the_hash

Status: done

§9.6.4.8 KeyHash Schritte 2 und 3: Werte und Rekursion

Spec: §9.6.4.8, S. 194 — “Step 2. … setting the members present in FooKeyHolderObject to the same values as the corresponding members in FooObject. Step 3. Apply steps 1 and 2 recursively to the members of FooKeyHolder if they are themselves Aggregated types”.

Repo: crates/dcps/src/key_hash.rs (PlainCdr2BeKeyHolder); crates/dcps/src/runtime.rs (reader_key_hash_context)

Status: done

§9.6.4.8 KeyHash Schritt 4: PLAIN_CDR2 Big Endian

Spec: §9.6.4.8, S. 194 — “Compute the PLAIN_CDR2 Big Endian Serialization … The serialization shall be performed on a buffer that is initially aligned to the maximum alignment in PLAIN_CDR2 (i.e., 4). Furthermore, any padding bytes added due to alignment rules shall be set to zero.”

Repo: crates/dcps/src/key_hash.rs (PlainCdr2BeKeyHolder)

Status: done

§9.6.4.8 KeyHash Schritt 5: Polsterung oder MD5 nach der Maximalgröße

Spec: §9.6.4.8, S. 194 — “Step 5.1 If the FooKeyHolder has a maximum serialized size that is less than or equal to 16 bytes, then the KeyHash of FooObject shall be set to the result of Step 4, extended to 16 bytes. … Step 5.2 If the FooKeyHolder has a maximum serialized size that is greater than 16 bytes, then the KeyHash_t of FooObject shall be set to the MD5 Hash”.

Repo: crates/dcps/src/key_hash.rs (compute_key_hash: key_holder_max_size)

Tests: crates/dcps/src/key_hash.rs::tests::a_short_instance_of_a_bounded_type_still_pads, crates/dcps/src/key_hash.rs::tests::a_holder_over_sixteen_is_hashed

Status: done

§9.6.4.8 KeyHash Beispiele 1 bis 3

Spec: §9.6.4.8, S. 194–196 — “Example 1 …”, “Example 2 …”, “Example 3 …” mit den erwarteten Oktetten.

Repo: crates/dcps/src/key_hash.rs (PlainCdr2BeKeyHolder, compute_key_hash); crates/dcps/src/dds_type.rs (DdsType::compute_key_hash)

Status: done — die drei Beispiele ergeben die Oktette der Spec: Beispiel 1 den mit Nullen auf 16 Oktette erweiterten Holder, Beispiel 2 und 3 den MD5 des 20- und des 13-Oktett-Holders (f91a59e3…, 374b96e2…).

§9.6.4.9 StatusInfo_t: 4 Oktette

Spec: §9.6.4.9, S. 196 — “The StatusInfo_t is defined as a 4-Byte octet array (see 9.3.2) therefore the status info inline parameter just copies those 4 Bytes.”

Repo: crates/rtps/src/inline_qos.rs (status_info_param: Netzreihenfolge; find_status_info)

Status: done

§9.6.4.9 StatusInfo in Data oder DataFrag

Spec: §9.6.4.9, S. 196 — “The status info parameter may appear in the Data or in the DataFrag submessages.”

Repo: crates/rtps/src/reliable_reader.rs (classify_change_kind für DATA, handle_data_frag_opening für DATA_FRAG)

Status: done — in DATA und in DATA_FRAG ausgewertet (Schlüssel mit D oder U als Dispose und Unregister, F als gefiltertes Sample).

§9.6.4.9 StatusInfo: X-Flags

Spec: §9.6.4.9, S. 197 — “The flags represented with the literal ‘X’ are unused by this version of the protocol and should be set to zero by the writer and not interpreted by the reader”.

Repo: crates/rtps/src/inline_qos.rs (status_info); crates/rtps/src/reliable_reader.rs (classify_change_kind: nur D und U)

Tests: crates/dcps/tests/lifecycle_wire_decode.rs::reader_push_lifecycle_disposed_sets_instance_state

Status: done

§9.6.4.9 StatusInfo DisposedFlag

Spec: §9.6.4.9, S. 197 — “D=1 indicates that the DDS DataWriter has disposed the instance of the data-object whose Key appears in the submessage.”

§10.1 Einleitung

Spec: §10.1, S. 199 — “The representation of the serialized application data is not part of the RTPS protocol. The RTPS protocol does not interpret the content of the SerializedPayload.”; “the content and format of the SerializedPayload is defined in sections 10.3 to 10.5.”

Repo: —

Tests: —

Status: n/a (informative) — Überblick; die Anforderungen stehen in §10.2 bis §10.5.

§10.2 SerializedPayloadHeader am Anfang jeder SerializedPayload

Spec: §10.2, S. 199 — “All SerializedPayload shall start with the SerializedPayloadHeader defined below.”; “The SerializedPayloadHeader occupies the first four octets of the SerializedPayload”.

Status: done

§10.2 SerializedPayloadHeader: Struktur

Spec: §10.2, S. 199 — “typedef octet RepresentationIdentifier[2]; typedef octet RepresentationOptions[2]; struct SerializedPayloadHeader { RepresentationIdentifier representation_identifier; RepresentationOptions representation_options; };”

Repo: crates/dcps/src/runtime.rs (user_encap_body, encap_representation, encap_big_endian)

Status: done

§10.2 RepresentationOptions im Zusammenhang des RepresentationIdentifier

Spec: §10.2, S. 199 — “The RepresentationOptions shall be interpreted in the context of the RepresentationIdentifier, such that each RepresentationIdentifier may define the representation_options that it requires.”

Repo: crates/dcps/src/runtime.rs (user_encap_body: die unteren zwei Bit als Zahl der angehängten Füll-Oktette nach DDS-XTypes 1.3 §7.6.3.1.2)

Tests: crates/dcps/src/runtime.rs::tests::strip_user_encap_drops_the_padding_the_options_name, crates/dcps/src/runtime.rs::tests::strip_user_encap_refuses_padding_the_body_cannot_hold

Status: done

§10.2 CDR-Strom beginnt nach representation_options

Spec: §10.2, S. 199 — “For alignment purposes, the CDR stream is logically reset at the position that follows the representation_options. Therefore, there should be no initial padding before the serialized data is added to the CDR stream.”

Repo: crates/dcps/src/runtime.rs (write_user_sample_pooled: Kopf und getrennt kodierter Körper; user_encap_body: Körper ab Oktett 4)

Tests: crates/dcps/src/interop.rs::tests::u64_type_xcdr1_and_xcdr2_alignment_differs, crates/dcps/src/runtime.rs::tests::strip_user_encap_xcdr1_le

Status: done

§10.2 Fußnote 5: ältere Versionen

Spec: §10.2, S. 199, Fußnote 5 — “Versions of the RTPS specification previous to version 2.4 did not clearly state where the CDR stream was reset for alignment purposes. Therefore implementations may need to take into account the vendor and protocol version when interpreting the Serialized Data.”

Repo: —

Tests: —

Status: n/a (informative) — Hinweis ohne Pflicht.

§10.3 Discovery-Builtin-Endpoints verwenden Table 10.1

Spec: §10.3, S. 200 — “The SerializedPayload for the data messages associated with built-in discovery endpoints shall use the RepresentationIdentifier values and formats defined in Table 10.1 below.”

Repo: crates/rtps/src/participant_data.rs, crates/rtps/src/publication_data.rs, crates/rtps/src/subscription_data.rs, crates/rtps/src/topic_data.rs (Kodierung mit PL_CDR_LE oder PL_CDR_BE, andere Kennungen beim Lesen abgewiesen)

Tests: crates/rtps/src/participant_data.rs::tests::participant_data_decode_rejects_unknown_encapsulation, crates/rtps/src/publication_data.rs::tests::decode_rejects_unknown_encapsulation

Status: done

§10.3 Table 10.1 PL_CDR_BE {0x00, 0x02}

Spec: §10.5, S. 201, Table 10.3 — “CDR_BE — {0x00, 0x00} — Classic CDR representation with Big Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap mit big_endian, encap_big_endian)

Tests: crates/dcps/src/runtime.rs::tests::user_payload_encap_maps_repr_and_extensibility, crates/dcps/src/subscriber.rs::tests::cache_materialize_honors_xcdr1_encapsulation_le_and_be

Status: done

§10.5 Table 10.3 CDR_LE {0x00, 0x01}

Spec: §10.5, S. 201, Table 10.3 — “CDR_LE — {0x00, 0x01} — Classic CDR representation with Little Endian encoding.”

Repo: crates/dcps/src/runtime.rs (USER_PAYLOAD_ENCAP, user_payload_encap)

Tests: crates/dcps/src/runtime.rs::tests::user_payload_encap_is_cdr_le, crates/dcps/src/runtime.rs::tests::strip_user_encap_xcdr1_le

Status: done

§10.5 Table 10.3 PL_CDR_BE {0x00, 0x02}

Spec: §10.5, S. 201, Table 10.3 — “PL_CDR_BE — {0x00, 0x02} — ParameterList (9.4.2.11) with Big Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap: XCDR1 und MUTABLE)

Tests: crates/dcps/src/runtime.rs::tests::user_payload_encap_maps_repr_and_extensibility

Status: done

§10.5 Table 10.3 PL_CDR_LE {0x00, 0x03}

Spec: §10.5, S. 201, Table 10.3 — “PL_CDR_LE — {0x00, 0x03} — ParameterList (9.4.2.11) with Little Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap: XCDR1 und MUTABLE)

Tests: crates/dcps/src/runtime.rs::tests::user_payload_encap_maps_repr_and_extensibility

Status: done

§10.5 Table 10.3 CDR2_BE {0x00, 0x10}

Spec: §10.5, S. 201, Table 10.3 — “CDR2_BE — {0x00, 0x10} — Plain CDR representation (version2) with Big Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — CDR2_BE: Big-Endian, gerade Kennung. Gelesen werden beide Wertemengen. Gesendet wird als Vorgabe DDS-XTypes 1.3 Table 60, auf die die Kopfzeile von Table 10.3 verweist und die Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 und RTI 7.7.0 senden (gemessen in tools/wire-capture/frames/*/*.xcdr2.frames). Mit wire.encapsulation_ids: table-39 (Umgebung ZERODDS_WIRE_ENCAPSULATION_IDS) sendet ZeroDDS die Kennungen aus Table 39 (§7.4.3.4), deren XCDR2-Werte die aus Table 10.3 sind (XML: {0x01, 0x00}). Erwartet bei den Herstellern: ein Peer, der nur Table 60 liest, kann Daten mit 0x0010 bis 0x0015 nicht lesen; die Einstellung ist für Peers, die Table 10.3 senden und erwarten. Nicht gemessen: ein Lauf gegen die Hersteller mit der Einstellung.

§10.5 Table 10.3 CDR2_LE {0x00, 0x11}

Spec: §10.5, S. 201, Table 10.3 — “CDR2_LE — {0x00, 0x11} — Plain CDR representation (version2) with Little Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — CDR2_LE. Gelesen werden beide Wertemengen. Gesendet wird als Vorgabe DDS-XTypes 1.3 Table 60, auf die die Kopfzeile von Table 10.3 verweist und die Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 und RTI 7.7.0 senden (gemessen in tools/wire-capture/frames/*/*.xcdr2.frames). Mit wire.encapsulation_ids: table-39 (Umgebung ZERODDS_WIRE_ENCAPSULATION_IDS) sendet ZeroDDS die Kennungen aus Table 39 (§7.4.3.4), deren XCDR2-Werte die aus Table 10.3 sind (XML: {0x01, 0x00}). Erwartet bei den Herstellern: ein Peer, der nur Table 60 liest, kann Daten mit 0x0010 bis 0x0015 nicht lesen; die Einstellung ist für Peers, die Table 10.3 senden und erwarten. Nicht gemessen: ein Lauf gegen die Hersteller mit der Einstellung.

§10.5 Table 10.3 PL_CDR2_BE {0x00, 0x12}

Spec: §10.5, S. 201, Table 10.3 — “PL_CDR2_BE — {0x00, 0x12} — Extended CDR representation (version2) for MUTABLE types with Big Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — PL_CDR2_BE. Gelesen werden beide Wertemengen. Gesendet wird als Vorgabe DDS-XTypes 1.3 Table 60, auf die die Kopfzeile von Table 10.3 verweist und die Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 und RTI 7.7.0 senden (gemessen in tools/wire-capture/frames/*/*.xcdr2.frames). Mit wire.encapsulation_ids: table-39 (Umgebung ZERODDS_WIRE_ENCAPSULATION_IDS) sendet ZeroDDS die Kennungen aus Table 39 (§7.4.3.4), deren XCDR2-Werte die aus Table 10.3 sind (XML: {0x01, 0x00}). Erwartet bei den Herstellern: ein Peer, der nur Table 60 liest, kann Daten mit 0x0010 bis 0x0015 nicht lesen; die Einstellung ist für Peers, die Table 10.3 senden und erwarten. Nicht gemessen: ein Lauf gegen die Hersteller mit der Einstellung.

§10.5 Table 10.3 PL_CDR2_LE {0x00, 0x13}

Spec: §10.5, S. 201, Table 10.3 — “PL_CDR2_LE — {0x00, 0x13} — Extended CDR representation (version2) for MUTABLE types with Little Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — PL_CDR2_LE. Gelesen werden beide Wertemengen. Gesendet wird als Vorgabe DDS-XTypes 1.3 Table 60, auf die die Kopfzeile von Table 10.3 verweist und die Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 und RTI 7.7.0 senden (gemessen in tools/wire-capture/frames/*/*.xcdr2.frames). Mit wire.encapsulation_ids: table-39 (Umgebung ZERODDS_WIRE_ENCAPSULATION_IDS) sendet ZeroDDS die Kennungen aus Table 39 (§7.4.3.4), deren XCDR2-Werte die aus Table 10.3 sind (XML: {0x01, 0x00}). Erwartet bei den Herstellern: ein Peer, der nur Table 60 liest, kann Daten mit 0x0010 bis 0x0015 nicht lesen; die Einstellung ist für Peers, die Table 10.3 senden und erwarten. Nicht gemessen: ein Lauf gegen die Hersteller mit der Einstellung.

§10.5 Table 10.3 D_CDR_BE {0x00, 0x14}

Spec: §10.5, S. 201, Table 10.3 — “D_CDR_BE — {0x00, 0x14} — Extended CDR representation (version2) for APPENDABLE types with Big Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — D_CDR_BE. Gelesen werden beide Wertemengen. Gesendet wird als Vorgabe DDS-XTypes 1.3 Table 60, auf die die Kopfzeile von Table 10.3 verweist und die Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 und RTI 7.7.0 senden (gemessen in tools/wire-capture/frames/*/*.xcdr2.frames). Mit wire.encapsulation_ids: table-39 (Umgebung ZERODDS_WIRE_ENCAPSULATION_IDS) sendet ZeroDDS die Kennungen aus Table 39 (§7.4.3.4), deren XCDR2-Werte die aus Table 10.3 sind (XML: {0x01, 0x00}). Erwartet bei den Herstellern: ein Peer, der nur Table 60 liest, kann Daten mit 0x0010 bis 0x0015 nicht lesen; die Einstellung ist für Peers, die Table 10.3 senden und erwarten. Nicht gemessen: ein Lauf gegen die Hersteller mit der Einstellung.

§10.5 Table 10.3 D_CDR_LE {0x00, 0x15}

Spec: §10.5, S. 201, Table 10.3 — “D_CDR_LE — {0x00, 0x15} — Extended CDR representation (version2) for APPENDABLE types with Little Endian encoding.”

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — D_CDR_LE. Gelesen werden beide Wertemengen. Gesendet wird als Vorgabe DDS-XTypes 1.3 Table 60, auf die die Kopfzeile von Table 10.3 verweist und die Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 und RTI 7.7.0 senden (gemessen in tools/wire-capture/frames/*/*.xcdr2.frames). Mit wire.encapsulation_ids: table-39 (Umgebung ZERODDS_WIRE_ENCAPSULATION_IDS) sendet ZeroDDS die Kennungen aus Table 39 (§7.4.3.4), deren XCDR2-Werte die aus Table 10.3 sind (XML: {0x01, 0x00}). Erwartet bei den Herstellern: ein Peer, der nur Table 60 liest, kann Daten mit 0x0010 bis 0x0015 nicht lesen; die Einstellung ist für Peers, die Table 10.3 senden und erwarten. Nicht gemessen: ein Lauf gegen die Hersteller mit der Einstellung.

§10.5 Table 10.3: Kennungen 0x0010 bis 0x0015

Spec: §10.5, S. 201, Table 10.3 — “CDR2_BE {0x00, 0x10}”, “CDR2_LE {0x00, 0x11}”, “PL_CDR2_BE {0x00, 0x12}”, “PL_CDR2_LE {0x00, 0x13}”, “D_CDR_BE {0x00, 0x14}”, “D_CDR_LE {0x00, 0x15}”.

Repo: crates/dcps/src/runtime.rs (user_payload_encap, encap_in_table, user_encap_body); wire.encapsulation_ids

Status: done — Die sechs Kennungen 0x0010 bis 0x0015 (gerade Big-Endian, ungerade Little-Endian). Gelesen werden beide Wertemengen. Gesendet wird als Vorgabe DDS-XTypes 1.3 Table 60, auf die die Kopfzeile von Table 10.3 verweist und die Cyclone DDS 11.0.1, Fast DDS, OpenDDS 3.34.0 und RTI 7.7.0 senden (gemessen in tools/wire-capture/frames/*/*.xcdr2.frames). Mit wire.encapsulation_ids: table-39 (Umgebung ZERODDS_WIRE_ENCAPSULATION_IDS) sendet ZeroDDS die Kennungen aus Table 39 (§7.4.3.4), deren XCDR2-Werte die aus Table 10.3 sind (XML: {0x01, 0x00}). Erwartet bei den Herstellern: ein Peer, der nur Table 60 liest, kann Daten mit 0x0010 bis 0x0015 nicht lesen; die Einstellung ist für Peers, die Table 10.3 senden und erwarten. Nicht gemessen: ein Lauf gegen die Hersteller mit der Einstellung.

§10.5 Table 10.3 XML {0x00, 0x04}

Spec: §10.5, S. 201, Table 10.3 — “XML — {0x00, 0x04} — See DDS-XTypes [3] clause 7.4.4.”

Repo: crates/dcps/src/runtime.rs (XML_ENCAP, user_payload_encap, xml_wire_body, xml_sample_as_cdr); crates/dcps/src/xml_data.rs; crates/dcps/src/publisher.rs

Status: done — ein Writer, dessen erste DataRepresentation XML ist, sendet das Dokument des Samples unter {0x00, 0x04}; ein Reader liest die Probe gegen seinen registrierten Typ und gibt den XCDR2-Rumpf weiter. Nicht gemessen: ein Hersteller, der XML sendet oder liest.

§10.5 Ältere DDS-Implementierungen ohne DDS-XTypes

Spec: §10.5, S. 201 — “Legacy DDS implementations that are not compliant with DDS-XTYPES should minimally support the RepresentationIdentifier values CDR_BE and CDR_LE and the type system elements specified in clause F1”.

Repo: —

Tests: —

Status: n/a (informative) — richtet sich an Implementierungen ohne DDS-XTypes; ZeroDDS unterstützt CDR_BE und CDR_LE (§10.5 Table 10.3).

§10.6 Beispiel für Daten eines Builtin-Endpoints

Spec: §10.6, S. 201–203 — “Following is the SerializedPayload element used by the SEDPbuiltinSubscriptionsWriter to declare a DataReader.” mit Aufbau und Oktetten.

Repo: crates/rtps/src/subscription_data.rs (SubscriptionBuiltinTopicData::from_pl_cdr_le, to_pl_cdr_le)

Status: done — die 84 Oktette der Spec werden als der DataReader gelesen, den sie beschreiben; die fünf Parameter des Beispiels schreibt der Encoder mit denselben Oktetten (die Spec lässt die Vorgabewerte aus, ZeroDDS schreibt sie zusätzlich).

§10.7 Beispiel für Daten eines Anwender-Topics

Spec: §10.7, S. 203–204 — “Following is the SerializedPayload element used by an application DataWriter to send Data on the Topic “Square” with type “ShapeType”” mit Aufbau und Oktetten.

Repo: crates/dcps/src/runtime.rs (user_payload_encap, strip_user_encap)

Tests: crates/dcps/src/runtime.rs::tests::the_example_of_10_7_has_the_header_and_body_of_the_spec

Status: done — Kopf CDR_LE ({0x00, 0x01}, Optionen 0) und der Rumpf von 24 Oktetten des Beispiels („BLUE“, 34, 100, 24) werden so gelesen, wie die Spec sie druckt; der Kopf für einen XCDR1-Final-Writer ist der der Spec.

Annex A References

Annex A Literatur

Spec: Annex A, S. 205 — “[1] DDS-SECURITY: DDS Security version 1.1 https://www.omg.org/spec/DDS-SECURITY”.

Repo: —

Tests: —

Status: n/a (informative) — Literaturverzeichnis.

Audit-Status

978 done / 3 partial / 15 open / 2 blocked / 127 n/a (informative).

Offene Punkte: ddsi-rtps-2.5.open.md.