ZeroDDS-UDS-Transport 1.0 — Spec Coverage

A ZeroDDS-vendor-specific Unix-domain-socket transport for container IPC. Not OMG-normative — Cyclone DDS and FastDDS have no official UDS transport. Implemented in:

• crates/transport-uds/ · docs.rs — path resolution + SOCK_DGRAM format + abstract namespace + cleanup (lib.rs, abstract_dgram.rs)

The vendor-reserved locator-kind value (§9.4) is a constant in crates/rtps/src/wire_types.rs.

Spec family	Status
OMG-normative	DDSI-RTPS 2.5 §9.4 LocatorKind (vendor-reserved) — locator value in crates/rtps/src/wire_types.rs
ZeroDDS-own spec	path resolution + SOCK_DGRAM format + abstract namespace — zerodds-uds-transport-1.0.md

§1 Scope and spec status

§1.1 What OMG standardizes

DDSI-RTPS 2.5 §9.4 allows vendor-reserved locator kinds. ZeroDDS allocates LOCATOR_KIND_UDS = 0x81000001 (a vendor-specific value).

No normative wire format, no path schema, no cleanup protocol.

§1.2 ZeroDDS choice

An own spec for: - filesystem path resolution. - the SOCK_DGRAM wire format. - the Linux abstract-namespace variant. - cleanup semantics.

§2 Path resolution

§2.1 Filesystem mode (default)

16-byte Locator address → path:

<base_dir>/<lowercase-hex32>.sock

• Default base_dir = /tmp/zerodds/uds.
• <lowercase-hex32> is the 16-byte ID as 32 hex characters.
• The base directory is created lazily on bind with mode 0700 (user-private).

Repo anchors: lib.rs::socket_path, lib.rs::DEFAULT_BASE_DIR.

§2.2 Abstract-namespace mode (Linux-only)

An alternative on Linux: sockets in the abstract namespace (no filesystem inode). Path:

\0zd-<lowercase-hex32>

(A leading null byte signals the abstract namespace on Linux.)

• Advantages: no file cleanup needed, no inode permissions.
• Trade-off: Linux only, no cross-mount volume.

Repo anchor: abstract_dgram.rs::AbstractDgramSocket.

§3 Wire format

SOCK_DGRAM over UDS — one datagram message per RTPS frame. The kernel preserves message boundaries (unlike a TCP stream).

• Default max_datagram = 65,536 bytes.
• Kernel limit: Linux wmem_max (default 212,992) is the upper bound; ZeroDDS stays below it.

Repo anchors: lib.rs::DEFAULT_MAX_DATAGRAM, lib.rs::UdsTransport::recv.

§4 Cleanup semantics

§4.1 Filesystem mode

• Bind creates the socket file on demand.
• Drop removes the socket file via fs::remove_file (best-effort).
• Crash: a zombie socket remains; the next bind detects it via path.exists() and fails with AlreadyInUse (TOCTOU-safe: probe first, then fail fast — no auto-cleanup, because auto-cleanup could be a cross-process race).

§4.2 Abstract mode

No cleanup needed — Linux reclaims abstract sockets automatically when the last FD is closed.

§5 Container use case

§5.1 Docker/Kubernetes pattern

A mounted volume /tmp/zerodds/uds between two containers; each container binds its own 16-byte locator as a socket file. The kernel routes between the FDs.

§5.2 When to use UDS instead of SHM

• Multicast blocked (cluster network policy).
• POSIX SHM impractical cross-container (UID mapping, /dev/shm visibility, SELinux profiles).
• A volume mount is the realistic permission boundary.

§6 Cross-vendor interop

Not intended. UDS is intra-container/intra-host IPC. Cross-vendor interop with Cyclone/FastDDS stays in the UDP/TCP/SHM domain.

§7 Platform support

Platform	Status	Notes
Linux	✅ primary	filesystem + abstract namespace
macOS	✅ supported	filesystem mode only (no abstract namespace)
Windows	❌ not supported	UDS is Unix-specific (Windows named pipes would be the analogue)

§8 Test coverage

Spec section	Tests
§2.1 filesystem path	lib.rs::tests::socket_path_*
§2.2 abstract namespace	abstract_dgram.rs::tests::abstract_*
§3 SOCK_DGRAM	lib.rs::tests::send_recv_*
§4 cleanup	lib.rs::tests::cleanup_*, bind_existing_path_*
§5 cross-process	tests/l1_cross_process.rs

Total: 16 lib + 1 cross-process = 17 tests green.

§9 Status

Fully covered. The ZeroDDS UDS transport is a complete, internally coherent spec; all § sections are implemented and tested.

ZeroDDS-UDS-Transport 1.0 — Spec-Coverage

ZeroDDS-vendor-spezifischer Unix-Domain-Socket-Transport für Container-IPC. Nicht OMG-normativ — Cyclone DDS und FastDDS haben keinen offiziellen UDS-Transport. Implementiert in:

• crates/transport-uds/ · docs.rs — Path-Resolution + SOCK_DGRAM-Format + Abstract-Namespace + Cleanup (lib.rs, abstract_dgram.rs)

