DC - Chapter - 5 : The Client-Server Paradigm

5.1 Background

In distributed computing, the client-server paradigm refers to a model for network applications where processes play one of two different roles: a server process, also called a server, is dedicated to managing access to some resources such as printers or files or a network service, while client processes, called clients, access the server to use these resources or network service to complete a task.

Figure 5.1 illustrates the concept of the client-server model. A server process runs on a network-connected computer called as the server host, to manage a network service provided by that host. A client host makes use of a client process to access a particular service.

Fig 5.1 The Client-Server Distributed Computing Paradigm

On the Internet, many services like HTTP, FTP, DNS, gopher, etc are client-server applications which are often known by the protocol that the application implements.

5.2 Client-Server Paradigm Issues

Some of the client-server paradigm issues are given below:

5.2.1 A Service Session

As shown in Figure 5.1, the service managed by a server may be accessed by multiple clients who want to use the service, sometimes concurrently. Each client, when serviced by the server, engages in a separate and independent session with the server, during which the client conducts a dialog with the server until the client has obtained the service it desires.

Figure 5.2 illustrates the execution flow of the server process. Once started, a network server process runs indefinitely, looping continuously to accept requests for sessions from clients. For each client, the server conducts a service session.

 Fig 5.2 The execution flow of a server process

5.2.2 The Protocol for a Service

A protocol is needed to specify the rules that must be observed by the client and the server during a session of the service. Such rules include specifications on matters such as (1) how the service is to be located, (2) the sequence of interprocess communications, and (3) the representation and interpretation of data exchanged.

Locating the Service

A mechanism must be available to enable a client process to locate a server for a given service. In the simplest scheme, the service location is static and can be identified using the address of the server process, in terms of the host name and protocol port number assigned to the server process. This is the scheme used for Internet services, where each Internet service is assigned to a specific port number. In particular, a well-known service such as FTP, HTTP, or telnet is assigned a default port number that is reserved on each Internet host for that service. For example, the FTP service is assigned two port numbers: TCP 20 and 21. HTTP is assigned to the TCP port 80.

At a higher level of abstraction, a service may be identified using a logical name registered with a directory or a registry. The logical name will need to be mapped to the physical location of the server process. If the mapping is performed at run time, then the service's location will be dynamic, which is said to be location transparent.

5.2.3 Interprocess Communications and Event Synchronization

In the client-server model, the interaction of the processes follows a request-response pattern (see Figure 5.3). During a service session, a client makes a request to the server, which replies with a response. The client may make a subsequent request, followed by a reply from the server. This pattern may repeat indefinitely until the session is concluded.

Fig 5.3 The request response pattern of IPC in the Client-Server model

For each request issued, a client must wait for the reply from the server before it can proceed further. For example, one of the simplest network services is the Daytime service, whereby a client process simply obtains a timestamp (the time of day on the server host) from the server process. Translated into plain English, the dialog during a service session of this protocol proceeds as follows:

Client: Hello, <client address> here. May I have a timestamp please?

Server: Here it is: (timestamp follows).

Likewise, the dialog in a World Wide Web session proceeds as follows:

Client: Hello, <client address> here.

Server: Okay. I am a Web server and speak protocol HTTP 1.0.

Client: Great, please get me the Web page index.html at the root of your document tree.

Server: Okay, here's what's in the page (contents follow).

The dialog in each session follows a pattern prescribed in the protocol specified for the service. Among other things, the specification defines (1) the sequence of interprocess communications between the client and the server, (2) the syntax and semantics of each request and response, and (3) the action expected of each side upon receiving a particular request or response.

Again, using the simple Daytime service as an example, the protocol specifies the following:

• There is no need for any syntax in the request from the client, as its contact with the server automatically implies a request for time.

•  The response is a timestamp as a character string formatted according to the specification of the protocol.

A sequence diagram is a good way to document the interprocess communications during a service session. Fig 5.4 shows the sequence diagram for a session of the Daytime service. The only message exchanged here is the timestamp.

Fig 5.4 Sequence Diagram for client server paradigm

5.2.4 Client-server protocol data representation

Part of the specification of a protocol is the syntax and semantics of each request and response. The choice of data representation depends on the nature and the needs of the protocol. Representing data using text (character strings) is common, as it facilitates data marshalling and allows the data to be readable by human. Most well known Internet protocols are client-server, request-response, and text-base.

5.3 Software Engineering for a Network Service

There are two sets of software which provides a network service: one for the client process, the other for the server process. The set of software needed on the client host to support a service or application, includes the client program and its run-time support, which is referred to as the client-side software, as opposed to the server-side software, which includes the server program and all the run-time support that it needs.

