zerodds-tcp-transport-1.0 — Open Items
Aggregate of zerodds-tcp-transport-1.0.en.md, generated by website/_tools/gen_open_items.py.
No new content: every entry appears there as an item with its evidence.
§1.1 Locator kind TCPv4 / TCPv6
Status: partial — the transport carries the vendor-range values 0x01F0_0004 and 0x01F0_0005 (DDSI-RTPS 2.5 §9.3.2.4 reserves 3 to 0x01ffffff for vendors); set_tcp_kinds_fast_dds writes the values 4 and 8 of the spec line (Fast DDS, DDS-TCP-PSM), and both are read. Remainder: 4 and 8 are not the default.
§3.3 Reject reason codes
Status: partial — the codec and the client-side handling exist and are tested for all five codes. server_handshake however emits only VersionMismatch; ResourceLimit, LogicalPortConflict and VendorNotAccepted never reach the wire from a ZeroDDS server. The three missing sender paths are carried separately as §3.5, §3.6 and §3.7.
§3.5 Reserved flags — receiver check
Status: open — crates/transport-tcp/src/handshake.rs decodes flags and passes it on; neither server nor client refuses set bits.
§3.6 Logical-port claim
Status: open — server_handshake does not check logical_port and assigns the connection to no port; LogicalPortConflict is only encoded and decoded.
§3.7 ResourceLimit reject at the peer cap
Status: open — TcpTransport::serve closes the connection beyond MAX_PEERS after accept and counts it (refused_connections); no handshake with ResourceLimit goes on the wire.
§4.1 Handshake-skip mode
Status: open — a peer without a handshake is refused with HandshakeError::BadMagic (crates/transport-tcp/src/handshake.rs); a client and server mode without §3 is missing.
§4.2 Auto-detect on the first frame byte
Status: open — the server always expects the ZeroDDS handshake; telling 'Z' from 'R' on the first byte is missing.
§6.1 FastDDS BindConnection (submessages 0x71/0x72)
Status: open — no handshake dialect with the submessages 0x71/0x72; set_tcp_kinds_fast_dds concerns only the locator kinds (§1.1).
§6.2 RTI TLS-oriented handshake
Status: open — no mode with RTI’s TLS-oriented bring-up.
zerodds-tcp-transport-1.0 — offene Punkte
Aggregat aus zerodds-tcp-transport-1.0.md, erzeugt von website/_tools/gen_open_items.py.
Kein eigener Inhalt: jedes Item steht dort mit seinem Beleg.
§1.1 Locator-Kind TCPv4 / TCPv6
Status: partial — der Transport führt die Werte des Herstellerbereichs 0x01F0_0004 und 0x01F0_0005 (DDSI-RTPS 2.5 §9.3.2.4 reserviert 3 bis 0x01ffffff für Hersteller); die Werte 4 und 8 der Spec-Zeile schreibt set_tcp_kinds_fast_dds (Fast DDS, DDS-TCP-PSM), gelesen werden beide. Rest: die Werte 4 und 8 sind nicht der Vorgabewert.
§3.3 Reject-Reason-Codes
Status: partial — Codec und Client-Verarbeitung sind für alle fünf Codes vorhanden und getestet. server_handshake erzeugt jedoch nur VersionMismatch; ResourceLimit, LogicalPortConflict und VendorNotAccepted kommen nie aus einem ZeroDDS-Server auf die Leitung. Die drei fehlenden Sender-Pfade sind als §3.5, §3.6 und §3.7 getrennt geführt.
§3.5 Reserved flags — Empfänger-Prüfung
Status: open — crates/transport-tcp/src/handshake.rs dekodiert flags und gibt es weiter; weder Server noch Client lehnen gesetzte Bits ab.
§3.6 Logical-Port-Claim
Status: open — server_handshake prüft logical_port nicht und ordnet die Verbindung keinem Port zu; LogicalPortConflict wird nur kodiert und dekodiert.
§3.7 ResourceLimit-Reject bei erreichtem Peer-Limit
Status: open — TcpTransport::serve schließt die Verbindung über MAX_PEERS nach dem Accept und zählt sie (refused_connections); ein Handshake mit ResourceLimit geht nicht auf die Leitung.
§4.1 Handshake-Skip-Mode
Status: open — ein Peer ohne Handshake wird mit HandshakeError::BadMagic abgewiesen (crates/transport-tcp/src/handshake.rs); eine Client- und Server-Betriebsart ohne §3 fehlt.
§4.2 Auto-Detect am ersten Frame-Byte
Status: open — der Server erwartet immer den ZeroDDS-Handshake; eine Unterscheidung von 'Z' und 'R' am ersten Byte fehlt.
§6.1 FastDDS-BindConnection (Submessages 0x71/0x72)
Status: open — kein Handshake-Dialekt mit den Submessages 0x71/0x72; set_tcp_kinds_fast_dds betrifft nur die Locator-Kinds (§1.1).
§6.2 RTI-TLS-orientierter Handshake
Status: open — keine Betriebsart mit dem TLS-orientierten Bring-up von RTI.