Clients and Servers: Roles in a Network Conversation

The words client and server are sometimes treated as hardware categories: a laptop is a client and a rack-mounted computer is a server.

The more useful definition concerns roles.

A client initiates a request for a service. A server listens for requests and provides responses or actions.

One machine can perform both roles in different conversations.

A role, not a shape

A phone weather app is a client when it requests a forecast.

The weather service is a server for that request.

The weather server may then act as a client when it requests data from:

• Database
• Mapping service
• Payment API
• Another internal service

Roles are relative to one interaction.

A small laptop can run a development web server. A powerful cloud machine can act as a client to another service.

Listening and connecting

A server creates a socket, binds to an address and port, and listens.

A client learns the endpoint and connects or sends a datagram.

For TCP:

1. Client initiates a handshake.
2. Server accepts the connection.
3. Both exchange a byte stream.
4. An application protocol defines message meaning.

The server can accept many clients because each connection has a distinct endpoint tuple.

Requests and responses

Application protocols define conversation structure.

A request may include:

• Operation
• Resource identifier
• Headers or metadata
• Authentication
• Body

A response may include:

• Success or error status
• Metadata
• Returned data

HTTP uses this pattern, but client-server designs also appear in databases, email, file sharing, games, and remote administration.

A concrete weather example

When a weather app refreshes:

1. The app obtains the user's selected location.
2. It resolves the service's domain.
3. It establishes a secure connection.
4. It sends a request for forecast data.
5. The server authenticates or rate-limits the client.
6. It reads databases and upstream forecasts.
7. It returns structured data.
8. The app renders icons and temperatures.

The client owns the user interaction. The server centralizes data and shared business logic.

Thin and thick clients

A thin client delegates more work to the server.

Benefits:

• Centralized logic and updates
• Less local processing
• Consistent shared data

Costs:

• Greater network dependence
• Server load
• Offline limitations

A thick client performs more locally.

Benefits:

• Rich offline operation
• Lower latency for local tasks
• Reduced server computation

Costs:

• More client complexity
• Distributed updates
• Device compatibility

Most modern applications combine both.

Stateful and stateless servers

A stateless request contains enough information to process it independently.

A stateful server remembers context between requests, such as:

• Login session
• Shopping cart
• Game state
• Database transaction

Stateless service instances are easier to distribute because any instance can handle the next request.

State still exists somewhere, perhaps in a database, cache, or signed client token.

The architectural question is where state lives and how consistency is maintained.

Concurrent clients

Servers need to handle many clients.

They can use:

• Thread per connection
• Process workers
• Event loops
• Asynchronous I/O
• Thread pools

The right model depends on workload.

Network servers often spend much time waiting on databases or other services. Asynchronous designs can manage many waiting connections without one blocked thread per client.

CPU-heavy work may use worker pools or separate services.

APIs

An application programming interface defines how software requests capabilities.

A network API can specify:

• Endpoints
• Methods
• Request fields
• Response structures
• Errors
• Authentication
• Versioning

REST, GraphQL, gRPC, and WebSocket-based protocols are examples of API styles and technologies.

An API is a contract, not necessarily a server. Local libraries also expose APIs.

Scaling servers

When one server instance cannot handle demand, systems can scale:

• Vertically: more resources on one machine
• Horizontally: more instances

A load balancer distributes requests.

Horizontal scaling introduces:

• Shared state
• Cache consistency
• Deployment coordination
• Failure handling
• Observability

Stateless frontends and external durable stores are common patterns, but not universal solutions.

Proxies

A forward proxy acts on behalf of clients.

A reverse proxy acts in front of servers.

Reverse proxies can:

• Terminate TLS
• Route requests
• Cache responses
• Balance load
• Apply authentication
• Hide internal topology

The client may believe it contacted one server while the proxy coordinates many backends.

Failures and timeouts

Network calls can fail through:

• DNS failure
• Connection refusal
• Timeout
• Server crash
• Overload
• Invalid response
• Partial network partition

Clients should set timeouts rather than wait forever.

Retries must be designed carefully. Repeating a read is often safe; repeating a payment request can charge twice unless the API supports idempotency.

Servers should return useful errors without exposing secrets.

Peer-to-peer

Client-server is not the only model.

In peer-to-peer systems, participants can request and provide resources to one another.

Examples include distributed file sharing and some communication applications.

Peer-to-peer still uses protocols, addressing, discovery, security, and sometimes central coordination.

Network address translation and firewalls make direct inbound peer connections more difficult, leading to relay servers or traversal techniques.

Common misunderstandings

"A server is always one physical computer"

A service may run across containers, virtual machines, load balancers, and regions.

"The client is always the user's device"

A backend service can be a client of another server.

"Stateless means no data is stored"

It means an instance does not depend on private conversational state between requests. Durable state can exist elsewhere.

"Retrying every failure is safe"

Retries can duplicate non-idempotent operations and amplify overload.

Knowledge check

1. What defines the client in a conversation?

It initiates a request for a service.

2. Can one machine be client and server?

Yes. Roles depend on each interaction, and a machine can perform both simultaneously.

3. Why are stateless service instances easier to scale?

Any instance can handle a request without needing private session context from a particular previous instance.

4. Why are retries dangerous for payments?

Repeating a non-idempotent request can perform the action twice unless the API detects duplicates.

The one idea to remember

Client and server describe who initiates and who provides a service, not fixed categories of hardware.

Real applications combine requests, state, APIs, concurrency, proxies, scaling, and failure handling behind those two simple roles.

Next, we will inspect the HTTP request and response messages most web clients and servers exchange.