Start Here

This atlas is read as a build queue, not a course catalog. Each branch feeds the next one's problem; you feel a branch's pain before the next branch's tool solves it.

Before you start

Do Low-Level Atlas I and Low-Level Atlas II first. At minimum, from Atlas I: systems programming (syscalls, low-level I/O) and concurrency & performance (threads, atomics, memory ordering). From Atlas II: HTTP Server from Scratch (raw sockets, an event loop) and Concurrency in Practice. Nothing here re-teaches what a socket, an epoll loop, or a thread pool is.

The build queue

1. Understand the wire. TCP Fundamentals — the handshake, Nagle, socket buffers, backpressure, real network errors. Build v0: a raw TCP echo server.
2. Suffer, then design. Custom Binary Protocol — frame your own messages, serialize them, version the protocol. Build v1: N clients on your own format, no WebSocket yet.
3. Speak the real standard. WebSocket Protocol from Scratch — RFC 6455 by hand. Build v2: migrate to a compliant WebSocket, verify against a browser.
4. Make connections scale. Connection Concurrency at Scale — event loops, thread pools, C10K. Build v3: rooms, presence, broadcast at real concurrency.
5. Model the chat's domain. Presence, Rooms & Fanout — runs alongside step 4, not after it.
6. Compare the runtimes. Client in C and Client in TypeScript — build v4: the same protocol, two clients, side by side.
7. Never stop testing it. Network Craftsmanship runs alongside every branch above, not after them.

How to read it

• The chat is one project built in milestones (v0 → v5), the same discipline as Atlas I's OS and Atlas II's database engine — see the roadmap on the home page.
• This atlas exists because the concurrency problem is categorically different here: long-lived connections that need to see each other (broadcast, presence, rooms), not many stateless requests handled in parallel. That's why it's a separate atlas, not a phase of Atlas II.
• Two clients (C and TypeScript) speak the exact same wire protocol on purpose — the point is watching one spec survive two runtimes, not building the same thing twice.

See also: Must Know · Full Index