Systems Programming · Bounded implementation
WireStack
A userspace network stack built from Linux TAP through Ethernet, ARP, IPv4, ICMP, UDP, TCP, HTTP, and DNS.
Why I built it
The first successful curl request proved that WireStack had a vertical path. It did not test the machinery TCP needs when packets are delayed, lost, reordered, or blocked by the receiver.
Architecture
Frames enter through a Linux TAP device and move through independently tested protocol layers. TCP maintains connection state, send and receive sequence spaces, retransmission state, congestion state, reassembly, negotiated options, and close transitions. HTTP and DNS exercise the transport against real applications.
C++20 · Linux TAP · TCP/IP · HTTP · DNS · packet capture
After the happy path
The retransmission timer uses smoothed RTT and variance; Karn's rule excludes ambiguous samples after retransmission. Reno and NewReno recovery adjust the congestion window under loss, while SACK describes receive holes. Advertised-window handling includes zero-window persist, and FIN consumes sequence space across explicit close states.
What I actually tested
- active and passive open against the Linux kernel
- real curl requests and a Python server across network namespaces
- loss, retransmission, reordering, and receive reassembly
- SACK negotiation, congestion recovery, and zero-window behavior
- packet-capture inspection of handshake, data, and close paths
Boundary and trade-off
WireStack is a learning implementation that prioritizes protocol correctness over throughput. It is not RFC-complete and omits simultaneous open, DSACK, CUBIC, and BBR.