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.