Peer-to-Peer vs Client-Server

Peer-to-Peer vs Client-Server

What you'll learn

• Contrast peer-to-peer and client-server as models of administration, not wiring
• Walk a growing office to the exact point where peer-to-peer breaks down — and explain why it must
• Recognize client and server as roles a computer plays, not kinds of boxes
• Trace the same trade-off into 2026: cloud identity and SaaS as the successors of the office server

This lesson completes our journey through Chapter 1 of Network Essentials. Having drawn networks and named their shapes, the chapter turns to a question that no diagram shows: when two computers share a folder or a printer, who decides who gets access? The answer splits all networks into two administrative families — and the book teaches the split through a story about a law firm that we will retell, because it is one of the best teaching devices in the whole textbook.

Two models of being in charge

Network administration means controlling access to resources: files, folders, printers, services. Every network answers the who-decides question in one of two ways.

In a peer-to-peer network, every computer administers its own resources. Each machine's owner decides who may open its folders and use its printer; there is no higher authority. Control is decentralized.

In a client-server network, one central authority — a server run by an administrator — manages access to resources on behalf of everyone. Control is centralized.

The book makes a subtle point here that many beginners miss: a peer-to-peer network can still contain machines that provide services, and a client-server network obviously contains clients. The dividing line is not whether servers exist — it is who holds administrative control. Keep that in mind; it is the difference between describing what a network has and understanding how it is governed.

Peer-to-peer: everyone their own administrator

Peer-to-peer is how small networks begin, for good reasons. It costs almost nothing: no dedicated server hardware, no specialist to hire. Setup is quick — sharing a folder or a printer takes minutes. For a handful of trusting people, it simply works.

The disadvantages are the mirror image. Security is weak, because it depends on every user separately doing the right thing on their own machine. There is no central backup: each computer's files live and die with that computer. And it does not scale. The traditional rule of thumb — stated in the book and repeated across a generation of teaching — is that peer-to-peer tops out at around ten computers. Treat the number as a teaching artifact rather than a law of physics; the reason behind it is what matters, and the reason is arithmetic. If every person needs an account on every colleague's machine that holds something they need, the number of account-and-permission relationships grows roughly with the square of the headcount. Ten people can mean dozens of relationships; fifty people can mean thousands. No goodwill survives that curve — as the following story shows.

The law firm that outgrew itself

Here is the book's scenario, retold in our own words.

Dana coordinates benefits at an eight-person law firm. So that colleagues can reach the insurance forms and leave requests themselves, she creates a login account on her own computer for each of the other seven people and grants them access to her shared "Benefits" folder. It works. Her colleagues do the same in their corners: lawyers share case folders from their own machines, everyone can reach the printer. Eight people, little turnover, plenty of goodwill — the peer-to-peer model at its best.

Five years pass. The firm now employs fifty people, and the same arrangement is quietly falling apart:

• Every new hire needs accounts created — by hand, by busy colleagues — on every machine holding something the newcomer needs; onboarding takes days and favors.
• Nobody can produce a single list of who has access to what. The knowledge is scattered across fifty machines' settings.
• Some of those folders hold genuinely sensitive material — client files, salary data — and confidentiality now rests on fifty people's individual sharing settings.
• Many employees never understood the sharing mechanics in the first place, so training new staff eats more and more time.

Notice that the firm did nothing wrong. Nothing broke. The model itself has a ceiling, and the firm grew through it. Every symptom on the list is the same arithmetic wearing a different costume: too many relationships for decentralized control to track.

Client-server: centralized administration

The cure is to move control to the center. The firm installs a domain server — a server whose job is to hold the user accounts and decide access for the whole network — under a trained administrator's care.

Watch what the story's problems do next. The administrator creates one group called Employees on the server. Dana hands control of her Benefits folder to the server, and the group is granted access to it — and, with one more stroke, to the print server too. A new hire now means one account, added to one group, and the newcomer automatically has everything the role requires: benefits folder, printing, the lot. The scattered fifty-machine account sprawl collapses into a single authoritative list — which is also, at last, an answer to "who can access what?" that can be printed on one page.

The model's advantages generalize: real security (one place to enforce rules, one place to revoke a departing employee), scalability to hundreds or thousands of clients, central management and central backup. Its disadvantages are equally real and the book is honest about them: higher cost, in equipment and especially in people — someone with specialized training must run the server — and a concentration of risk, because the server becomes a single point of failure. Centralization means the network is now worth protecting properly: redundancy and backups stop being luxuries. That trade — money and expertise in exchange for control and scale — is the entire decision, and the case study below asks you to make it yourself.

Clients and servers are roles, not boxes

The vocabulary, precisely: a server is whatever provides a service, and a client is whatever requests one. The chapter's catalog of examples: a file server hosts files for an organization; a print server manages printing; a domain controller provides authentication — it checks who you are and what you may do; even a router can be seen this way, providing connection services to everyone on the LAN.

