Client-server: Difference between revisions
imported>Pat Palmer (moving the first sentence down (it is an aside, not an intro)) |
imported>Pat Palmer (working on the intro) |
||
Line 2: | Line 2: | ||
{{TOC|right}} | {{TOC|right}} | ||
Client/server | '''Client/server''' refers to a style of interaction between a requester (the ''client'') and the provider of the resource (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]] [[protocol (computer)|protocols]], it is quite applicable to single-computer software architecture. While "client-server" is an acceptable notation, "client/server" is more common, but not used here due to technical restrictions on Citizendium titles. | While the phrase '''client/server''' is most common in [[computer network]] [[protocol (computer)|protocols]], it is quite applicable to single-computer software architecture. While "client-server" is an acceptable notation, "client/server" is more common, but not used here due to technical restrictions on Citizendium titles. |
Revision as of 22:14, 7 June 2011
Client/server refers to a style of interaction between a requester (the client) and the provider of the resource (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. While "client-server" is an acceptable notation, "client/server" is more common, but not used here due to technical restrictions on Citizendium titles.
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.
Single-computer equivalents, and generalizing them to networks
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]
Unusual usages
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.
Thin, hybrid and thick clients
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:
- Security: The application, or its files, may be sensitive, and the enterprise does not want the code or data available on desktops.
- Protecting investment: An old PC that cannot run a modern operating system or needed applications, still may be able to run a minimum LINUX and a windowing system
- Cost control: there may be very little processing needed on the user workstation, and, in a new application, it may be possible to use less expensive hardware on each desktop. Many single-purpose workstations at hotel registration desks, for example, are thin clients.
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.
References
- ↑ Srinivasan, R. (August 1995), RPC: Remote Procedure Call Protocol Specification Version 2., RFC 1831
- ↑ X.open project
- ↑ Remote Desktop Connection (Terminal Services Client 6.0) for Windows XP (KB925876), Microsoft Corporation