Client/Server Model

split the user interaction and the engine into two processes

• each process can run on a machine suited to its needs
• server characteristics?
• client characteristics?
• machines can be on a network: geographical independence
• failures are isolated to process boundaries
• problem is made more tractable by breaking it into smaller pieces

How do you ensure that the client and server processes start talking to each other at the same (or nearly the same) time?

Answer: you don't

The client interacts with the user.  The client makes requests from the server.  The server is quiescent until the client makes a request. The server is assumed to be always available. After handling a client request it waits for the next request. This takes care of the rendezvous problem.

request/reply - controls the conversation between the clien and server

The terms client and server most generically refer to software processes.

Machines with operating systems where server processes execute are often called "servers", but it's the process that is the real server.

Machines with operating systems where client processes execute are often called "clients", but it's the process that is the real client.

Servers maintain, or can find, data stored permanently (database) used to answer client requests.

Servers need to worry about authenticating clients.

Servers should be robust and reliable.

Servers tend to be complex for these reasons.

Cients interact with users.

Clients need nice interfaces.

Clients assume servers are available and operating correctly, making their development simpler.

The client/server model is a good example of lazy evaluation. No work is done until the client needs data and makes a request of the server. The work is demand driven.

An alternative model which also solves the rendevous problem is to pre-compute responses and store them, anticipating the needs of clients. Since this model isn't demand driven it has the potential to waste resources. But it has the advantage of possibly working even when the network goes down, since the answer sought may already be found locally.

Scaling is a problem with this approach, though some applications use it (ruptime example from Comer).