Core CS · Computer Networks

One machine serves everyone, or everyone serves each other

Two ways to arrange who provides and who consumes. You will send one file to four laptops both ways, count what each arrangement costs, and get the honest answer to “which is better”.

Send one file to four peers, two ways →

A server is whatever is already listening at an address you know. A client is whatever speaks first. Client server puts those two roles on two different machines and keeps them there; peer to peer puts both roles on every machine.

01 The idea

Somebody has to be listening first

Nothing on a network happens until one side speaks. For that to work, the other side has to already be there: a process running, bound to an address and a port, doing nothing but waiting. That waiting process is the server. The one that speaks first is the client. Every exchange you have ever made over a network has those two halves, and the whole of this lesson is about where you put them.

In the client server arrangement they live on different machines and stay there. One machine is always on, has a name in DNS that everybody can look up, and answers requests. The clients are laptops and phones that appear, ask for something, and go away. A client never has to be reachable, because it always speaks first and the reply comes back down the connection it opened. That single asymmetry explains most of what follows: why your laptop needs no fixed address, why the server needs a very fixed one, and why the server can never start the conversation.

In peer to peer every node runs both halves. It has a client part, so it can ask for what it does not have, and a server part, so it can hand out what it does. There is no machine whose job it is to be on. Peers arrive, share for a while, and leave, and the system is expected to keep working through all of it. What you gain is that every arrival brings its own storage and its own uplink. What you lose is every guarantee that came from having one place that is always there.

Client server buys you one place that is always on, always addressable and always in charge, and you pay for that place in money, in somebody whose job is to keep it running, and in a single point of failure. Peer to peer refuses to buy it, and pays instead in trust, discoverability and durability.

ServerA process that is already running, bound to a known address and port, waiting to be spoken to. It never speaks first. Being a server is a role in one exchange, not a label on a box.

ClientThe process that starts an exchange. It must know where the server is; the server learns where the client is from the packets that arrive, and forgets when the connection closes.

PeerA node running both parts at once, so it can request the pieces it lacks and serve the pieces it holds. It owes the network nothing: it may leave mid-transfer and usually does.

02 Worked example

One lecture recording, four laptops in a hostel

A 300 MB lecture recording sits on a college server whose uplink runs at 100 Mbps. Four students want it. Do the units first, because this is where these questions are lost: 300 MB is 300 × 10⁶ bytes = 2,400 megabits, so one complete copy across a 100 Mbps link takes 2,400 Mb / 100 Mbps = 24 s. Call that one round. Everything below is counted in rounds.

1 · One copy existsthe file is on the server; four laptops have nothing and know the server’s name

→

2 · Four clients askeach laptop opens its own connection and requests the whole file; the server never asks anything

→

3 · One uplink carries all of it4 copies × 300 MB = 1.2 GB out of one link, 4 rounds, 96 s for the last laptop

→

4 · The first laptop that finishes can servegive it a server part and it stops being only a consumer

→

5 · Sources double each round1, then 2, then 4 uploaders: all four finish in 3 rounds and the server sends one copy

The highlighted node is the entire difference between the two architectures, and it is one sentence: a laptop that has finished downloading is a machine with a copy of the file and an idle uplink. Client server cannot use it, because a client has no server part and nobody would know to ask it. Peer to peer uses it, and from that moment the number of possible sources grows instead of staying at one.

Count both. Client server needs one round per laptop, so four laptops take 4 rounds, the last one waits 4 × 24 s = 96 s, and 12 units of 100 MB each cross the server’s uplink. Peer to peer seeds one copy in round 1, then holders double: 1 holder, 2 holders, 4 holders, so it takes 3 rounds, 3 × 24 s = 72 s, and the server uploads 300 MB once. Now scale it to sixteen laptops. Client server needs 16 rounds, 16 × 24 s = 384 s. Peer to peer needs 1 + log₂16 = 5 rounds = 120 s. The gap is not a constant factor; it widens with every participant.

