TL;DR: Sockets do not establish physical connections. In TCP, the illusion of a connection comes at the expense of head-of-line blocking: if one packet drops, everything stops and waits. In real-time games running at 60 FPS, old position updates are useless garbage. Fast multiplayer netcode uses UDP for 95% of state, layering lightweight acknowledgments only for critical events, and decoupled from the render loop via circular ring buffers.
┌────────────────────────────────────────────────────────────────────────┐
│ NETWORK PROTOCOLS IN REAL-TIME GAMES │
├───────────────────────────────────┬────────────────────────────────────┤
│ TCP (Stream / Connection Model) │ UDP (Datagram / Tuner Model) │
├───────────────────────────────────┼────────────────────────────────────┤
│ • Head-of-line blocking on loss │ • Zero blocking on dropped packets │
│ • Forced in-order delivery │ • Discards stale out-of-order data │
│ • Retransmits obsolete positions │ • Newest snapshot overwrites loss │
│ • High latency jitter under load │ • Constant low latency envelope │
│ • Great for web pages and files │ • Standard for games, audio & VOIP │
└───────────────────────────────────┴────────────────────────────────────┘
One of the most persistent misconceptions in computer networking is the concept of a "connection."
When developers learn socket programming with TCP, they are taught that connect() establishes a virtual wire between client and server. If a packet is lost in transit, TCP halts the entire stream, buffers subsequent packets, and waits for retransmission before handing anything to your application.
For web pages and file transfers, this is ideal: you cannot display half a JPEG. But for fast-paced real-time games, physical simulations, and voice chat, TCP is catastrophic.
The Problem With Waiting for Yesterday's News
In a fast multiplayer game running at 60 FPS, the simulation advances every 16.6 milliseconds.
Imagine your server sends a position update for an opponent running across the map:
- Packet 101: Position (10, 0, 5)
- Packet 102: Position (11, 0, 5)
- Packet 103: Position (12, 0, 5)
If Packet 101 drops over an unstable Wi-Fi hop, TCP stalls the connection. While it waits for Packet 101 to be re-sent, Packets 102 and 103 sit trapped in the OS kernel buffer. By the time Packet 101 finally arrives 150 milliseconds later, its position data is completely useless: the player is already at position 12.
TCP introduced artificial latency by insisting on delivering obsolete information in strict chronological order.
UDP: The Radio Broadcast Model
UDP does not establish a connection. There is no handshake, no keep-alive signal, and no acknowledgment packet. It behaves like a radio transmitter:
- You format a datagram.
- You hand it to the network socket.
- You tell the operating system where to send it.
If the packet arrives, great. If it drops in the ether, neither the OS nor the network cares.
Because UDP never waits for dropped packets, it has zero head-of-line blocking. New state updates arrive at the hardware interface and pass directly to your game loop without delay. If a packet arrives out of order, your game loop simply checks its sequence counter: if the packet is older than the latest state you already processed, you throw it away.
Game Traffic Taxonomy
| Traffic Category | Protocol | Volume | Examples |
|---|---|---|---|
| Unreliable Unordered | Pure UDP | ~95% | Player positions, look vectors, physics velocity, audio packets |
| Reliable Ordered | RUDP / ACK header | ~5% | Match start/end, round score, inventory loot pickup, health damage |
| Out-of-Band Setup | TCP / HTTPS | Init only | Login authentication, store purchase, match matchmaking handshake |
The Circular Ring Buffer Architecture
To maintain 60+ FPS without hitching, game engines never read UDP packets directly on the main render thread. Doing so would risk stalling frame generation if socket buffers back up.
Instead, a dedicated background thread consumes raw datagrams from the socket and writes them into a thread-safe, lock-free circular ring buffer:
┌────────────────────────────────────────────────────────────────────────┐
│ LOCK-FREE CIRCULAR UDP RING BUFFER ARCHITECTURE │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ Incoming Network Socket │
│ │ │
│ ▼ [Datagrams arrive at 60-120 Hz] │
│ ┌───────────────┐ │
│ │ Network Thread│ ──► writes to head pointer │
│ └───────────────┘ │
│ │ │
│ ▼ │
│ ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐ │
│ │Slot0│Slot1│Slot2│Slot3│Slot4│Slot5│Slot6│Slot7│ ◄── Fixed Memory │
│ └─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘ │
│ ▲ │
│ │ │
│ ┌───────────────┐ ◄── reads from tail pointer │
│ │ Render Thread│ │
│ └───────────────┘ │
│ │ │
│ ▼ [Samples at 60 FPS, interpolates positions smoothly] │
│ Display Frame │
└────────────────────────────────────────────────────────────────────────┘
The background thread writes datagrams to the next open slot in the fixed-size ring array. The main game thread samples the ring buffer once per tick, interpolates entity positions smoothly between the last two confirmed snapshots, and keeps the render loop gliding effortlessly.
Connections are convenient illusions. In real-time engineering, fast datagrams and smart sequence tracking win every time.
References, Standards & Verified Data
- IETF RFC 768 (User Datagram Protocol): RFC 768 Specification (J. Postel, August 1980) - Defines the minimal, connectionless transport protocol providing application-level multiplexing without retransmission or ordering guarantees.
- IETF RFC 793 (Transmission Control Protocol): RFC 793 Specification - Documents TCP's in-order byte-stream mechanics, establishing why packet loss triggers Head-of-Line Blocking and stalls downstream delivery.
- IETF RFC 9000 (QUIC Transport Protocol): RFC 9000 Specification (May 2021) - Demonstrates modern web infrastructure adopting UDP to eliminate TCP head-of-line blocking across independent streams.
- Game Networking Architecture: Glenn Fiedler, "Networking for Game Programmers" (Gaffer on Games, 2006-2016) - Industry standard guides for virtual connection handshakes, sequence bitfield acking, and snapshot interpolation.
- Valve Lag Compensation Standard: Yahn W. Bernier, "Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization" (Game Developers Conference, 2001) - Canonical paper on client-side prediction, entity interpolation, and server backward reconciliation.