5.3.1 Software Architecture

The software architecture of an application built using the client-server model, or a client-server application, can be described as follows:

Presentation layer: On the server side, a user interface (UI) is needed to allow the server process to be started; typically, a command-line execution is sufficient. On the client side, a user interface needs to be provided by the client process. Using such an interface, a user on the client host may request the service and receive the response from the server.

Application logic layer: On the server side, the time of day needs to be obtained from the system and sent to the client host. On the client side, the request from the user will need to be forwarded to the server, and the response from the server will need to be displayed to the user.

Service layer: The services required to support the application are (1) on the client side, a readout of the server host's clock (for the timestamp); and (2) on both sides, an IPC mechanism.

The functionalities of the three layers must be present in the combined software. Some of the functionalities belong in the client, some in the server. For large-scale applications, it is advisable to design the software so that the functionalities of the three layers are encapsulated in separate software modules as shown in figure 5.5. 

Fig 5.5 Software Architecture of a Client-Server Application

5.4 Daytime Client-Server using Connectionless Datagram Socket

Client-Side Software

Presentation logic: The presentation layer provides the interface for a user of the client process. A class called DaytimeClientl.java encapsulates the client-side presentation logic. The code in this class is concerned solely with obtaining the server address as input from the user and displaying the output in the form of timestamp to the user.

To obtain the timestamp, a method call to a helper class, DaytimeClientHelperl.java, is issued. This method hides the details of the application logic and the underlying service logic. As a result, the programmer of DaytimeClientl.java need not be aware of which socket types are used for the IPC.

Application Logic: The DaytimeClientHelperl.java class encapsulates the client-side application logic. This module performs the IPC for sending a request and receiving a response using a subclass of the DatagramSocket, MyClientDatagramSocket. Note that the details of using datagram sockets are hidden from this module.

Service Logic: The MyClientDatagramSocket.java class provides the details of the service, in this case using the datagram socket API. There are at least two significant advantages to separating the three layers of logic into different software modules:

• Each module can be developed by people with special skills to focus on a module for which they have expertise. Software engineers who are skilled in user interface may concentrate on developing the modules for the presentation logic, while those specializing in application and service logic may focus on developing other modules.

• The separation allows modifications to be made to the logic at one layer without requiring changes to be made at the other layers. For example, the user interface can be changed from text mode to graphical mode without necessitating changes in the application logic or the service logic. Likewise, changes made in the application logic should be transparent to the presentation layer.

Server-Side Software

Presentation Logic: Typically, there is very little presentation logic on the server side. In this case, the only user input is for the server port, which, for simplicity, is handled using a command-line argument.

Application Logic: The DaytimeServerl.java class encapsulates the server-side application logic. This module executes in a forever loop, waiting for a request from a client and then conducting a service session for that client. The module performs the IPC for receiving a request and sending a response using a subclass of the DatagramSocket, MyServerDatagramSocket.

Service Logic: The MyServerDatagramSocket class provides the details of the IPC service, using the datagram socket API which is similar to the MyClientDatagram class, with the exception that the receive Message method returns an object of the DatagramMessage class which contains the sender's address in addition to the message itself. The sender's address is needed by the server in order for the server to send a request to the client. The methods employed to obtain the sender's address from a datagram received are getAddress and getHost, whose descriptions are shown in Table 5.1.

 

Table 5.1 Methods of DatagramPacket Class

5.5 Daytime Client-Server Using Stream-Mode Socket

In the previous section we have seen how the Daytime service can be implemented using the connectionless datagram socket for the IPC mechanism. Suppose we wish to implement the same service using the connection-oriented datagram socket instead. Since this change primarily affects the service logic only, we should need to make extensive modifications only to the Java classes at the service logic layer. The application logic, specifically the Helper class, will need to be adjusted accordingly.

Client-Side Software

Presentation logic: Here we use a Java class called DaytimeClient2 which is the same as DaytimeClient1 except for a change in the name of the "helper" class, DaytimeClientHelper2. The getTimestamp ( ) method in DaytimeClientHelper2 now uses the stream-mode socket API, but the details are transparent to DaytimeClient2.

Application logic: The DaytimeClientHelper2 class which encapsulates the client-side application logic is similar to the DaytimeClienHelper1 class, except that a stream-mode socket is used instead of a datagram socket.

Service logic: The MyStreamSocket class provides the details of the IPC service using the stream-mode socket API. The MyStreamSocket class is a wrapper class which contains an instance variable that is a reference to a Socket object and provides methods for sending a message to and receiving a message from a socket.