This is the textbook model and it flatters peer to peer. It assumes every laptop uploads as fast as the server does, which most home broadband connections cannot, because consumer links are usually asymmetric and give you far less upload than download. It also assumes a peer must hold the whole file before it can serve; real BitTorrent lets a peer forward a piece the moment it has that piece, which pushes back the other way. Interviews test the model. Say the model, then name both corrections.

03 Mechanics

The eight properties an interviewer walks down

One row per property, and the row is only worth marks if you can say why. The last column is the follow-up you will get, so answer it before it is asked. Read the two middle columns as a trade, never as a winner: almost every advantage on one side is a cost on the other side of the same row.

Property	Client server	Peer to peer	The follow-up
Who speaks first	The client, always. The server never initiates a connection to a client.	Either side. Every node has a client part and a server part running at once.	`then how does a server push?` It answers inside a connection the client opened first.
Addressing	The server needs a fixed, published address: a DNS name and a well-known port, `443` for HTTPS.	No peer needs a fixed address. A directory or a distributed hash table hands out whoever is online now.	`and the client?` It needs no address anyone has to look up in advance; a temporary one it did not choose is enough, which is why it can sit behind NAT and a server usually cannot.
Cost	`you buy the machine, the power and the bandwidth, and you pay for peak demand all year`	Nothing extra. It runs on capacity the participants already own and are already paying for.	`is it really free?` No: you still pay for discovery, and for the seeder that keeps rare content alive.
Administration	One place to patch, configure, monitor and audit. A change takes effect for everybody at once.	`every node administers itself; there is no place to stand to change anything`	`who upgrades the protocol?` Nobody can, centrally, so peers must stay compatible with old versions for years.
Access control	One gate. The server authenticates you and decides per request what you may see.	`no gate exists; anyone who can reach a peer can ask it for anything it holds`	`so how is anything trusted?` By verifying the bytes, not the sender: every piece is checked against a hash agreed in advance.
Backup and durability	One canonical copy, so a schedule, a retention policy and a restore test are all possible.	`no canonical copy; the file exists while peers happen to hold it and vanishes when they stop`	`is replication not backup?` No. Many copies of a file somebody deleted is many copies of nothing.
As demand rises	`capacity is fixed at whatever the server has, so each client’s share falls as clients arrive`	Each arrival brings an uplink, so capacity rises roughly with the number of participants.	`can you not add servers?` Yes, and that is what a CDN is: still client server, only more of it, and you pay for it.
Failure	`the server is a single point of failure; it goes down and the service is gone for everyone`	No single node whose loss stops the system. Peers route around whoever left.	`so P2P cannot fail?` It can: a central tracker is one point, and content dies when the last holder leaves.

Now the honest part, because pure peer to peer is rare and interviewers know it. Nearly every deployed system is a hybrid: a small central service does discovery, and the payload never touches it. That is the index server pattern. Napster was the first at scale, and it is also the cleanest warning: the transfers were peer to peer, but the index was one company’s server, and shutting that server down ended the network. Gnutella answered by removing the index entirely and paid for it by flooding every search query to its neighbours, which does not scale either. BitTorrent settled in between.

peer    → tracker   GET /announce?info_hash=...&peer_id=...&port=6881tracker → peer      a list of ip:port for peers on this torrentpeer    ↔ peer      the pieces themselves, direct, in both directions -- discovery is client server. the payload is peer to peer. the tracker-- never sees one byte of the file, so it needs almost no bandwidth.-- BEP 5 adds a DHT: the peer list itself is stored across the peers,-- so a swarm can survive with no tracker at all.-- every piece is checked against a hash from the .torrent before it-- counts: SHA-1 per piece in v1, SHA-256 in v2 (BEP 52).

Lines 1 and 2 are an ordinary client server exchange over HTTP, and they are the only lines a tracker takes part in. Line 3 is where the 300 MB goes, and the tracker cannot see it, throttle it or be overloaded by it. That split is why the pattern works: the central component carries the metadata, which is tiny, and the decentralised part carries the payload, which is not. Lines 9 and 10 are what replaces the missing gate. You cannot trust a peer, so you do not have to: a peer that sends you a corrupt piece fails the hash and the piece is discarded.

