Zig Networking: Sockets and TCP

Every application you use today—from your streaming service to your chat app—is essentially an "I/O Machine" that reads and writes through a Network Socket. In high-level languages like Python or JavaScript, this complexity is hidden behind thousands of lines of library code and virtual machines. In Zig, you talk directly to the Operating System Kernel.

This 1,500+ word guide is your deep-dive into the "Wire." We will build a TCP Echo Server from scratch, explore the critical difference between UDP (speed) and TCP (reliability), and understand how to handle "Non-blocking" connections that allow a single machine to support $10,000+$ simultaneous users.

1. What is a Socket? (IP:Port)

A socket is a "Handle" or a "File Descriptor" that represents a network connection.

The Address: A combination of an IP (Who) and a Port (Which door).
The Protocol: Usually TCP (reliable stream) or UDP (fire-and-forget datagrams).

In Zig, we use std.net.Address to handle these. Zig provides built-in parsers for IPv4 and IPv6, ensuring your address handling is type-safe and cross-platform from the start.

2. The Physics of the Wire: Propagation and Latency

When you send a packet, you aren't just sending data; you are pulsing electrons through copper or photons through glass.

The Signal Mirror

The Concept: Data travels at a fraction of the speed of light.
The Physics: Every "Hop" (Router) in the network adds latency. In high-performance Zig networking, we minimize Serialization Delay by using precise buffer sizes that fit into single MTU (Maximum Transmission Unit) frames (usually $1500$ bytes).
The Result: By aligning our application-level buffers with the physical MTU of the network interface, we avoid Packet Fragmentation, reducing the CPU cost of re-assembling packets and ensuring the lowest possible latency for the end-user.

3. The TCP Lifecycle: Listen, Accept, Stream

A server follows a strict architectural pattern to handle incoming traffic.

1. Listen

You tell the OS: "I want to own Port 8080. If anyone knocks on this door, let me know."

2. Accept

The server loops forever, waiting for the OS to "Hand over" a new connection.

zig

3. Read & Write

Once you have a connection, it behaves like any other Stream in Zig. You can use standard readers and writers to transfer bytes.

4. The Kernel Boundary: Socket Descriptors and Buffer Swaps

In Zig, a Socket is more than a variable; it is a Portal to the Kernel.

The Boundary Mirror

The Process: When you call read() or write(), you are requesting a Context Switch. The CPU moves from your "User Land" application into "Kernel Land."
The Physics: The kernel copies data from its protected "Socket Buffer" into your Zig application's memory. This Memory COPY is a performance bottleneck.
Zero-Copy Architecture: High-performance Zig systems use sendfile() or io_uring to tell the kernel: "Don't copy this into my app; just send it directly from the Disk to the Network Card." This bypasses the CPU entirely for data transfer.

5. TCP vs. UDP: Reliability vs. Raw Speed

TCP (Transmission Control Protocol): The "Certified Courier." It ensures every byte arrives in order. If a packet is lost on a noisy Wi-Fi network, TCP waits and re-sends it.
UDP (User Datagram Protocol): The "Firehose." It shoots packets as fast as the hardware allows. If some bytes are lost, it doesn't care.
Which to use? Use TCP for Web APIs and Databases. Use UDP for Voice over IP (VoIP) and online gaming, where a slightly dropped frame is better than a $2$-second delay.

4. Performance: The Poll vs. Blocking Debate

By default, network calls in Zig are Blocking. When you call read(), your thread sleeps until data arrives. This is fine for simple tools, but it fails in a high-load server.

IO Multiplexing

Professional Zig servers use poll, epoll (Linux), or kqueue (macOS).

You give the OS a list of $1,000$ sockets.
You tell the OS: "Wake me up only when one of these has data." This allows a single thread to manage thousands of clients without wasting CPU cycles "Waiting."

5. Byte Order: The "Endianness" Trap

This is the #1 bug in network programming. Most modern CPUs are "Little Endian" (least significant byte first). However, the Internet strictly uses "Big Endian" (Network Byte Order).

If you send the number 1 as a 4-byte integer from your PC without converting it, a Big Endian server will read it as 16,777,216.

The Solve: Use std.mem.nativeToBig before sending data and bigToNative after receiving it.

Networking is the "Voice" of your system. By mastering the Socket lifecycle and the protocol of TCP, you gain the ability to build global, distributed systems that talk to each other across any distance. You graduate from "Input/Output" to "Architecting the Global Wire."

Phase 18: Network Architecture Checklist

Audit your Resource Lifecycle: Use defer to ensure every socket is closed, even in the event of an error union bubble-up.
Implement Endian Conversion: Use std.mem.nativeToBig for every multi-byte integer field in your custom protocol headers.
Optimize for MTU Efficiency: Ensure your "Fast Path" packets are smaller than $1500$ bytes to avoid hardware-level fragmentation.
Setup a Non-Blocking Listener: Use server.accept() in an async loop to handle thousands of concurrent handshakes without thread saturation.
Profile your Serialization Latency: Measure the time spent converting your high-level structs into raw byte arrays for the wire.

Part of the Zig Mastery Course — engineering the wire.