Commonly written
client/server. The concept behind this
system design architecture, is that the task at hand can be divided into a
client part and a
server part.
The client part sends requests to the server part: the server part tries to satisfy them.
Usually the client handles the user interface, that's to say, the typical user of the system uses the client, while the server handles the data storage and computation.
Examples:
- airline reservation systems (like SABRE). You have a million terminals that operators use to reserve and buy seats on planes. The actual reservation and ticketing data is stored on a big computer somewhere, called the server.
- The WWW. A client program (normally called a browser) sends requests to a server: the requests are coded in HTTP, and the server sends back text and images.
- Checkout systems in supermarkets: each cashier mans a client, and a central inventory and accounting system receives the transaction information and updates the inventory and the books.
- A MOO: the central server maintains reality consistent, while the clients modify bits of the world and interact with it.
A client server system is well suited to situations where you want to
centralize data (either because it is very expensive or because it has to be consistent) or where you have a very expensive
resource that has to be shared (like a very
big iron).
Client server systems are inherently
asymmetric, that's to say that there is a different load on the server than on the client (that is why usually a server is a big system).
There can be also asymmetries in communications traffic. For example, Web network traffic is highly asymmetrical, because for every tiny (1 Kilobyte) client request there is a usually larger server answer.
Opposed to peer to peer, where the participating entities are on the same level (a good example of this is Windows 98 file sharing)