Skip to content

Feature: Add UDP, Unix datagram, and named pipe (FIFO) transports #159

Description

@dustinblack

Summary

rusty-comms currently supports UDS (stream), TCP, SHM, and PMQ. Three common Linux IPC mechanisms are missing:

  1. UDP (IPv4/IPv6 loopback) — the simplest connectionless datagram transport
  2. Unix datagram sockets — local datagram delivery with atomic message boundaries
  3. Named pipes (FIFO) — the classic unidirectional IPC primitive

These are significant gaps for comprehensive IPC mechanism comparison, particularly when comparing results against other benchmarking tools that include these transports.

Why These Matter

UDP: The baseline network-stack datagram transport. Comparing UDP loopback vs. Unix dgram isolates the cost of the IP/UDP header processing. UDP is also the foundation for many automotive middleware protocols.

Unix datagram: Provides atomic message delivery (no framing needed) with lower overhead than stream sockets. The current UDS implementation uses SOCK_STREAM, which requires length-prefix framing and can deliver partial messages — a fundamentally different kernel path than SOCK_DGRAM.

Named pipes (FIFO): The simplest kernel-mediated IPC primitive. Pipes have different buffering semantics than sockets (configurable via F_SETPIPE_SZ) and are commonly used in embedded systems for signal-like communication.

Implementation Notes

All three transports are straightforward to implement using existing libc bindings:

  • UDP: socket(AF_INET, SOCK_DGRAM) + sendto/recvfrom. No connection state, no framing needed (datagrams are atomic).
  • Unix dgram: socket(AF_UNIX, SOCK_DGRAM) + sendto/recvfrom. Similar to UDP but local-only.
  • Named pipe: mkfifo + open(O_RDONLY)/open(O_WRONLY) + read/write. Unidirectional, so round-trip requires two FIFOs.

Each would need both async (Tokio) and blocking implementations, following the existing transport pattern.

Scope

This could be split into three separate PRs (one per transport) or a single PR if the implementations are kept minimal. The blocking implementations are simpler and higher priority for latency benchmarking; async variants can follow.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions