Client-server refers to a style of software communications between two computers, in which a requester (the client program) sends a message asking for some work to be done by a program on another computer (the server). In a client-server relationship, the client always initiates the action, to which the server responds. A web browser is a client that requests a response from a web server, the request and response being carried by the Hypertext Transfer Protocol (HTTP). Thus we can say that a web browser is an HTTP client, and the web server is an HTTP server.
Client-server interaction differs from peer-to-peer (P2P) communications in which any party can interact with any other party.
While the phrase client-server is most common in computer network protocols, it is quite applicable to single-computer software architecture.
Messaging application protocols include both client-server and peer-to-peer protocols. A peer-to-peer protocol, Simple Mail Transfer Protocol (SMTP) can initiate sending to, or receiving from, any other SMTP server. Client-server protocols get messages from a user's mailbox; Post Office Protocol removes, by default, the messages on the server after they have been transferred, while Internet Message Access Protocol (IMAP) provides access to the messages, but leaves them on the server. In some electronic mail implementations, the mail application may use SMTP to transfer outgoing messages to the mail server, but this usually follows a POP transfer, which requires user authentication, as with a password.
On a single computer, a user program can call another procedure, such as an operating system function, making the user program the client and the operating system the server. The Remote Procedure Call (RPC) protocol generalizes this model, so the procedure being called may be on a different computer.[1]
The X Windows System uses client/server in a non-obvious way, which is often confusing until one understands the services being request.[2] In an X Windows environment, the end user computer is considered to be the server, and the program reading from the keyboard or writing to the screen is the client.
This seems counterintuitive, because the human end user appears to start the interaction by typing a command. The X Windows client, however, is an application that is ready to accept input. It sends a request to the server to accept keyboard input. The user may not type anything for a long time, but, when that happens, the typed data forms the response.
While distributing applications to personal computers often is a wise choice, there are also can be good reasons to limit the kinds of software that can run on a PC. A thin client has no general-purpose local storage such as a hard disk, and is configured not to be able to run applications other than minimal terminal services such as X Windows or Microsoft Desktop connection (formerly Microsoft Terminal Services [3]. These are both full graphic user interface; the thinnest of clients might run a minimal LINUX distribution with a windowing or line-oriented terminal emulator.
Reasons to run thin clients include:
A hybrid client does local applications programming, but has no local mass storage. In contrast, a fat client still expects to interact significantly with a server, but does have some local storage. Backup of the thick client's files has to be solved on a case-by case basis.