Socket Programming Fundamentals

A socket is a software abstraction the operating system exposes to an application, representing one endpoint of a communication channel. Concretely, a socket is a file descriptor (an integer handle) that the kernel associates with a protocol (TCP or UDP), a local address and port, and — for connected sockets — a remote address and port. The application never touches packets, checksums, or routing tables directly; it calls a handful of functions (`socket`, `bind`, `connect`, `listen`, `accept`, `send`, `recv`, `close`) and the kernel's networking stack does the rest. The two socket types you will use constantly correspond to the two transport protocols. A stream socket (`SOCK_STREAM`) rides on TCP: it gives the illusion of a reliable, ordered, full-duplex byte stream between two endpoints, with explicit connection setup and teardown. A datagram socket (`SOCK_DGRAM`) rides on UDP: each send is a self-contained message with no guarantee of delivery, order, or deduplication, and there is no connection state to establish. Choosing between them is a choice about what guarantees your application needs versus what latency and overhead it can tolerate — a tradeoff formalized later when studying transport-layer protocols in depth. A socket is addressed by a socket pair: (local IP, local port, remote IP, remote port, protocol) for TCP, or just (local IP, local port) for a UDP socket that hasn't called `connect()`. The kernel uses this tuple to demultiplex incoming segments to the correct application process — this is precisely why a single server port can serve thousands of simultaneous TCP clients: each accepted connection gets its own socket, distinguished by the client's IP and port, even though all of them share the same server-side listening port number.

The TCP connection lifecycle

A TCP client-server exchange follows a fixed sequence of system calls on each side, which mirrors the transport-layer three-way handshake (SYN, SYN-ACK, ACK) underneath.

Server side, performed once at startup: 1. `socket()` — allocate a new socket descriptor, specifying TCP. 2. `bind()` — associate the socket with a local IP and a well-known port. 3. `listen()` — mark the socket as passive, and set a backlog queue size for pending connections. 4. `accept()` — block until a client connects; returns a new socket descriptor dedicated to that one client, while the original listening socket keeps listening.

Client side, performed once per connection: 1. `socket()` — allocate a socket descriptor. 2. `connect()` — specify the server's IP and port; this call triggers the handshake and blocks until it completes (or fails). After `accept()`/`connect()` return successfully, both sides have a connected socket and call `send()`/`recv()` (or `write()`/`read()`) symmetrically until one side calls `close()`, which initiates TCP's four-way connection termination. The crucial architectural point: the server's listening socket and the per-client socket returned by `accept()` are different descriptors. This is what lets one server process (or thread pool) handle many clients on the same port — the listening socket is a factory for connected sockets, not a channel for data itself.

The UDP lifecycle

UDP removes the connection ceremony entirely. A server calls `socket()` and `bind()` only, then loops on `recvfrom()`, which blocks until any client sends a datagram and reports that client's address alongside the data. The server can `sendto()` a reply to that address without any prior handshake. A client can skip `bind()` altogether (the OS assigns an ephemeral port automatically) and simply call `sendto()` with the server's address. There is no `listen()`, no `accept()`, and no persistent per-client state at the socket layer — any reliability or session tracking must be built by the application itself.

Pseudocode: TCP echo server and client

``` // ---------- TCP SERVER ---------- function tcp_server(port): listen_sock = socket(AF_INET, SOCK_STREAM) set_option(listen_sock, SO_REUSEADDR, true) // allow fast restart bind(listen_sock, local_addr("0.0.0.0", port)) listen(listen_sock, backlog = 128) while true: client_sock, client_addr = accept(listen_sock) // blocks handle_client(client_sock, client_addr) // could fork/spawn thread here close(client_sock) function handle_client(sock, addr): buffer = bytes(4096) while true: n = recv(sock, buffer, 4096) // returns 0 <= n <= 4096 if n == 0: break // peer closed connection cleanly send_all(sock, buffer[0:n]) // echo back exactly what we got function send_all(sock, data): total_sent = 0 while total_sent < length(data): sent = send(sock, data[total_sent:]) if sent <= 0: raise ConnectionError total_sent += sent // ---------- TCP CLIENT ---------- function tcp_client(server_ip, port, message): sock = socket(AF_INET, SOCK_STREAM) connect(sock, remote_addr(server_ip, port)) // triggers 3-way handshake send_all(sock, message) reply = bytes(4096) n = recv(sock, reply, 4096) print("Echoed back:", reply[0:n]) close(sock) // initiates connection teardown ``` ``` // ---------- UDP SERVER ---------- function udp_server(port): sock = socket(AF_INET, SOCK_DGRAM) bind(sock, local_addr("0.0.0.0", port)) buffer = bytes(4096) while true: n, client_addr = recvfrom(sock, buffer, 4096) // no connection needed sendto(sock, buffer[0:n], client_addr) // echo to sender // ---------- UDP CLIENT ---------- function udp_client(server_ip, port, message): sock = socket(AF_INET, SOCK_DGRAM) sendto(sock, message, remote_addr(server_ip, port)) reply = bytes(4096) n, _ = recvfrom(sock, reply, 4096) print("Echoed back:", reply[0:n]) close(sock) ``` Two design decisions embedded in this pseudocode deserve attention. First, `handle_client` loops on `recv` until it returns `0`, because TCP is a byte stream with no built-in message boundaries — a single `send()` of 4000 bytes on one side might arrive as two separate `recv()` calls of 2500 and 1500 bytes on the other, or even be coalesced with a subsequent send. Second, `send_all` loops because `send()` is permitted to write fewer bytes than requested (e.g., if the kernel's send buffer is temporarily full) — treating its return value as "all bytes sent" is one of the most common socket bugs in production code.

Concurrency: serving many clients at once

The pseudocode above serves clients sequentially — a slow client blocks all others. Real servers use one of three patterns:

• Process-per-connection: `fork()` after `accept()`; the child handles one client and exits. Simple, robust, but heavyweight (used by early Apache).
• Thread-per-connection: spawn a lightweight thread per accepted socket; shares memory, avoids fork's cost, but many threads have scheduling and memory overhead at scale.
• Event-driven multiplexing: use `select()`/`poll()`/`epoll()` (Linux) or `kqueue()` (BSD) to monitor many sockets with a single thread, reacting only when a socket has data ready. This is how Nginx and Node.js achieve tens of thousands of concurrent connections on a handful of threads.

Time complexity of setup: `socket()`, `bind()`, `listen()` are $O(1)$ kernel operations — they touch fixed-size kernel data structures (the socket descriptor table, a listening queue) regardless of network conditions. `connect()` and the corresponding `accept()` complete in time bounded by network round-trip time (RTT) for the handshake: one RTT in the common case (SYN out, SYN-ACK back, ACK sent without waiting for a reply). This is a latency cost, not a computational one — the CPU work is $O(1)$; the wall-clock delay is dominated by physical propagation and queuing delay, which is why connection reuse (as in HTTP keep-alive, foreshadowing HTTP and the Web) is such a valuable optimization.

Time complexity of data transfer: `send()`/`recv()` on an established socket cost $O(n)$ in the number of bytes copied between user-space buffers and kernel-space socket buffers — a memory copy, not a computation. Throughput is governed by the transport protocol's flow control and congestion control (TCP's sliding window and AIMD algorithm), not by the socket API itself; the API is a thin, low-overhead wrapper.

