Johnny Li Portfolio

Case study 04 / Transport protocols

Reliable Transport
over UDP

A selective-repeat-style file transfer protocol that preserves ordering and delivery while packets and acknowledgements are deliberately lost.

View source Protocol design
Role
Protocol design and implementation
Stack
C++17 · POSIX sockets · Python
Model
Sliding window · Per-packet ACKs
Status
Integration tested · Public
01

The problem

UDP provides datagrams, not reliable delivery, ordering, congestion control, or a completed-file guarantee.

The application therefore has to define its own packet identity, acknowledgement behavior, retransmission policy, transfer completion, and file-reassembly rules.

The server makes the failure path observable by independently dropping received DATA packets and transmitted acknowledgements at a configured rate.

02

Transfer model

  1. SegmentBounded datagrams

    The client divides the file into packets that fit the requested maximum segment size, including the protocol header.

  2. WindowMultiple packets in flight

    A configurable send window avoids stop-and-wait behavior while bounding memory and outstanding work.

  3. RecoverTimeout and retransmit

    Unacknowledged packets are retried individually until acknowledged or the retry limit is reached.

  4. ReassembleOrdered output

    The server buffers out-of-order data and writes the final byte stream only in sequence.

03

Engineering decisions

A

Selective recovery

Each packet is acknowledged and retransmitted independently, so one loss does not force the whole active window to be resent.

B

Integrity in the wire format

A CRC-32 field rejects corrupted protocol datagrams before they can enter the reassembly state.

C

Bounded resource use

The client streams from disk and retains only window state rather than loading the complete input file into memory.

D

Sessions over one socket

The server distinguishes transfer state by client and transfer identifier, allowing packet streams from multiple clients to interleave.

04

Failure evidence

Reliability is visible in the packet timeline rather than inferred from a successful exit code alone.

The client writes RFC 3339 CSV events for every DATA transmission and acknowledgement, including the current base, next sequence number, and window boundary. The server separately records every deliberate DATA or ACK drop.

A bundled Python tool converts those logs into a sequence-versus-time SVG. Retransmissions appear as repeated DATA points, while acknowledgements show when the send window can advance.

05

Validation

32 Bprotocol header
5transfer scenarios
2simulated loss directions
SHA-256output verification

The integration suite covers text, empty, binary, nested-path, and lossy transfers. Each successful run compares the source and reconstructed files by SHA-256 rather than relying only on application status.

06

Scope and provenance

This is an application protocol experiment, not a replacement for a production transport such as TCP or QUIC.

The model uses a fixed retransmission policy and controlled packet loss. It does not implement congestion control, path-MTU discovery, cryptographic authentication, or Internet-scale fairness.

The project originated in CSE 156/L at UC Santa Cruz in Winter 2025. After the original university-hosted source was lost, the published implementation was reconstructed from the surviving specification and expanded with integrity checks, automated tests, and clearer documentation.

Next project

Clear requests,
secured upstream.

Read proxy case study