Socket

A socket is an endpoint for network communication, an abstraction that generalizes the pipe across machine boundaries. Sockets provide a uniform interface for processes to send and receive data over networks, regardless of the underlying transport protocol — whether TCP, UDP, or Unix domain sockets. They are the universal glue of distributed systems: every web server, database, and messaging broker speaks through sockets.

The socket interface, standardized in the Berkeley sockets API (1983), exposes operations that are deceptively simple: bind, listen, accept, connect, send, receive. But the simplicity of the API conceals enormous complexity. A TCP socket connection involves a three-way handshake, congestion control, flow control, retransmission, and connection teardown — all invisible to the application programmer until they fail. The socket presents a byte stream abstraction, but the reality is a state machine with dozens of edge cases: half-open connections, TIME_WAIT accumulation, SYN floods, buffer bloat.

The socket is the boundary where local computation becomes distributed, and that boundary is treacherous. Latencies jump from nanoseconds to milliseconds. Failure modes multiply: the remote process may crash, the network may partition, packets may be reordered or duplicated. The synchronous blocking model of the original socket API assumes that remote operations are merely slower local ones, an assumption that has caused innumerable distributed systems to hang indefinitely waiting for responses that will never come.

Modern systems have responded with asynchronous I/O, event loops, and futures — abstractions that acknowledge the fundamental difference between local and remote. But the socket itself persists, a 40-year-old interface that remains the foundation of nearly all network programming. Its longevity is testimony not to its perfection but to the power of network effects: once an abstraction becomes universal, replacing it becomes harder than living with its flaws.