[Announcements] ZettaTransport: A custom UDP transport layer for hostile networks (FEC, X25519, Lock-less I/O)

announcements
1

Hi everyone,

I’ve been working on an open-source project called ZettaTransport (ZT), and I would love to get some architectural feedback from the experienced Rustaceans here.

It is a custom transport layer protocol built on top of UDP, specifically designed for robotics, industrial automation, and edge IoT networks operating in highly unstable RF environments.

The Motivation: TCP's head-of-line blocking makes it unusable for real-time telemetry over lossy links. Raw UDP offers zero reliability. I evaluated QUIC, but it carries too much HTTP/3 legacy baggage for lightweight edge devices, and I needed native Forward Error Correction (FEC) at Layer 4 so I could compile it directly into my application binaries.

Architecture & Rust Highlights:

  • Lock-less I/O Path: This was my biggest focus. I wanted to ensure the server doesn't suffer from thread starvation. The critical paths (ChaCha20 cryptography and UDP send_to operations) are completely decoupled from the main state map locks.
  • Active FEC & Congestion Control: Implemented a dual-engine FEC (XOR Parity and Reed-Solomon Erasure Coding) to recover dropped packets mathematically. It also features a TCP-like AIMD congestion control to prevent buffer bloat.
  • Connection IDs (CID): Connections use a 64-bit CID instead of IP:Port binding. This allows seamless network handovers (e.g., an AGV jumping from factory Wi-Fi to a 5G network) without dropping the session.
  • Async Integration: The core state machine is wrapped in a tokio-compatible ZtStream that natively handles flow backpressure.

What I am looking for: I have written up a full RFC-001 specification for the protocol. I would really appreciate it if anyone could take a look at the codebase or the spec and point out any flaws.

Thanks in advance for your time and feedback!

2

My first look went to the spec, to which I have the following feedback:

The spec lacks nearly all details. It defines the packet headers, which is what I would expect. But the rest reads more like the abstract of a spec or a leaflet. In my eyes, a spec should rigorously define all aspects of a protocol. Things that I feel like are missing, in no particular order:

  • Header field descriptions
  • There seem to be different packet types. What are they? Currently, they are scattered through the document. It is not clear if there are more.
  • State machine descriptions: How do you initiate, keep up and finalize a connection. Are there any timers? How is the state of a system affected when packets arrive, timers expire or packets are sent?
  • Exact definition of how all the things are computed: FEC, encryption, window sizes, etc. How are keys exchanged, etc...

The spec should allow one to create an alternative implementation without looking at your code, just the spec. Only in this way you can sufficiently reason about the correctness of your code. If you want your code to be the source of truth, the document is probably better called a description, not a spec.

Btw: your header description is very confusing, you are mixing bits and bytes, the lengths do not match in any way. I like to use this little library to create header visualizations: GitHub - luismartingarcia/protocol: An ASCII Header Generator for Network Protocols · GitHub

3

Hi @ntova,

Thank you for the feedback, you were completely right. The initial document was definitely too abstract to serve as a proper specification.

I have updated the document based on your points. Here are the main changes I made:

  • Fixed the header diagrams so they are properly aligned and much easier to read.
  • Centralized all packet types and added clear field descriptions.
  • Added the missing state machine descriptions, including transitions and timers.
  • Included the exact computations and logic for cryptography, FEC, and flow control.

Thanks again for taking the time to review it!