Der vendor-reservierte Locator-Kind-Wert (§9.4) ist eine Konstante in crates/rtps/src/wire_types.rs.

Spec-Family	Status
OMG-normativ	DDSI-RTPS 2.5 §9.4 LocatorKind (vendor-reserviert) — Locator-Wert in crates/rtps/src/wire_types.rs
ZeroDDS-eigene Spec	Path-Resolution + SOCK_DGRAM-Format + Abstract-Namespace — zerodds-uds-transport-1.0.md

§1 Scope und Spec-Status

§1.1 Was OMG normiert

DDSI-RTPS 2.5 §9.4 erlaubt vendor-reservierte Locator-Kinds. ZeroDDS allokiert LOCATOR_KIND_UDS = 0x81000001 (vendor-spezifischer Wert).

Kein normatives Wire-Format, kein Path-Schema, kein Cleanup-Protokoll.

§1.2 ZeroDDS-Wahl

Eigene Spec für: - Filesystem-Pfad-Resolution. - SOCK_DGRAM-Wire-Format. - Linux-Abstract-Namespace-Variante. - Cleanup-Semantik.

§2 Path-Resolution

§2.1 Filesystem-Modus (Default)

16-Byte Locator-Adresse → Path:

<base_dir>/<lowercase-hex32>.sock

• Default base_dir = /tmp/zerodds/uds.
• <lowercase-hex32> ist die 16-Byte-ID als 32-Zeichen-Hex.
• Base-Directory wird lazy auf Bind erstellt mit Mode 0700 (user-private).

Repo-Anker: lib.rs::socket_path, lib.rs::DEFAULT_BASE_DIR.

§2.2 Abstract-Namespace-Modus (Linux-only)

Alternative auf Linux: Sockets im Abstract-Namespace (kein Filesystem-Inode). Path:

\0zd-<lowercase-hex32>

(Leading-Null-Byte signalisiert Abstract-Namespace bei Linux).

• Vorteile: kein File-Cleanup nötig, keine Inode-Permissions.
• Trade-off: nur Linux, kein Cross-Mount-Volume.

Repo-Anker: abstract_dgram.rs::AbstractDgramSocket.

§3 Wire-Format

SOCK_DGRAM über UDS — eine Datagram-Message pro RTPS-Frame. Kernel erhält Message-Grenzen (anders als TCP-Stream).

• Default max_datagram = 65 536 Bytes.
• Kernel-Limit: Linux wmem_max (default 212 992) ist die obere Grenze; ZeroDDS liegt drunter.

Repo-Anker: lib.rs::DEFAULT_MAX_DATAGRAM, lib.rs::UdsTransport::recv.

§4 Cleanup-Semantik

§4.1 Filesystem-Modus

• Bind erstellt Socket-File auf-demand.
• Drop entfernt das Socket-File via fs::remove_file (best-effort).
• Crash: Zombie-Socket bleibt; nächster Bind detektiert das via path.exists() und failed mit AlreadyInUse (TOCTOU-sicher: erst Probe, dann fail-fast — kein Auto-Cleanup, weil Auto-Cleanup beziehbar wäre als Cross-Process-Race).

§4.2 Abstract-Modus

Kein Cleanup nötig — Linux räumt Abstract-Sockets beim Close des letzten FD automatisch.

§5 Container-Use-Case

§5.1 Docker/Kubernetes-Pattern

Gemountetes Volume /tmp/zerodds/uds zwischen zwei Containern; jeder Container bindet seinen eigenen 16-Byte-Locator als Socket-File. Der Kernel routet zwischen den FDs.

§5.2 Wann UDS statt SHM

• Multicast geblockt (Cluster-Network-Policy).
• POSIX-SHM cross-Container unpraktisch (UID-Mapping, /dev/shm- Sichtbarkeit, SELinux-Profile).
• Volume-Mount ist die realistische Permission-Boundary.

§6 Cross-Vendor-Interop

Nicht vorgesehen. UDS ist intra-Container/intra-Host-IPC. Cross- Vendor-Interop mit Cyclone/FastDDS bleibt UDP/TCP/SHM-Domain.

§7 Plattform-Support

Plattform	Status	Anmerkungen
Linux	✅ primary	Filesystem + Abstract Namespace
macOS	✅ supported	Nur Filesystem-Modus (kein Abstract Namespace)
Windows	❌ nicht supported	UDS ist Unix-spezifisch (Windows-Named-Pipes wären die Analogie)

§8 Test-Coverage

Spec-Sektion	Tests
§2.1 Filesystem-Path	lib.rs::tests::socket_path_*
§2.2 Abstract-Namespace	abstract_dgram.rs::tests::abstract_*
§3 SOCK_DGRAM	lib.rs::tests::send_recv_*
§4 Cleanup	lib.rs::tests::cleanup_*, bind_existing_path_*
§5 Cross-Process	tests/l1_cross_process.rs

Total: 16 lib + 1 cross-process = 17 Tests grün.

§9 Status

Voll abgedeckt. ZeroDDS-UDS-Transport ist eine vollständige, in-sich-kohärente Spec; alle §-Sektionen sind implementiert und getestet.