Learning Question
Why does network communication often look like file I/O in a program?
Network communication is another form of OS-managed I/O.
On Unix/Linux, a socket can be represented by a file descriptor, and programs use system calls to send and receive bytes.
The first mental model is:
A socket is an OS-managed communication endpoint that lets a process exchange data through network protocols.
Sockets as Endpoints
A socket is not the remote server itself.
It is a local endpoint managed by the operating system.
The process uses the socket descriptor to ask the kernel to send or receive data.
The kernel handles protocol state, buffers, routing decisions, and interaction with network devices.
For TCP, the socket participates in a connection with ordering, reliability, flow control, and connection state.
For UDP, the socket sends and receives datagrams with different guarantees.
The socket API hides much of that complexity behind descriptor-based operations.
Client Connections
A client process that connects to a server usually follows a path like:
- create a socket
- resolve or choose a remote address
- ask the kernel to connect
- send and receive data through the socket
- close the socket
The connect operation is not a direct jump into the server process.
It asks the local kernel to establish communication through the network stack.
Only after the protocol-level connection is established can application bytes flow.
Server Listening
A server process commonly:
- creates a socket
- binds it to a local address and port
- listens for incoming connections
- accepts a connection
- receives and sends data on the accepted socket
The listening socket and an accepted connection socket are different roles.
The listening socket represents the server’s readiness to receive connection attempts.
The accepted socket represents one established communication path with a peer.
This distinction prevents a common confusion:
A server does not handle all clients through one magical connection. It accepts individual connection endpoints from a listening socket.
Network I/O Can Block
Network reads and writes may block.
A receive operation may wait for data.
A send operation may wait for buffer space.
A connection attempt may wait for protocol progress or fail.
The kernel can put the thread to sleep while waiting for network events.
Alternatively, programs can use nonblocking I/O or event notification mechanisms to manage many sockets without one blocking thread per connection.
Those mechanisms are advanced, but the boundary remains:
The process asks for network I/O. The OS tracks readiness, buffers, protocol state, and wakeups.
Bytes Versus Messages
TCP gives a byte stream, not application-level messages.
If an application sends two logical messages, the receiver may not receive them in the same chunks.
The application protocol must define message boundaries.
HTTP, for example, defines its own structure over bytes.
This matters because the OS provides the transport abstraction, not the full meaning of the application data.
Network Devices and the Kernel
Network cards and drivers are below the socket interface.
A user program does not usually transmit Ethernet frames directly.
It writes bytes to a socket.
The kernel’s network stack packages data according to protocols, uses device drivers, receives interrupts or polling events, and moves data through buffers.
The program sees socket operations and errors.
The OS manages the layers beneath that interface.
Core Mental Model
Networking is OS-mediated I/O through sockets.
When diagnosing network behavior, ask:
Is the issue in the application protocol, the socket state, kernel buffers, connection state, address/port binding, or the network path below the process?
Final Summary
Sockets make network communication available to programs as OS-managed I/O endpoints.
Programs use descriptors and system calls, while the operating system manages protocol state, buffering, blocking, device interaction, and delivery across process and machine boundaries.