Module participant_message_data

Expand description

ParticipantMessageData Wire-Encoding (DDSI-RTPS 2.5 §9.6.3.1).

Payload-Struktur des Writer-Liveliness-Protocols (WLP, §8.4.13). Wird vom BUILTIN_PARTICIPANT_MESSAGE_WRITER als DATA-Submessage im Topic DCPSParticipantMessage periodisch publiziert. Reader nutzen den Empfang als implicit assert_liveliness() und treiben damit das Lease-Tracking pro Peer-Participant.

§Wire-Layout (§9.6.3.1)

struct ParticipantMessageData {
    GUID_t   participantGuidPrefix; // 12 byte (GuidPrefix only!)
    octet    kind[4];               // 4 byte u32 (BE/LE per CDR)
    sequence<octet> data;           // 4 byte length + N byte
};

Spec-Pitfall: trotz Feldname participantGuidPrefix wird in der Praxis von Cyclone DDS und Fast-DDS ein voller 16-Byte-Guid geschickt (Prefix + ENTITYID_PARTICIPANT). Wir schreiben deshalb 16 Byte und parsen tolerant: 16 Byte → Voll-Guid, 12 Byte → Prefix-Only.

Die data-Sequenz ist semantisch eine vec<octet> mit voran- gestellter 32-Bit-Laenge. Spec §9.6.3.1 definiert sie als opaque Token; ZeroDDS nutzt sie fuer MANUAL_BY_TOPIC, um den Topic-Token zu transportieren (Topic-Hash-Fingerprint).

§CDR-Encoding

Encoded als XCDR1 Plain (Encapsulation 0x0000 BE / 0x0001 LE) bzw. XCDR2 Plain (0x0006 BE / 0x0007 LE). Cyclone schickt das Topic per Default als XCDR1 Plain. Wir akzeptieren alle vier Encapsulation-Kinds und schreiben per Default LE.

§DoS-Caps

data.len() ist auf MAX_DATA_LEN = 4096 Byte gedeckelt. Encoder kuerzt nicht — Caller muss vor Aufruf cappen — Decoder lehnt ueberlange Daten mit WireError::ValueOutOfRange ab.

Structs§

ParticipantMessageData: ParticipantMessageData (DDSI-RTPS 2.5 §9.6.3.1) — Payload des DCPSParticipantMessage-Topics.

Constants§

ENCAPSULATION_CDR2_BE: CDR-Encapsulation-Header: XCDR2 Plain Big-Endian (0x0006).
ENCAPSULATION_CDR2_LE: CDR-Encapsulation-Header: XCDR2 Plain Little-Endian (0x0007).
ENCAPSULATION_CDR_BE: CDR-Encapsulation-Header: XCDR1 Plain Big-Endian (0x0000).
ENCAPSULATION_CDR_LE: CDR-Encapsulation-Header: XCDR1 Plain Little-Endian (0x0001).
MAX_DATA_LEN: DoS-Cap fuer data-Sequenz (Topic-Token / vendor opaque). Bewusst klein gewaehlt — WLP-Heartbeats sollen leicht sein, ein Peer der mehr schickt ist entweder buggy oder bösartig.
PARTICIPANT_MESSAGE_DATA_KIND_AUTOMATIC_LIVELINESS_UPDATE: Spec-defined kind Code: AUTOMATIC_LIVELINESS_UPDATE (§9.6.3.1). Wird vom Builtin-WLP-Writer geschickt, wenn LIVELINESS=AUTOMATIC.
PARTICIPANT_MESSAGE_DATA_KIND_MANUAL_BY_PARTICIPANT_LIVELINESS_UPDATE: Spec-defined kind Code: MANUAL_BY_PARTICIPANT_LIVELINESS_UPDATE (§9.6.3.1). Getrigger durch assert_liveliness() auf DomainParticipant.
PARTICIPANT_MESSAGE_DATA_KIND_VENDOR_BASE: Vendor-Specific-Kind-Range: oberstes Bit gesetzt (0x80000000..=0xFFFFFFFF). Spec §9.6.3.1 reserviert dies fuer Vendor-eigene Kinds (z.B. ZeroDDS-MANUAL_BY_TOPIC mit Topic-Token in der data-Sequenz).
PARTICIPANT_MESSAGE_DATA_KIND_ZERODDS_MANUAL_BY_TOPIC: ZeroDDS-Vendor-Kind: MANUAL_BY_TOPIC. Wird durch DataWriter::assert_liveliness() getriggert; die data-Sequenz traegt einen Topic-Token (typisch 4-Byte-Hash). Cyclone-Peers ignorieren das Vendor-Kind (Spec §9.6.3.1: “If kind has its MSB set, implementations not understanding the kind shall ignore the message”).