AF_UNIX (also called AF_LOCAL) Unix domain sockets use a filesystem path as the address. Data never leaves the kernel — it is copied directly from sender's buffer to receiver's buffer through the kernel's socket infrastructure. They are used for local IPC between processes on the same machine and offer the highest performance.

AF_INET (IPv4) and AF_INET6 (IPv6) are internet domain sockets that use IP address and port number pairs as addresses. Data flows through the full TCP/IP network stack — through the kernel's networking layers and potentially across a physical network. They support communication with processes on remote machines.

Both support SOCK_STREAM (reliable, connection-oriented, byte-stream) and SOCK_DGRAM (message-oriented, unreliable). Unix domain sockets are generally faster since they avoid network stack overhead, but they are limited to local communication.

select() allows a process to monitor multiple file descriptors, blocking until one or more become "ready" (readable, writable, or have an error condition). Internally, select() copies three bitmap sets (readfds, writefds, exceptfds) into the kernel, which checks each fd's state. When any fd is ready, the kernel updates the bitmaps in-place and returns.

Limitations:

• O(n) scanning: On return, you must iterate through all fds to find which are ready, even if only one was ready. Poor scaling with thousands of fds.
• Bitmap limit: The fd sets use fixed-size bitmaps (typically FD_SETSIZE, often 1024), limiting the number of fds you can monitor.
• Reset on return: The fd sets are modified by select(), so you must reinitialize them on each call.

Modern alternatives: poll() solves the fd limit issue (uses array instead of bitmap). epoll() (Linux) solves both — it uses a kernel event list and returns only ready fds, scales to millions of fds, and supports edge-triggered mode. kqueue() (BSD/macOS) provides similar functionality.

SOCK_STREAM provides a connection-oriented, reliable, byte-stream channel. It behaves like a bidirectional pipe — you send bytes, they arrive in order at the other end, with no message boundaries. If you send 100 bytes then 50 bytes, the receiver might read 150 bytes at once, or 50 bytes then 100 bytes, or any other division. TCP is the protocol that implements SOCK_STREAM over IP.

SOCK_DGRAM provides a connectionless, unreliable, message-oriented channel. Each send() delivers a discrete message (datagram) that arrives as a unit. Messages have boundaries — a single recv() returns exactly one datagram. Packets can be lost, duplicated, or arrive out of order. UDP is the protocol that implements SOCK_DGRAM over IP.

Choose SOCK_STREAM when you need reliable ordered delivery with no message framing concerns. Choose SOCK_DGRAM when you need low latency and can tolerate packet loss, or when each message is self-contained and should not be fragmented across recv calls.

When a TCP connection is closed, the endpoint that initiates the close (the one sending the first FIN) enters TIME_WAIT state for a duration of 2 * Maximum Segment Lifetime (MSL), typically 60 seconds on Linux. During this time, the socket pair (IP:port combination) cannot be reused. This exists so that delayed packets from the old connection are not mistaken for packets from a new connection using the same tuple.

This causes problems when restarting a server — you try to bind to port 8080 but it is still in TIME_WAIT from the previous run.

SO_REUSEADDR tells the kernel to allow binding to an address that is in TIME_WAIT. For server sockets, you set this option before calling bind(). For Unix domain sockets, you also need to unlink() the socket path if the file still exists.

int opt = 1;
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
bind(sockfd, ...);

This does not violate the TIME_WAIT safety property because the kernel only allows binding to an address in TIME_WAIT — it does not allow binding to a connection that is still active. Incoming packets for the old connection will still be handled correctly.

send() and recv() may transmit or receive fewer bytes than requested when the kernel's socket buffer is full (send) or no data is immediately available (recv). Both return the number of bytes actually transferred, or -1 on error.

Handling partial sends — always loop until all data is sent:

ssize_t sendall(int sockfd, const void *buf, size_t len) {
    size_t total = 0;
    while (total < len) {
        ssize_t n = send(sockfd, (const char *)buf + total, len - total, 0);
        if (n == -1) {
            if (errno == EINTR) continue;  // Retry
            return -1;
        }
        total += n;
    }
    return total;
}

Handling partial receives — accumulate until a complete message is received. Use a length prefix protocol (4-byte length header) so the receiver knows when a message is complete:

// Read exactly len bytes
ssize_t recvall(int sockfd, void *buf, size_t len) {
    size_t total = 0;
    while (total < len) {
        ssize_t n = recv(sockfd, (char *)buf + total, len - total, 0);
        if (n == 0) return total;  // EOF
        if (n == -1) {
            if (errno == EINTR) continue;
            return -1;
        }
        total += n;
    }
    return total;
}

For streaming protocols, consider using a circular buffer and maintaining a receive state machine that tracks how many bytes of the current message have been received.

The kernel maintains two queues for a listening socket: the accept queue (completed connections ready for accept()) and the SYN queue (incomplete connections that have received SYN but not yet a matching SYN-ACK). When listen(fd, backlog) is called, the backlog argument specifies the maximum size of the accept queue. The actual maximum is also bounded by /proc/sys/net/core/somaxconn.

