Client/Server Technology

More computing power can be brought to bear on a problem in three ways. The first way is to build a computer that has a very fast processor. This was the goal of many of the early supercomputer efforts. The second way is to build a computer that has multiple processors working on different parts of some problem using shared memory, storage, and input/output (I/O) . These "parallel computing" systems were the goal of many of the later supercomputer efforts.

The third way to increase computing power dedicated to solving a problem is to use networks to link many separate computers working on different parts of the same problem. Each of the computers has its own processor, memory, storage, and I/O channels. They use a particular I/O channel—a network connection—to communicate and coordinate with each other.

Collectively, these systems are classified as distributed computing systems. The distinction between parallel and distributed computing is somewhat gray. Generally, a parallel computing system connects the cooperating components within a single system, or "box." Distributed computing connects boxes over a network. However, as networks increase in speed, the communications between components comes close to the speed of communication over a slow internal bus . As networks become ubiquitous and reliable, the term "network computing" is frequently used synonymously with distributed computing.

A distributed computing system may be thought of as a loosely coupled parallel system. Although this is true, parallel systems are generally devoted to working on problems where many similar calculations are carried out in parallel by the various components. In distributed computing systems, it is more frequently the case that the various components are optimized for different kinds of functions, which are carried out through a sequential dialog. The dialog generally consists of a series of requests and responses. The dominant paradigm for this kind of distributed computing system is the client/ server model.

In the simplest model for a client/server system, one of the components, a server process, is started on a given computer and runs in an endless loop waiting for a connection from a client . The client process is started on another computer, and it makes a request, which is sent across the network and processed by the server. A response is formulated. The response is then sent back to the client. The client may then disconnect from the server or make another request. At some point, the client terminates its connection to the server and the server returns to a "wait state" listening for a connection from another client.

Network and application protocols are essential for client/server systems to work. A networking protocol, like a diplomatic protocol, simply defines the conventions that will be used in an interaction. Three classes of protocols are required. The first is an addressing protocol that allows one component to specify the other component with which it wishes to communicate. Although there are numerous addressing protocols, the dominance of the Internet has, for all practical purposes, made the Internet Protocol (IP) the de facto addressing protocol.

The second class of protocols applies to protecting the quality of networked communication. Since a message from one computer to another must be transmitted as a series of packets, there must be some agreement on what to do if a packet that is part of a message is lost or is corrupted. This protocol must also address how to put the packets back together at the destination should they arrive out of order.

This protocol also addresses issues of synchronization between the two sides—e.g. how many packets should be sent before waiting to see if they have arrived safely, and how long should the sender keep a record of sent packets in the event that one needs to be resent. There are many different ways that this exchange might be managed, but again, the dominance of the Internet has made the Transmission Control Protocol (TCP) the dominant protocol for controlling communications quality.

Finally, the client and the server must have a protocol which governs the nature of the dialog in which they will engage. This third type of protocol defines the nature of the relationship between the client and the server. The names of some of these protocols are well known even if the underlying nature of the dialog they define is not. The relationship between World Wide Web browsers and web servers is defined by the HyperText Transfer Protocol or HTTP. The process by which files are transferred is defined by the File Transfer Protocol or FTP. The exchange of mail is defined by the Simple Mail Transfer Protocol or SMTP. These protocols are defined as "standards."

Client/Server Paradigms

The preceding section described a simple model for a client server interaction, where a server accepts a connection from a single client, handles the exchange, and then closes the connection to wait for a new one. This is called an iterative client server model. It is also possible for the server to be constructed to handle multiple requests simultaneously. This model is called a concurrent client server model.

The astute reader will recognize that if the server program is running on a machine with a single processor, it is not really possible to handle requests concurrently. The use of the term concurrent here refers to the overall handling of connections between the clients and the server. In a concurrent model, the server creates copies of the main process. Each copy is dedicated to handling the request from a single client, with the original process returning immediately to listen for additional connections. Depending on the nature of the interaction between the client and the server, this design may be more or less efficient than the iterative design.

For example, if the connection between the client and the server consists of a single request and response, and if the processing of the request by the server is very efficient and quick, the overhead of creating a copy of the server process and then of shutting it down will make the handling of requests less efficient. However, if the exchange between the client and the server involves multiple requests and responses and if the client is operating in conjunction with human input, the server will spend a lot of time waiting for the client to make a request and very little of its time actually handling the request. In this case, the multitasking capability of the operating system can be used to shift back and forth between the various server processes, handling the requests from the various clients in a timely fashion. Thus, from the point of view of the clients, the server is handling the various requests concurrently.