The index server pattern is the answer to almost every “how would you design X peer to peer” question. Keep one small central service for the thing that must be findable, and let the expensive traffic go directly between the participants. Then say out loud which central-point risks you have accepted by keeping it.

05 Cheat sheet

The card to read on the morning of the interview

Nine rows. Six of them carry a rose cell marking the side that loses that row, and the rose cells fall in both columns, which is the point: there is no column that wins the table. The other three rows are facts, not verdicts.

Question	Client server	Peer to peer
Who initiates	the client, every time	any peer; both roles run on every node
Fixed address needed	yes, for the server: DNS name plus a well-known port	no; a tracker or DHT finds whoever is online
Cost to run	`a dedicated always-on machine and its bandwidth`	the participants’ own spare capacity
Administration	one place to patch, configure and audit	`every node on its own; no central place to change anything`
Access control	one gate; authenticate then authorise per request	`no gate; trust the hash of the content, never the sender`
Backup	one canonical copy you can schedule and restore	`no canonical copy; data lives only while peers hold it`
As demand rises	`capacity fixed; every new client gets a smaller share`	capacity rises with each participant
Single point of failure	`yes, the server; it stops and everyone stops`	none in the transfer path; a tracker is still one
Where you meet it	HTTPS on 443, DNS on 53, IMAPS on 993, online banking	BitTorrent swarms, Bitcoin gossip on 8333, phone-to-phone Wi-Fi Direct transfers

Pure peer to peer is rareAlmost everything shipped is a hybrid: a small central index makes peers findable and the payload goes directly between them. Napster proved the pattern and proved its weakness at once: the transfers were peer to peer, but the index belonged to one company, and a court order against that index ended the network. Gnutella deleted the index and had to flood every query instead.

The role is per exchange, not per machineA mail server that accepts your message turns around and becomes a client of the next server’s port 25 to deliver it. One process, both roles. Never answer “is this machine a client or a server” without first asking which exchange you mean.

No gate means you verify the bytesWith no server to vouch for anything, a peer to peer system checks content instead of senders. BitTorrent hashes every piece and puts the hashes in the .torrent file, SHA-1 in version 1 and SHA-256 in version 2, so a peer that sends you rubbish is caught by arithmetic rather than by trust.

06 Where & why

Four systems running right now, and which way each leans

Every one of these is something you can point a tool at today. Name the system, then name which half of it is client server and which half is not, because the interesting systems are almost never all one thing.

nginx · HTTPS on 443

The web is client server by definition

Your browser speaks first, every time. A web server cannot decide to send you a page, because it does not know where you are until you connect. Server push exists only inside a channel the client opened first, which is exactly what WebSocket and server-sent events are for. Online banking is the same shape with the stakes turned up: one gate, one audit log, one backup.

Google Public DNS 8.8.8.8

Client server all the way down

Your device is a client of a resolver at a fixed address on port 53, and that resolver is in turn a client of the root, TLD and authoritative servers. Nothing in the chain ever calls you back. The hierarchy looks distributed, and it is, but every single hop in it is one client asking one server that was already listening.

BitTorrent trackers · DHT

Central directory, peer to peer payload

The tracker announce is an ordinary HTTP request and gets back a list of peers. Every byte of the file then moves peer to peer, which is why a tracker for a huge swarm needs almost no bandwidth. BEP 5 spreads the peer list across the peers themselves, so a swarm can run with no tracker at all. This is the index server pattern in its most quoted form.

Bitcoin Core on port 8333

Gossip with no directory to shut down

Every full node stores the whole chain and relays new blocks and transactions to the neighbours it is connected to. There is no address whose loss stops the network, and no operator to serve a court order on. The nearest thing to a directory is bootstrap: a brand new node finds its first few peers through DNS seed names shipped inside the software, then keeps its own address book and stops needing them. The price is paid in the other columns: every node keeps a full copy, admits no administrator, and validates everything itself because it can trust nobody.

Which is better? Neither, and an interviewer asking it is testing whether you will pick one. The deciding question is whether you can afford a central point and whether everybody involved can trust it. If yes, take client server, because control, backup and access control are worth real money. If no, or if the traffic would bankrupt you at scale, push the payload out to the participants and keep the smallest central directory you can defend.

