Clients, servers & peers

Key takeaways Most conversations on a network follow the client / server model: a client asks and a server answers. The basic rhythm is request-response — the client sends a request, the server sends back a response, and the client always starts the exchange. The main alternative is peer-to-peer, where there’s no central server and every participant both asks and answers. Most of the internet is clients asking and servers answering, with peer-to-peer as the decentralized alternative.

Almost every time two machines talk, one of them is asking for something and the other is providing it. Naming those two roles — and seeing the one pattern they follow — makes the rest of networking much easier to reason about.

The client-server model

The most common way for programs to talk over a network is the client-server model, and it comes down to two roles:

• A client initiates. It’s the program that wants something and sends a request to get it — a browser loading a page, an app fetching your messages, a script calling an API.
• A server responds. It sits ready, receives the request, and sends back a response with whatever was asked for.

The key detail is direction: the client starts every exchange. A server never reaches out first — it waits to be asked, then replies. If nothing sends a request, a server simply sits idle. That one rule explains most of what follows.

What a server does

A server’s job sounds almost boring: it waits. More precisely, it listens for incoming connections on a known port and, when a connection arrives, handles the request and sends a response. Listen, accept, answer — over and over.

Two things trip beginners up here.

First, a server is a role, not special hardware. We picture servers as humming racks in a data centre, and many are — but “server” just means a program playing the answering role. A Raspberry Pi on your desk, or even the laptop you’re reading this on, becomes a server the moment it runs software that listens for requests.

Second, one machine can be both client and server. These are roles, not fixed identities. A computer can serve web pages to others while, in the same breath, acting as a client to fetch a software update or call another service. The labels describe what a program is doing in a given exchange, nothing more.

Request and response

The heartbeat of the client-server model is request-response: a request goes in, a response comes out. The client asks a specific question — “give me this page”, “save this record” — and the server sends back a specific answer, whether that’s the data requested or a message explaining why it couldn’t.

The classic example is HTTP, the protocol behind the web. Your browser (the client) sends an HTTP request for a page; the web server sends an HTTP response carrying the page back. We’ll unpack that exchange in detail in HTTP, and see how the same pattern powers APIs in web APIs & REST.

This request-then-response rhythm is so common that once you spot it, you’ll recognise it almost everywhere data moves across a network.

Peer-to-peer

Not every system has a central server. In the peer-to-peer (P2P) model there’s no single machine everyone depends on. Instead, every participant is a peer that both requests and serves — asking others for what it needs while providing what it has in return. The peers connect directly to one another rather than routing everything through a middle authority.

You’ve met P2P more often than you might think: file-sharing networks spread downloads across many peers, some chat and calling systems connect people directly, and blockchains keep a shared ledger with no central owner.

The trade-offs are real. Peer-to-peer avoids a single point of failure and can scale as more peers join, since each newcomer brings capacity as well as demand. But it’s harder to coordinate, harder to secure, and harder to keep consistent than a straightforward client-server setup, where one authoritative server calls the shots. Most of the internet sticks with client-server for exactly that reason; P2P shines when decentralization is worth the extra complexity.

Where GopherTrunk fits

You’re already using the client-server model to read this. GopherTrunk’s web interface is a server: it listens on your network, and your browser is the client that sends requests and renders the responses. Every meter, histogram, and control page you open is a request-response exchange.

That’s also a preview of the end of this path. Running GopherTrunk’s interface means putting your own service on the network for other devices to reach — the practical side of being a server. We’ll turn that into a hands-on setup in running a server and GopherTrunk on the network.

Quick check: in the client-server model, who starts the exchange?

Recap

• In the client-server model, a client initiates a request and a server listens and sends a response.
• The client always starts the exchange; a server waits to be asked.
• A server is a role, not special hardware — and one machine can be both client and server.
• Request-response is the basic rhythm, and HTTP on the web is the classic example.
• Peer-to-peer drops the central server: peers connect directly and both request and serve, trading simplicity for decentralization.
• GopherTrunk’s web interface is a server your browser talks to — a preview of putting your own service on the network.

Next up: how a web request works, end to end