The crucial insight is that these are roles, not categories of hardware. The same machine can play both, even at the same instant. The book's example: a file server that needs to print a document becomes, for that exchange, the print server's client. Serving files did not change; for the duration of the print job, it is also being served.

A retold version of the book's everyday analogy makes the role-switching natural. A freelance designer creates a menu for a neighborhood café: the café is her client. Every morning she buys her coffee at the same café: now she is the café's customer. Nobody is confused, because client obviously describes the relationship in each exchange, not the identity of either party. Computers work exactly the same way.

One more clarification from the chapter, because beginners draw this wrong constantly: sketching a client-server network, students often place the server in the middle with all clients wired directly to it, as if the server were the switch. Physically that is wrong — clients and server all connect to a switch, in the star you drew in Lesson 3. Logically, though, the drawing tells the truth: services flow from the server to every client, so as a map of relationships (not cables) it is fair. Knowing which kind of map you are drawing — physical or logical — is a skill this course will keep sharpening, all the way to the documentation lessons in Module 8.

From the textbook to 2026: the workgroup's successor is the cloud

Original (the book's story). Growth forces centralization, and centralization meant buying a machine: the firm acquires a domain server, installs it down the hall, and hires or trains an administrator. In 2007, "centralized administration" physically lived in your office.

What changed. Small organizations stopped buying that machine. The two halves of the office server moved out separately. Identity — the accounts, groups and permissions — moved to cloud identity providers (Microsoft Entra ID, Google Workspace, Okta and their kind: the domain controller's job, offered as a subscription). Services — files, mail, chat, printing queues — moved to SaaS (Software as a Service: applications consumed over the Internet instead of run on your own server). The administration is exactly as centralized as the book teaches — more so — but the server room is now rented space in a provider's data center, reached across the WAN links of Lesson 2. Meanwhile, note what did not die: peer-to-peer as an architecture thrives where decentralization is the point — file distribution like BitTorrent, some direct paths in video calling, blockchain systems. What ended is peer-to-peer as a way to run an organization.

2026 practice. A firm founded today does not re-live Dana's story and then buy a server at employee fifty. It starts centralized on day one — cloud identity plus SaaS — because the subscription model deleted the up-front cost that once made peer-to-peer the cheap option. The decision has shifted from when do we centralize? to which provider do we centralize on? — but you justify it with precisely the reasoning this lesson taught: count the relationships you would otherwise have to manage by hand. The book's ten-peer ceiling is a historical artifact; the arithmetic behind it is timeless.

Case study: The growing law firm — when do you centralize?

This is a case study — analysis and a written deliverable, not a tool exercise.

Objective. Apply both administration models to a growing firm, identify the point where peer-to-peer stops being defensible, and argue the transition the way you would to the people paying for it.

Setup. Paper or a blank document. The four snapshots below. No software needed.

The scenario. Follow one firm through four moments:

• Year 0 — 4 people. Everyone shares files from a folder on Dana's PC; one network printer; everyone knows everyone.
• Year 2 — 9 people. Two new hires waited three days for colleagues to create their accounts on the right machines; one of them was accidentally given access to the salary folder.
• Year 4 — 18 people. Nobody can say exactly who has access to the Hendricks case folder; a departed employee's accounts were later found still active on three machines.
• Year 6 — 45 people. A second office opens across town; a partner now loses most of a day each week to access requests; the firm's insurer sends a security questionnaire asking for an access-control list that does not exist.

Steps.

1. For each snapshot, list the administration tasks being performed and who is performing them.
2. Quantify the sprawl: assume each person maintains one shared resource that all colleagues need. The relationship count is then n × (n−1) — compute it for 4, 9, 18 and 45 people, and put the four numbers side by side.
3. Classify each snapshot's symptoms as inconvenience (slow, annoying) or risk (confidentiality, unrevoked access, no accountability).
4. Choose your centralization point — the first snapshot where you would refuse to continue peer-to-peer — and decide what to centralize first: identity (the accounts), files, or backup.
5. Write a one-page recommendation to the partners: the current exposure, your proposal, what changes for staff day-to-day, one honest cost, and one new risk that centralization itself introduces. Close by choosing between the book-era form (a server in the office) and the 2026 form (cloud identity plus SaaS), with one sentence of justification.

Expected result (deliverable). The relationship table (12, 72, 306, 1,980) plus a one-page memo that argues from numbers and risk — not from technology preferences.

Verify (self-check). Your memo should: (a) use the relationship arithmetic, not just adjectives, (b) cite at least one risk-class symptom as the trigger, (c) centralize identity first, and (d) name a genuine downside of your own proposal (cost, dependence on an administrator or provider, single point of failure).

Questions.

1. Why does centralizing identity first unlock more than centralizing files first?
2. Which quantity in the story grows quadratically with headcount, and which symptoms are that curve in disguise?
3. At Year 4, is the departed employee's live access an inconvenience or a risk? What single client-server feature would have prevented it?
4. Would your recommendation change for a firm certain it would never exceed six people? What does that say about where the peer-to-peer model is still legitimate?

If it stalls.

• You cannot pick a moment. Find the first irreversible exposure. Convenience problems can be endured; unrevoked access to client files cannot. Most strong answers centralize at Year 2 or Year 4 — arguing either well beats picking "correctly."
• Your memo goes technical. Partners buy risk reduction and time savings, not directory services. Rewrite every technical claim as money, time or risk.
• You want to answer "just buy a shared drive." A shared drive centralizes storage but not identity: who may log in and reach it remains scattered across machines. Trace the scenario's symptoms — most survive your fix. That is why step 4 exists.

Check yourself

1. Three roommates share a printer connected to one laptop and pass files over the apartment Wi-Fi. Which administration model is this, and is it the right choice here?
2. A 12-person dental practice keeps all patient records in folders shared from the receptionist's PC, with accounts she creates herself for each colleague. Using this lesson's terms, name two distinct problems — and say which one should worry the dentist most.
3. In an office network, file server FS1 sends a document to print server PS1 to be printed. In that exchange, which machine is the client, and why?
4. A startup of eight runs everything on Google Workspace and has no server anywhere in its office. A visitor concludes: "no server in sight — this is peer-to-peer." Correct the visitor.
5. "We bought a powerful tower PC for the office, so now we have a client-server network." What is wrong with this claim, according to the dividing line this lesson drew?
6. A company's authentication server fails at 9 a.m. and nobody can log in. Which known disadvantage of client-server just materialized, and what does its existence oblige the administrator to invest in?

Answers

1. Peer-to-peer — each device's owner controls its own resources. It is the right choice: three trusting users, trivial needs, zero budget; this is exactly the population the model serves well.
2. Any two of: no central backup (records die with that PC); weak security/confidentiality (patient data guarded only by one machine's per-user settings); no single record of who has access; administration resting on an untrained person. The security of patient records should worry the dentist most — it is a legal and ethical risk, not an inconvenience.
3. FS1 is the client. Client and server are roles per exchange: the machine requesting the print service is the client in that exchange, even though it spends its life serving files.
4. The startup is strongly client-server — administration is centralized in the provider's identity service and applications. The servers exist; they are simply in the provider's data centers, reached over the Internet. Absence of a visible box proves nothing about the administration model.
5. Hardware does not define the model — administrative control does. A powerful PC whose resources are still managed machine-by-machine leaves the network peer-to-peer; conversely, modest hardware running centralized identity makes it client-server.
6. The single point of failure. Centralization concentrates risk in the server, which obliges the administrator to invest in protecting it: redundancy, monitoring and tested backups (Module 8 turns this into method).

Key terms

• Network administration — controlling access to a network's resources: files, printers, services.
• Peer-to-peer network — every computer administers its own resources; decentralized control.
• Client-server network — a central server administers resources for all; centralized control.
• Server — the role of providing a service (file server, print server, domain controller, and more).
• Client — the role of requesting a service.
• Domain server / domain controller — the server that holds accounts and provides authentication for a network.
• Authentication — verifying who a user is before granting access.
• Group — a named set of users granted permissions together (one change provisions many people).
• Single point of failure — a component whose failure takes down the whole system; the price of centralization.
• Cloud identity (modern) — the domain controller's job delivered as a subscription service (e.g. Microsoft Entra ID, Google Workspace, Okta).
• SaaS (Software as a Service) (modern) — applications consumed over the Internet instead of run on your own servers.

Summary

• The peer-to-peer/client-server split is about who holds administrative control — not about which boxes are present.
• Peer-to-peer is cheap, quick and legitimate for a handful of trusting users; its ceiling (the traditional "about ten") comes from relationship arithmetic that grows with the square of headcount.
• The law firm story shows the failure mode: account sprawl, no authoritative access list, exposed confidential files, rising training cost — symptoms, not mistakes.
• Client-server cures the sprawl with central accounts and groups: one new account, one group membership, everything provisioned — at the price of cost, expertise and a single point of failure to protect.
• Client and server are roles per exchange: a file server printing a document is, for that moment, a client.
• The "server in the middle" drawing is physically wrong (everything meets at a switch) but logically true — and knowing which map you are drawing matters.
• In 2026 the office server's two halves live in the cloud: identity providers and SaaS. Organizations now centralize from day one; the book's arithmetic is how you justify it.

Next lesson

Module 1 gave you the nouns of networking: networks, their types, their shapes, their governance. Module 2 begins with the verbs — how data actually moves — starting with the most famous map in networking: the seven layers of the OSI model.

Sources and further study

• Network Essentials, Dr. Tahseen Al-Doori — Chapter 1, "Introduction to Networking": the administration models, the law-firm scenario, the server catalog and the roles-not-boxes teaching this lesson retells.
• GeeksforGeeks — "Difference between Client-Server and Peer-to-Peer Network": a current side-by-side comparison table for quick revision.
• Kurose & Ross, Computer Networking: A Top-Down Approach — Chapter 1's application-architecture section, for how the same client-server/peer-to-peer split shapes Internet applications.