All work07 / Network protocol research

AeroUDP

Reliability, one packet at a time.

AeroUDP is an experimental Rust transport built on Tokio and UDP. It explores connection setup, packet ordering, acknowledgements, retransmission, and congestion handling through a public implementation.

Context
Personal open-source project
Engineering scope
Protocol & transport implementation
Built with
Rust · Tokio · UDP · CRC32
An explanatory diagram drawn from the public implementation.

01Context

UDP provides a starting point.

UDP does not provide ordered delivery or retransmission. A transport that needs those properties must account for missing, duplicated, and out-of-order packets itself.

AeroUDP examines that problem as a personal protocol-engineering project.

02Approach

Make delivery state explicit.

The implementation frames packets, tracks sequence state, buffers received data, and uses cumulative acknowledgements. Missing delivery can trigger retransmission, while congestion logic limits the sending window.

RTT estimates and timeout handling inform the retry path. Connection setup and teardown are part of the protocol rather than assumptions outside it.

03Architecture

A packet codec and a stateful transport.

A Rust/Tokio transport coordinates protocol state around a UDP socket. The packet format uses a 28-byte header with a maximum 1200-byte payload, and CRC32 for corruption detection.

The sequence diagram illustrates the acknowledgement and recovery mechanisms in the implementation.

04Implementation

Account for imperfect networks.

The project separates packet encoding from delivery behavior, so both the wire format and receive state can be examined.

Ordered receive
Buffer out-of-order data and handle duplicate packets within the receive path.
Recovery
Use acknowledgements, RTT estimates, and timeouts to coordinate retransmission.
Congestion control
Apply NewReno-style window logic to regulate sending behavior.

05Tradeoffs

Keep the protocol's limits visible.

The protocol uses cumulative acknowledgements rather than selective acknowledgements. CRC32 detects accidental corruption; it does not authenticate a peer or encrypt a message.

Encryption and peer authentication would need to be provided separately. The project remains an experiment in framing, ordering, and recovery.

06Outcome

A transport you can inspect.

The repository includes packet-codec and receive-order checks, duplicate-handling tests, and a configurable network example. Together they expose how the implementation handles framing and delivery state.

Sources & further reading

A personal open-source engineering project. Experimental work, included in the team's portfolio of experience.

Next case study / 01Openship

A good place to begin

What are you
building next?

A new product, a difficult system,
or a considered next step.

Start a project