MeatballWiki |
RecentChanges |
Random Page |
Indices |
Categories
In the 1980s and 1990s
client-server computing became the dominant paradigm of DistributedSystem
?s. In the new millenium, despite the advance in MindShare
? of
PeerToPeer networking,
ClientServer technologies continue to do most of the heavy lifting.
Contrast with DumbTerminal?s, ThinClients, and PeerToPeer networking.
Basic concept
In a client-server architecture, one program or computer acts as a server. It provides services to other programs or computers, called clients. Usually the client program is on a computer connected over a network to the computer the server program is on.
The typical justification for a client-server architecture is to keep certain data or information centralized at the server, while distributing the task of UserInterface to the various clients. Additionally, servers usually do some hard work -- complex processing or storage of lots of data -- requiring expensive hardware. In a client-server model, the clients can be relatively cheap, with just one server that has to be relatively expensive.
Client-server in practice
There is an implied inequality between the client computer or program and the server computer or program. Usually, one server provides services to many clients, and as mentioned above, is usually a more powerful and more expensive computer.
Servers also make for a SinglePointOfFailure?, in that if the server fails for some reason, the clients can't obtain the services they need.
Socially, servers are usually the province of a TechnicalElite? -- either within an organization or between organizations -- and clients are left to the devices of the UnwashedMasses?. Because of the server's importance, it's usually protected from unfit hands behind locked doors.
Depending on the resources of the organization or community, a single computer may provide multiple kinds of services, with different server programs, or there may be multiple computers each dedicated to a single service.
Examples
- Database servers. Most SQL database systems work in a client-server model. Client programs submit SQL queries to the database server to change or retrieve data, and the database server returns results. The server handles most of the difficult work of coordinating requests from multiple clients at the same time.
- File servers. Many client-server purists don't consider file servers to be true client-server -- probably because file servers were widespread at the time client-server was taking off, so they wanted to differentiate. But at the base level, file servers exhibit client-server behavior. A single server provides a virtual filesystem to clients, which can copy files to and from that file system. Examples would be Windows file-sharing, Novell Netware file-sharing, FTP, NFS, Gopher, and in some cases HTTP.
- Terminal servers. Again, this is an example that makes client-server advocates bristle, because terminal services were a key part of the previous minicomputer- or mainframe-to-dumb-terminal paradigm widely used in big organizations. With terminal services, the client simply sends uninterpreted user input codes -- representing keystrokes or, for graphical user interfaces, movement of the mouse or another pointing device -- to the server. The server sends user-interface cues -- characters, graphics, sounds -- back to the client, which shows them to the user. Examples range from telnet to XWindows and Microsoft Terminal Server.
- Web servers. Web servers mix up the idea of file services and terminal services in interesting ways. In the basic form, a client program -- usually a WebBrowser -- requests an object identified by a UniformResourceIdentifier from a server. The server returns the object. In many cases, the object is just a static file located on the server -- so the Web server is just providing file services. But in other cases, the object is generated dynamically by programs or functions on the server, and in fact the "object" requested may be an action (such as updating a database or file). In this way, the Web server acts like a terminal server, providing a simple user interface -- usually through HTML -- to functionality performed on the server.
Random notes
- The XWindows system is idiosyncratic in that its traditional terminology reverses the meaning of "client" and "server". An XWindows server sends user input codes, and an XWindows client interprets and acts on them, sending back user interface cues. In XWindows parlance, the XWindows server is providing user-interface services to the XWindows client. It's an interesting inversion, and highlights some interesting preconceptions of the Unix community where XWindows originated.