07 Interview questions

What they actually ask

This is a first-round networking question and it is usually answered as two memorised lists. What separates candidates is naming a trade in both directions and admitting that the real system in front of you is a hybrid.

What is the client server model, in one line?

One machine runs a process that is always on, bound to a known address and port, and it answers requests from many machines that are not. The client always speaks first and the server never initiates. Everything else about the model — the cost, the single point of failure, the one place to enforce access control — falls out of putting the two roles on two different machines and leaving them there.

What makes a peer different from a client?

A peer runs a server part as well as a client part, so it can serve what it holds instead of only asking for what it lacks. That one addition is what lets capacity grow: a client that finishes downloading is a machine with a copy and an idle uplink that nobody can use. A peer in the same position is a new source.

Does the server ever speak first?

No. A server cannot open a connection to a client, because it does not know where the client is until the client connects, and the client usually has no fixed address to be reached at. What looks like the server speaking first always happens inside a channel the client opened: WebSocket, server-sent events, or long polling. A phone notification is the same trick one level out — the phone holds an open connection to a push service it is a client of.

Why does the client not need an address of its own?

Because it always initiates. The server learns the client’s address from the packets that arrive and replies down the same connection, then forgets. The server has the opposite problem: it must be findable before anybody has spoken to it, which is why it needs a stable address published in DNS and a well-known port such as 443. This is also why a client behind NAT works fine and a server behind NAT does not.

Compare the two on cost and administration.

Client server costs money continuously: a dedicated always-on machine, its power and its bandwidth, sized for peak demand rather than average. In exchange you get one place to patch, configure, monitor and audit, and a change applies to everybody the moment you make it. Peer to peer costs almost nothing to run because it uses capacity the participants already own, and it gives you nowhere to stand when you need to change something — you cannot upgrade nodes you do not control, so peers must stay compatible with old versions for years.

Which is more secure?

Neither, and the honest answer names what each one is doing about trust. Client server has one gate: you authenticate at the server and it decides per request what you may see, which also means one machine worth breaking into. Peer to peer has no gate at all, so it cannot trust the sender of anything and verifies the content instead — BitTorrent checks every piece against a hash agreed in advance, so a peer sending corrupt data is caught by arithmetic. Centralised control is a security property and a security risk in the same sentence.

What happens to each one as demand rises?

Client server capacity is fixed at whatever the server has, so each extra client gets a smaller share. Peer to peer capacity rises with participants, because each arrival brings an uplink. In this lesson’s run, one file to four peers takes 4 rounds and 12 units of server upload one way, and 3 rounds and 3 units the other. The catch is that the model assumes peers upload as fast as the server, and most consumer connections are asymmetric, giving far less upload than download.

Is peer to peer really free of a single point of failure?

Not in most real deployments. The transfer path usually is: peers route around whoever left, and no one node’s loss stops the system. But if peer discovery runs through a central tracker or index, that tracker is a single point of failure in exactly the client server sense, and Napster is the standard example — the transfers were peer to peer and shutting down the index ended the network anyway.

Is BitTorrent pure peer to peer?

No, it is the classic hybrid. Peers find each other by making an ordinary HTTP request to a tracker, which is a client server exchange, and then move every byte of the payload directly between themselves. That split is deliberate: the central part carries metadata, which is tiny, and the decentralised part carries the file, which is not. Modern clients also support a DHT, which spreads the peer list across the peers themselves so a swarm can run with no tracker.

Email feels decentralised. Is it client server?

Hard

You are building peer to peer file sharing for people whose machines have never met. Specify what the directory must store for each peer, what happens when a peer joins and when it disappears without saying goodbye, and name two failure modes your design still has.

Follow-up

The directory is itself a client server component, so every row of the failure and administration discussion now applies to it. A design that does not say which of those risks it has accepted is not finished.

Show the hint

Write down what a joining peer already knows and what it must know before it can transfer anything. The gap between those two lists is exactly what the directory has to hold.