Other client/server model variations involve the preallocation of server processes such that there are multiple copies of the server listening for a request at the same address. Each request is processed iteratively by one of the servers, but multiple processes can be running in parallel handling these requests. This is the model most frequently employed by web servers.

It is also possible to design a server that will open multiple connections to a number of different clients. The one server then checks and handles communications from all of these clients in some "round-robin" fashion. This model is frequently used for applications like chat rooms, where the information presented by one client is then broadcast to all the clients.

Client/server systems may be chained or linked with a server to one client being a client to another server. Additionally, a client may simultaneously connect to multiple servers for different services. As an example of the first model, consider a client that makes a connection to a server to process a purchase order. The server may understand all the rules about who may make orders, and how an order is to be processed, but the actual recording of the order may be handled by another process that would place the order into a database.

This is the model for most three-tier client server systems. The client handles the user interface which processes requests to a middleware server. This intermediate server applies rules and checks on the data. When satisfied, the middleware server makes a connection as a client to another server, which controls a database. The database server is only responsible for storing the data, assuming that the middleware server has done the necessary checking.

More Sophisticated Models for Clients and Servers

Over the years, it has become clear that the process of defining protocols for clients and servers is a difficult task, and not fully consistent with modern programming techniques. In addition, the process of locating the address at which a server is listening for clients has become more complicated as the number of client/server applications has grown.

These and other problems associated with client/server design and implementation have been addressed by new layers of protocols. The most well known of these is the Remote Procedure Call (RPC) protocol, which was developed to insure protocol consistency between pairs by automating much of the basic structural code, and by establishing a mechanism for registration and finding of server processes through a shared directory service. While RPC worked for procedural languages, a model was also needed for object-oriented programming languages. Remote Method Invocation (RMI) fills this need in a similar fashion.

Beyond these efforts, more recent developments include mechanisms for standardizing more of the basic functionality of the interaction, allowing for servers to be located across multiple machines, and for managing the various services that are running. These models, generally classified as distributed application servers, include the Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), JavaSpaces and JINI, and E'Speak to name a few.

Design Issues

Client/server systems endeavor to optimize per-problem performance, multiple-problem throughput, and reliability, among other things. New problems arise for the programmer, however, because techniques used for writing stand-alone serial programs often fail when they are applied to distributed programs.

In building a system, the programmer must address a variety of issues such as data partitioning , task partitioning , task scheduling, parallel debugging , and synchronization . In addition, the programmer has to understand that interconnection bandwidth and message latency dominate the performance of distributed and parallel systems. There is no clear-cut way to predict what the performance of a new system will be. Therefore, it is difficult to predict what the benefits of a distributed or parallel system will be prior to an investment of time and effort. Finally, the design of the server in a client/server system requires particular attention to a number of issues, including process synchronization, global state, reliability, distributed resource management, deadlock, and performance evaluation.

see also Assembly Language and Architecture; Information Technology Standards; Networks; Operating Systems.

Michael B. Spring

Bibliography

Ananda, Akkihebbal L., and B. Srinivasan. Distributed Computing Systems: Concepts and Structures. Piscataway, NJ: IEEE Computer Society Press, 1991.

Beeri, Catriel, Philip A. Bernstein, Nathan Goodman. "A Model for Concurrency in Nested Transactions Systems." The Journal of the ACM 36, no. 2 (April 1989): 230–269.

Ben-Ari, M. Principles of Concurrent and Distributed Programming. New York: Prentice Hall, 1990.

Black, Uyless. TCP/IP and Related Protocols, 3rd ed. New York: McGraw-Hill, 1998. Brewer, Eric, et al. "A Network Architecture for Heterogeneous Mobile Computing." IEEE Personal Communications, October 1998.

Comer, Douglas, and David Stevens. Internetworking with TCP/IP, vols. 1 and 2. Upper Saddle River, NJ: Prentice Hall, 1994.

——. Internetworking with TCP/IP, vol. 3. Upper Saddle River, NJ: Prentice Hall, 1996.

Mullender, Sape, ed. Distributed Systems, 2nd ed. Reading, MA: Addison-Wesley, 1993.

Orfali, Robert, and Dan Harkey. Client/Server Programming with Java and CORBA, 2nd ed. New York: John Wiley and Sons Inc., 1998.