Server-Side Software

Presentation logic: The code for DaytimeServer2 is identical to that of DaytimeServer1. The only user input is for the server port, which, for simplicity, is handled using a command-line argument.

Application logic: The code for DaytimeServer2 uses the stream mode socket API to accept a connection. The Socket reference returned (for the data socket) is then used to instantiate a MyStreamSocket object, whose sendMessage method is employed to transmit a timestamp to the client at the other end of the connection.

Service logic: The same wrapper class used for the client, MyStreamSocket, is used in our server as well, as it contains the necessary methods for stream-mode IPC. Note that a different class or even mechanism for providing the service logic is possible if the server software were developed independently of the client software.

To reiterate, in switching to use the stream-mode socket API, the only modules that required significant modifications are those that provide the service logic on either side.

5.6 Testing a Network Service

Because of its inherent complexity, network software is notoriously difficult to test. Even a simple network service such as Daytime poses a challenge to novices. Following is some advice that you may find helpful:

•    Use the three-layered software architecture and modularize each layer on both the client and the server sides.

•    Use an incremental or stepwise approach in developing each module. Starting with stubs for each method, compile and test a module each time after you put in additional details.

•    Develop the client first. It is sometimes useful to employ an Echo server that is known to be correct and that uses a compatible IPC mechanism to test the client independently of the server. Doing so allows you to develop the client separately from the server.

•    Use diagnostic messages throughout the source code to report the progress of the program during run time.

•    Test the client-server suite on a single machine before running the programs on separate machines.

The Daytime client-server examples are useful as an introduction to the development of a network service. The simplicity of the protocol is such that each service session involves merely one round of message exchange between the two processes.

5.7 Connection-oriented and Connectionless servers

The Internet protocol Echo is the basis for a well-known Internet service. The Echo protocol simply allows a client to send one text line to the server at a time, receiving an echo of each line from the server. The protocol uses an Echo server on any Internet host, as a temporary server when a software engineer is developing a client for another protocol. There are two implementations of the service: one using a connectionless server and the other using a connection oriented server.

5.7.1 Connectionless Echo Client Server

The Echo Client

The presentation logic for the client is encapsulated in the EchoClient1 class, which provides the user interface for prompting for the server information and then, using a loop for the text lines to send to the Echo server. The sending of the text string and receiving of the echo in return is handled by a method, getEcho, of the EchoClientServer1 class. The EchoClientHelper1 class provides the application logic for the client.

An instance of this class is created by each client process, which holds the address of the server host as well as a reference to the socket used by the client for IPC. The getEcho method uses the socket to send a line to and then receive a line from the server. Finally, the close method closes the socket.

The Echo Server

EchoServerl.java combines the presentation logic and application logic for the server. In each iteration of the forever loop, the server reads a line from the socket and then writes the line back to the socket, addressing the reply to the sender. Since there is no connection involved, it is possible for the server to interact with different clients in successive iterations, resulting in interleaved concurrent service sessions. Figure 5.6 illustrates a scenario wherein two concurrent clients of this implementation, A and B, interleave their interactions with an instance of EchoServer1.

Fig 5.6 A sequence diagram illustrating two interleaved sessions with EchoServer1

5.7.2 Connection Oriented Echo Client Server

The implementation of the presentation logic (in EchoClient2 and EchoServer2) is unchanged from EchoClient1 and EchoServer1 in the previous example, but the application logic in EchoClientHelp2 and EchoServer2) as well as the service logic (in MyStreamSocket) are different (since stream-mode socket is used instead of datagram socket).

Note that in EchoClientHelper2 the connection to the server is performed in the constructor, while each round of message exchange is provided via the getEcho method. A method, done, is used to transmit the end-of-session message (containing a single period) to the server before the client-side socket is closed.

In EchoServer2, a connection socket is first created to accept connections. For each connection accepted, the server continually receives a message and echoes it via the data socket attached to the connection, until the end-of-session message is received. At the end of the session, the data socket for the current client is closed, and the connection is terminated. The server then waits to accept another connection.

Throughout a session, the server maintains its connection with the client and exchanges data with the connected client via a data socket dedicated to that client. If another client connects to the server while it is already occupied with a session, the client will not be able to exchange data with the server until the server has completed the current session. Figure 5.7 shows the sequence diagram of two sessions conducted when client 2 attempts to connect to the server while client 1 is being served. Note that there is no interleaving of the sessions in this case.

Fig 5.7 EchoServer2 will not allow interleaved sessions

5.8 Iterative server and Concurrent server