When the accept queue is full, new completed connections are discarded (silently dropping the final ACK) rather than being queued, causing clients to retransmit until they timeout. accept() simply removes connections from the accept queue; it does not affect the SYN queue. High-performance servers must balance backlog size (memory) against the rate of new connections arriving. Linux also provides TCP_FASTOPEN which bypasses the SYN handshake for previously connected clients, bypassing queue pressure.

Level-triggered mode (the default for epoll) notifies you whenever a file descriptor is ready, as long as the condition persists. If you do not drain all available data when notified, you will be notified again on the next epoll_wait call. Edge-triggered mode notifies you only when the state changes from not-ready to ready, or when new data arrives on a file descriptor that was previously empty.

Edge-triggered mode requires careful handling: you must drain all data when notified (or use EAGAIN returns to stop), and you must handle all file descriptors that become ready on each call or miss events. Edge-triggered is typically used with non-blocking sockets in high-performance servers to avoid spurious wakeups. Level-triggered is easier to program but can generate more events in high-throughput scenarios.

SO_KEEPALIVE enables periodic probes on idle TCP connections to detect if the peer has crashed or become unreachable. When enabled and no data has been sent or received for a configurable period, the kernel sends a zero-checksum probe packet. If the peer responds with an ACK, the connection is alive. If probes fail repeatedly, the connection is closed with ETIMEDOUT.

Configurable via socket options: TCP_KEEPIDLE (time before first probe, default 7200s on Linux), TCP_KEEPINTVL (interval between probes, default 75s), and TCP_KEEPCNT (number of failed probes before giving up). These can be set per socket before connect() or listen(). Keepalive is useful for detecting dead peers in long-lived connections like database connections, but the long defaults mean dead connections may be undetected for hours.

Both Unix domain sockets and FIFOs use filesystem paths as addresses and respect filesystem permissions. Key difference: FIFOs are unidirectional (one reader, one writer) and message-oriented but with read/write semantics (write returns success when data is copied to kernel buffer), while Unix domain sockets are bidirectional and can be stream-oriented (SOCK_STREAM) or datagram-oriented (SOCK_DGRAM).

FIFOs cannot be used with select()/poll()/epoll() for multiplexing multiple readers/writers the way sockets can. A Unix domain SOCK_STREAM socket pair behaves like a bidirectional pipe, while a FIFO requires two named pipes for bidirectional communication. Unix sockets support ancillary messages (file descriptors, credentials), byte-stream ordering, and connection-oriented communication, making them more versatile than FIFOs for most IPC scenarios.

Calling connect() on a UDP socket does not perform a handshake (unlike TCP). Instead, it associates the socket with a specific peer address and records this association in the kernel's socket state. For subsequent send() and recv() calls, the kernel uses the connected peer address, and ECONNREFUSED is returned if the peer is unreachable (ICMP port unreachable). Without connect(), UDP sendto() must specify the destination each time.

Connected UDP provides: automatic use of the peer address (no need to specify on every send), immediate error notification when the peer is unreachable (ICMP errors delivered to socket), and on some systems, improved performance due to reduced address resolution overhead. Connected UDP still has no delivery guarantees but is more efficient for bidirectional UDP communication with a single peer.

Raw sockets bypass the normal protocol stack layers and allow you to construct custom network packets at the IP level or below. With socket(AF_INET, SOCK_RAW, protocol), you receive and send raw IP datagrams with full control over IP headers and payload. You can even use SOCK_PACKET (Linux-specific) to access Ethernet frames directly.

Legitimate uses: network diagnostics tools (ping uses raw ICMP sockets), packet sniffers with BPF, custom tunneling protocols (like GRE or IP-in-IP), network simulation, and firewall implementations. Requires CAP_NET_RAW capability. Raw sockets are a security concern because they can be used for reconnaissance, crafting spoofed packets, and network scanning, which is why many production environments restrict or disable them.

Socket buffers (SO_RCVBUF and SO_SNDBUF) are kernel-managed ring buffers for incoming and outgoing data. If the send buffer is full, a send() call blocks or returns EAGAIN (non-blocking), backpressuring the application. If the receive buffer is full, incoming data is dropped (UDP) or the sender's TCP window closes (TCP), reducing throughput.

The kernel auto-tunes these on modern Linux, but high-throughput or low-latency applications may benefit from manual tuning. Increasing the receive buffer helps when receiving bursts of data. For low-latency, smaller buffers reduce queuing delay. For high-bandwidth-delay-product links (like WAN connections), larger buffers allow more data to be in flight. Linux also provides SO_SNDBUF and SO_RCVBUF with _LOWAT variants to set minimum watermarks.

poll() and select() both copy the file descriptor sets from user space to kernel space and scan all fds linearly on each call, making them O(n) for each notification. poll() uses an array of pollfd structures (no fixed FD_SETSIZE limit like select()), but still has the linear scan problem. Both require re-adding fds after each call (for poll(), events are cleared after each call; for select(), the fd sets are modified).