Space complexity: each open socket consumes kernel memory for its send and receive buffers (typically tens of kilobytes, tunable), plus a small fixed-size control block holding state (TCP state machine phase, sequence numbers, timers). A server with $C$ concurrently open connections uses $O(C)$ kernel memory and, in the thread-per-connection model, $O(C)$ additional memory for thread stacks — this is precisely the scalability limit that motivates event-driven I/O multiplexing for large $C$.

Correctness argument — the byte-stream invariant: TCP guarantees only that bytes written by `send()` on one end arrive at the other end in the same order, eventually, with no gaps and no duplicates (assuming the connection doesn't fail) — it makes no promise about message boundaries. Formally, if the client issues writes producing the byte sequence $b_1 b_2 \ldots b_n$ (concatenated across however many `send()` calls), the server's sequence of `recv()` calls will read back exactly $b_1 b_2 \ldots b_n$ in order, but the partitioning into individual `recv()` return chunks is unspecified and may not match the sender's chunking at all. Any correct TCP application must therefore either (a) treat the connection as a raw byte stream and define its own message framing (length prefixes or delimiters), or (b) loop until a known-length message is fully assembled, exactly as `send_all` and the `recv`-until-zero loop do above. This is not a defect of TCP — it follows directly from the reliable-byte-stream abstraction TCP is defined to provide, and any pseudocode that assumes "one `send()` equals one `recv()`" is unsound by construction.

Correctness argument — UDP has no such invariant at all: a UDP `sendto()` maps to at most one IP datagram; a `recvfrom()` returns at most one complete datagram (or nothing, if none has arrived, or an error). Datagrams may be dropped, duplicated, or reordered by the network, and the socket API surfaces this directly — there is no retransmission, no acknowledgment, and no window. Any application-level reliability (sequence numbers, timeouts, retransmission, deduplication) must be built by hand on top, which is exactly what protocols like DNS-over-UDP, TFTP, and QUIC's own reliability layer do.

Tradeoffs made explicit:

Trace a client sending the message `"HELLO"` (5 bytes) to the TCP echo server above, followed by a second, larger message, to show the partial-read behavior explicitly.

Now suppose the client sends a 9000-byte payload in one `send()` call, exceeding the typical maximum segment size (roughly 1460 bytes on an Ethernet path with a 1500-byte MTU):

This trace demonstrates concretely why `handle_client`'s echo loop must not assume `n == length(sent_message)`, and why any protocol built on raw TCP sockets needs explicit framing (e.g., prefixing each message with its length in bytes) if message boundaries matter to the application.

The socket abstraction was not designed in isolation — it emerged from the effort to make the fledgling ARPANET, and later TCP/IP, programmable from ordinary application code without every programmer needing to understand packet formats.

Every networked application you use daily is, at its lowest programmable layer, a socket program. Web browsers and servers open TCP sockets on port 443 for HTTPS and port 80 for HTTP — the subject of HTTP and the Web is precisely "what bytes flow over an already-established socket." DNS resolvers use UDP sockets on port 53 for fast, connectionless lookups, falling back to TCP for large responses. Video conferencing and multiplayer games use UDP sockets directly (often wrapped in protocols like RTP or QUIC) because retransmission-induced delay is worse than an occasional dropped frame. Databases, message queues (Kafka, RabbitMQ), and remote procedure call frameworks (gRPC) all open long-lived TCP sockets between services, and modern container orchestration systems (Kubernetes) route traffic by manipulating exactly the (IP, port) tuples that socket addressing depends on. Understanding sockets is also the entry point to Peer-to-Peer Architectures, where every node runs both server code (listening for peers) and client code (connecting to peers) simultaneously — a symmetric use of the exact same API introduced here.

Ask the tutor: How would you extend this TCP echo server to safely handle length-prefixed messages instead of treating the connection as an undelimited byte stream?