With a connection-oriented server such as DaytimeServer2 and EchoServer2, there is no overlapping of client sessions, since the server is limited to exchanging data with a client whose connection it has accepted. Such a server is said to be an iterative server, since it services one client at a time. When requesting service from a popular iterative server, a client will be blocked until all preceding clients have been served. The result can be a significant blocking time if the service sessions are lengthy, such as in the case of a file transfer protocol.

Suppose each session can be expected to last ‘t’ time units and that ‘n’ clients have requested connection at a given time. Disregarding other delays for the sake of simplicity, the next client who requests connection can expect to be blocked for at least n*t time units. If t is large, the time taken for the data to reach the destination will be unacceptable. The solution to this problem is to introduce concurrency to the server, resulting in a concurrent server. A concurrent server is capable of conducting multiple client sessions in parallel which can be provided using threads or using asynchronous IPC operations.

Similar to iterative servers, there are concurrent servers, which use a single connection socket to listen for connections. But a concurrent server creates a new thread to accept each connection and to conduct a service session with the connected client; the thread is terminated upon the conclusion of the session.

Figure 5.8 shows the sequence diagram for two concurrent sessions. With a concurrent server, a client will not have to wait long for its connection to be accepted;

   Fig 5.8 EchoServer3 supporting two concurrent client sessions

5.9 Stateful and Stateless Servers

Both the Daytime protocol and the Echo protocol belong in a category of protocols known as stateless protocols, as opposed to stateful protocols. A protocol is stateless if no state information needs to be maintained by the server.

Such is the case with the Daytime protocol, where the server merely sends a timestamp obtained from the system to each client; and also with the Echo protocol, where the protocol only requires that the server echo each message it receives. In either protocol, the task performed by the server is independent of its state, such as how long the server has been in service or which client it is serving.

A stateless server is one that provides a service according to a stateless protocol and hence does not have to maintain any state information, as in the case of the Daytime server or the Echo server. A stateful server, as the name implies, is one that must maintain some state information in order to provide its service.

5.9.1 Global State Information

The global state information is maintained by the server for all the clients throughout the lifetime of a server. For example, suppose a protocol, which we will call the counter protocol, requires that a server maintain a counter initialized to 0.

Each time the server is contacted by a client, it increments the counter by 1 and sends the current value of the counter to the client. To provide such a service, the server must have the value of the counter placed in some storage where it can be retrieved and updated throughout the execution of the server.

For a simple counter, the storage may be implemented using a variable of primitive data type in Java. For more complex state information, the storage may be implemented using a file, a database, or other mechanisms.

5.9.2 Session State Information

For some protocols or applications, there is a need to maintain information specific to a client session.

Consider a network service such as ftp. A file is typically transferred to blocks, requiring several rounds of data exchanges to complete the file transfer. The state information of each session includes:

1. The name of the file being used

2. The current block number

3. The action (get, put, etc) being performed on the file

There are at least two schemes to maintain the session state data.

Stateless Server: In one scheme, the session state information may be maintained by the client so that each request contains the session state information, allowing the server to service each request in accordance with the state data sent in the request.

The dialog during a session will then proceed roughly as follows:

Client: Please send me block 1 of the file foo in directory someDir.

Server: Okay. Here is that block of the file.

Client: Please send me block 2 of the file foo in directory someDir.

Server: Okay. Here is that block of the file.

….

Client: Please send me block n of the file foo in directory someDir.

Server: Okay. Here is that block of the file.

By requiring the client to maintain the session data, this scheme allows the server to process each request in the same manner, and thereby reduces the complexity of its application logic. Such a server is known as a stateless server.

Stateful Server: In the second scheme, the session state information may be maintained by the server, in which case the dialog during a session may proceed roughly as follows:

Client: Please send me the file foo in directory someDir.

Server: Okay. Here is block 0 of the file foo.

Client: Got it.

Server: Okay. Here is block 1of the file foo.

Client: Got it.

….

Server: Okay. Here is block n of the file foo.

Client: Got it.

With this scheme, the server keeps track of the progress of the session by maintaining the session state. Such a server is known as a stateful server. Figure 5.9 illustrates the difference between a stateless server and a stateful server.

        Fig 5.9 Difference between a stateless server and a stateful server

Stateful servers are more complex to design and implement. In addition to the logic required for maintaining state data, provisions must be made to safeguard the state information in the event that a session is disrupted. If a stateful server host fails temporarily in the midst of a session, it is important for the ongoing session to resume in the correct state.

Another example of a stateful protocol is one for a shopping cart application. Each session must maintain state data that keeps track of the identity of the shopper and the cumulative contents of the shopping cart.