epoll() uses a kernel-maintained red-black tree of monitored file descriptors and a separate ready list of file descriptors that have events. On epoll_wait(), it returns directly from the ready list without scanning all fds, making it O(1) for notification. It supports edge-triggered mode and one-shot mode (one notification per event until explicitly rearmed). epoll() scales to hundreds of thousands of file descriptors efficiently, which is why nginx and other high-performance servers use it.

Nagle's algorithm (enabled by default on TCP sockets) buffers outgoing data and waits for an ACK before sending more, coalescing small writes into larger segments to reduce packet overhead on low-speed links. For interactive, low-latency applications like remote shells or real-time game updates, this buffering adds unacceptable latency.

TCP_NODELAY disables Nagle's algorithm, sending data immediately without waiting for ACKs. Use it when you have small, latency-sensitive messages that should be sent immediately: keystrokes in an SSH session, game state updates, real-time chat messages. The tradeoff is more packets on the wire and potentially reduced throughput for bulk transfers. Most interactive applications disable Nagle's algorithm.

pipe() creates a unidirectional channel with two file descriptors: fd[0] for reading, fd[1] for writing. Data written to fd[1] is read from fd[0]. socketpair(AF_UNIX, SOCK_STREAM) creates a pair of bidirectional, connected stream sockets where both file descriptors can both send and receive.

socketpair() with SOCK_STREAM provides a bidirectional pipe that works with shutdown() (SHUT_RD, SHUT_WR, SHUT_RDWR) for half-close semantics, can be used with select()/poll()/epoll() for multiplexed communication, and supports out-of-band data (MSG_OOB) and file descriptor passing via sendmsg() with SCM_RIGHTS. A bidirectional protocol is more natural to implement on a socketpair than coordinating two unidirectional pipes.

When the remote end sends FIN (initiating connection close), the local TCP receives the FIN and moves the connection to CLOSE_WAIT state while notifying the application that the connection is closed for sending. The application must call close() to complete the close. After the application buffers are flushed and close() is called, the local TCP sends the final ACK and moves to LAST_ACK. The connection stays in LAST_ACK until the final ACK is received.

Connections stuck in CLOSE_WAIT indicate the application is not calling close() after receiving the remote close. This commonly happens when the application does not properly handle half-closes from the peer. A socket in CLOSE_WAIT holds kernel resources (receive buffer) until the application calls close(). Properly handling shutdown(SHUT_RDWR) or detecting peer close with zero-length recv() prevents socket leaks.

On Linux, read(fd, buf, len) and recv(sockfd, buf, len, flags) are essentially equivalent for socket file descriptors. The key difference is recv() accepts a flags argument: MSG_PEEK (peek at data without consuming it), MSG_DONTWAIT (non-blocking), MSG_OOB (out-of-band data), and MSG_WAITALL (wait for full request).

read() is the generic POSIX file descriptor operation and works on any file descriptor (pipes, files, sockets). recv() is socket-specific and provides socket-related control via flags. For regular sockets without special flags, they behave identically. Using recv() makes the socket-specific intent explicit and provides access to features that read() cannot express.

setsockopt() modifies kernel-level socket behavior at various levels: SOL_SOCKET (generic options like SO_REUSEADDR, SO_KEEPALIVE, SO_RCVBUF), SOL_TCP (TCP-specific like TCP_NODELAY, TCP_QUICKACK), SOL_IP (IP-specific like IP_MTU_DISCOVER), and protocol-family-specific options. Each option has a type and value that the kernel interprets according to the protocol's implementation.

getsockopt() retrieves the current value of an option. Options can be integer values, structs, or binary blobs depending on the option. Some options are read-only (determined by the kernel or connection state) and return errors when set. Setting options before bind() or connect() is important because some options affect connection establishment and cannot be changed after the socket is fully established.

close() closes the file descriptor and, when the last reference to the socket is closed, initiates the TCP close sequence (FIN exchange) if it is a connected socket. It releases the file descriptor and kernel resources. If multiple processes share the socket (via fork), each close() decrements the reference count and only the last one initiates the TCP close.

shutdown() operates at the socket level, shutting down one or both directions of the connection: SHUT_RD (no more receptions allowed, receive buffer is discarded), SHUT_WR (no more sends, initiates FIN), SHUT_RDWR (both directions). shutdown() is useful for half-close patterns where one direction closes while the other remains open, which close() cannot express. shutdown() does not release the file descriptor itself.

io_uring is a Linux kernel interface (5.1+) that enables high-performance asynchronous I/O for sockets, files, and other I/O operations. Unlike traditional async I/O (select/poll/epoll are synchronous multiplexing), io_uring uses a pair of ring buffers (submission queue and completion queue) shared between the application and kernel. The application submits I/O operations by filling the submission queue ring buffer; the kernel processes them and returns results in the completion queue ring buffer.

Key advantages: true async send/recv with IORING_OP_SEND and IORING_OP_RECV that return immediately and notify via completion queue, batched submissions that amortize syscall overhead, and features like fixed buffers that eliminate per-operation memory allocation. For high-frequency socket I/O, io_uring reduces context switch overhead significantly compared to epoll with blocking send/recv. Libraries like liburing make io_uring accessible to applications.