The way in which network communication happens is very similar to Interprocess Communiucation.
A network connection between two endpoints (say, A and B) involves two queues:
- One for outgoing data (send buffer).
- One for incoming data (receive buffer).
These queues decouple the sender and receiver, allowing asynchronous communication.
When data arrives from the network, it is first stored in a network buffer managed by the operating system. If the receiving process has not yet issued a read, the data simply accumulates in the buffer.
Only when the process performs a read operation does the data get transferred from the buffer into the process’s memory space.
This buffering ensures that network communication can tolerate timing mismatches between sender and receiver, but it also introduces the need for careful protocol design.
Protocol Design
Protocols become critical when communication spans across networks. They define how data is structured, transmitted, acknowledged, and retransmitted if errors occur. Without protocols, processes would have no agreed-upon rules for interpreting the raw bytes arriving in buffers.
Examples include:
- TCP ensures reliable, ordered delivery of data streams.
- UDP provides lightweight, connectionless communication but leaves reliability to the application.
Socket Abstraction
Sockets are the standardized abstraction for network communication. They are the software endpoints for two-way communication between two programs running on a network.
Like 'Pipe' is used to create pipes and sockets are created using 'socket' system call. The socket provides bidirectional FIFO Communication facility over the network.
They act as double-sided endpoints:
- Each socket is bound to a port and an IP address.
- Together, they uniquely identify a communication channel.
Pipes and shared memory queues are local IPC mechanisms. Sockets extend the same queue-based abstraction across machines.
Sockets are standardized across platforms, making them the universal interface for network programming. They provide the same abstraction whether you’re building a web server, chat application, or distributed database.
Think of sockets as mailboxes:
- Each port is like a unique street address.
- The socket is the actual mailbox, holding letters (messages) until the resident (process) picks them up.
- Protocols are the postal rules, ensuring letters arrive intact, in order, and to the right address.
Sockets are designed to look like file descriptors:
write()sends data.read()receives data.
This design leverages the Unix philosophy of treating “everything as a file,” simplifying the programming model.
The simple socket model assumes:
- No corruption in transmission.
- Both reader and writer are active and synchronized.
In reality, networks can corrupt or lose packets or processes may crash or stall. Protocols like TCP handle these issues with checksums, retransmissions, and flow control.
Ports and Multiplexing
A single machine may host multiple network services simultaneously (e.g., a web server, mail server, and database).
Ports are numerical identifiers that allow the operating system to distinguish between these services. Each port represents a unique communication channel, enabling multiple concurrent connections without confusion.
A port is a 16-bit number (range: 0–65535). Certain ports are well-known (e.g., 80 for HTTP, 443 for HTTPS). Others are dynamically allocated for client connections.
Here is how a port differs from a socket:
- A port is the identifier for a communication endpoint.
- A socket is the actual data structure maintained by the OS, holding buffers, state, and metadata.
Unlike files, sockets don’t exist in a structured filesystem namespace. Instead, the namespace for sockets is defined by:
- IP address: identifies the host machine.
- Port number: identifies the specific communication channel on that host.
Together, (IP, Port) uniquely identifies a socket endpoint.
Connection Establishment
A server creates a listening socket bound to a well-known port. It waits for incoming connection requests.
A listening socket is an application-level endpoint that waits for incoming client connections on a specific port. It uses bind() to associate with a port, listen() to monitor for incoming requests, and accept() to establish communication, enabling two-way data exchange via TCP.
Unlike client sockets that initiate connections, a listening server acts as a passive receptor.
A client initiates a connection, often using a randomly chosen ephemeral port. The request is validated against the server’s listening socket. Once accepted, the server creates a new socket dedicated to that client.
This allows the listening socket to continue accepting new requests. A connection is uniquely identified by a 5-tuple:
- Source IP
- Source Port
- Destination IP
- Destination Port
- Protocol (e.g., TCP).
This ensures that multiple simultaneous connections can coexist without confusion.
Concurrency in Servers
Servers must handle multiple clients simultaneously.
The standard design pattern to enable this is as follows:
- The server continues listening on the original socket.
- For each new client, it spawns a new execution context (process or thread).
- The child context handles communication with that client, while the parent remains available for others.
The creating of a child context can happen in two ways:
- Forking processes:
Each client connection is handled by a separate process. This provides strong isolation (memory protection). But this is expensive: process creation and context switching are costly.
- Threads:
Threads are lighter weight than processes. Threads share memory space, making communication easier. But they have weaker isolation: a bug in one thread can affect the entire server.