Application Architectures
A network application is a program that runs on end hosts and talks to a peer program over the network. The network core (routers, links) moves bits; it runs no application code. All the interesting logic - a browser, a web server, a chat client - lives at the edge, on the hosts. So designing a network application is mostly about deciding how those edge programs are arranged and how they find each other.
Client-server vs peer-to-peer
Two structures dominate.
In client-server, one always-on host (the server) waits for requests; many clients initiate connections to it and never talk to each other. The server has a stable, well-known address. The web, email, and DNS are all client-server.
In peer-to-peer (P2P), there is no always-on server. Hosts (peers) talk directly to one another, and each peer is both a client and a server. Peers come and go, so the system must tolerate churn. BitTorrent is the classic example.
| Aspect | Client-server | Peer-to-peer |
|---|---|---|
| Always-on host | Yes - the server | No - any peer may leave |
| Who initiates | Clients contact the server | Peers contact each other |
| Addressing | Server has a stable address | Peers discover each other |
| Scaling cost | Grows with the server | Peers bring their own capacity |
| Examples | Web, email, DNS | BitTorrent, some overlays |
Many real systems are hybrids: a central server helps peers find each other, then the bulk transfer happens peer-to-peer.
Worked example: why scaling cost differs
Say a video needs to reach 10,000 viewers at 500 Kbps each.
- Client-server: the server's uplink must sustain 10,000 x 500 Kbps = 5,000,000 Kbps = 5 Gbps, all from that one host (or a cluster paid for by the operator). Double the audience, double the required server capacity.
- Peer-to-peer: if each peer, once it has downloaded a piece, also uploads at even 250 Kbps to other peers, the swarm supplies 10,000 x 250 Kbps = 2.5 Gbps of the total demand itself. The bigger the swarm gets, the more upload capacity it brings with it - unlike client-server, where more clients only ever add load.
This is the concrete reason BitTorrent-style distribution scales cheaply for the distributor: capacity grows with demand instead of against it.
A frequent interview error is describing peer-to-peer as having no central component at all. In practice, most real P2P systems still depend on a server for something client-server does trivially: BitTorrent peers still rely on a tracker (or a serverless DHT bootstrapped from known nodes) to find each other before any peer-to-peer transfer starts; early Skype used dedicated supernodes to route calls around NAT and firewalls. Saying "P2P has no server" in an interview is technically wrong and signals a shallow understanding - the accurate claim is that P2P avoids a server in the bulk data path, not that servers are entirely absent from the system.
The socket: the app / transport boundary
An application does not touch the network directly. It talks to a socket - the door between the application layer and the transport layer. The app writes bytes into the socket and reads bytes out; the transport layer (TCP or UDP) carries them to the socket on the other host. Everything above the socket is your application's business; everything below it is the operating system's.
Addressing an application
To reach a specific application on a specific host, two things are needed:
- The IP address identifies the host.
- The port number identifies the application on that host.
A web server listens on port 80 (HTTP) or 443 (HTTPS); a request to
93.184.216.34:443 reaches the HTTPS server on that host. The pair
(IP address, port) is what a socket is bound to, which is why it is the unit
of application addressing.
A socket is just an API: the application says "give me the bytes that arrive on this port" and "send these bytes to that host and port." It hides retransmission, ordering, and routing. This clean boundary is why the same browser code works over any link - Wi-Fi, fiber, cellular - without change.