The Client-Server Model – part 1

M. L. Liu

Distributed Computing, Liu 1

 Introduction
The Client-Server paradigm is the most
prevalent model for distributed computing
protocols.
It is the basis of all distributed computing
paradigms at a higher level of abstraction.
It is service-oriented, and employs a
request-response protocol.

Distributed Computing, Liu 2

 The Client-Server Paradigm
A server process, running on a server host, provides access
to a service.
A client process, running on a client host, accesses the
service via the server process.
The interaction of the process proceeds according to a
protocol. s e r vic e r e que s t
a c lie nt pr o c e s s
a s e r ve r pr o c e s s
S e r ve r h o s t a s e r vic e

C l i e nt ho st
...

Th e C l i e n t- S e r ve r P ar ad i g m , c o n c e p tu al

Distributed Computing, Liu 3

 Client-server applications and services
An application based on the client-server
paradigm is a client-server application.
On the Internet, many services are Client-
server applications. These services are
often known by the protocol that the
application implements.
Well known Internet services include
HTTP, FTP, DNS, finger, gopher, etc.
User applications may also be built using
the client-server paradigm.
Distributed Computing, Liu 4
A Sample Client-Server Application

Distributed Computing, Liu 5

 Client-server system architecture
vs.
Client-server distributed computing

In the client-server system architecture,

the terms clients and servers refer to
computers, while in the client-server
distributed computing paradigm, the
terms refer to processes.

Distributed Computing, Liu 6

 Client-server, an overloaded term
clie n t h o s ts

s e rvic e re que s t
a c lie nt pro c e s s
s e rv e r h os t a s e rve r pro c e s s
Se r ve r ho s t a s e rvic e

C l i e nt ho st

...
...

The C l i e nt-Se r ve r P ar adi g m , c o nc e ptual

C l i e nt-Se r ve r C o m puti ng P ar adi g m

C l i e nt-Se r ve r Syste m Ar c hi te c tur e C lie n t pro ce s s e s (o bje cts ) m a k e u s e o f a s e rv ice

pro v ide d by a s e rv e r pro ce s s ( o bje ct) ru n n in g o n
C lie n t h o s t s m a k e u s e o f s e rv ice s
a s e rve r h o s t .
pro v ide d o n a s e rv e r h o s t.

Distributed Computing, Liu 7

 A protocol/service session

In the context of the client-server model, we will

use the term session to refer to the interaction
between the server and one client. The service
managed by a server may be accessed by multiple
clients who desire the service, sometimes
concurrently. Each client, when serviced by the
server, engages in a separate session with the
server, during which it conducts a dialog with the
server until the client has obtained the service it
required

Distributed Computing, Liu 8

A service session

s t a rt s e rv ice

a cce pt a clie n t's

re qu e s t fo r a s e s s io n

co n du ct a s e s s io n
with th e clie n t

Distributed Computing, Liu 9

 The Protocol for a Network Service
A protocol is needed to specify the rules
that must be observed by the client and
the server during the conductin of a
service. Such rules include specifications
on matters such as (i) how the service is to
be located, (ii) the sequence of interprocess
communication, and (iii) the representation
and interpretation of data exchanged with
each IPC.
On the Internet, such protocols are
specified in the RFCs.
Distributed Computing, Liu 10
 Locating the service
A mechanism must be available to allow a client process to
locate a server for a given service.
A service can be located through 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
for Internet services. 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 reserved on each Internet host for that service.
At a higher level of abstraction, a service may be identified
using a logical name registered with a registry, the logical
name will need to be mapped to the physical location of the
server process. If the mapping is performed at runtime
(that is, when a client process is run), then it is possible for
the service’s location to be dynamic, or moveable.

Distributed Computing, Liu 11

The interprocess communications and
event synchronization
clie n t s e rv e r
re qu e s t 1

re s po n s e 1

re qu e s t 2

re s po n s e 2

re qu e s t n
re s po n s e n

Distributed Computing, Liu 12

 Implementation of a network service
Any implementation of the client or server
program for this service is expected to adhere
to the specification for the protocol, including
how the dialogs of each session should
proceed. Among other things, the
specification defines (i) which side (client or
server) should speak first, (ii) the syntax and
semantic of each request and response, and
(iii) the action expected of each side upon
receiving a particular request or response.

Distributed Computing, Liu 13

 The interprocess communications and
event synchronization

Typically, the interaction of the client and

server processes follows a request-response
pattern.
clie n t s e rv e r
re qu e s t 1

re s pon s e 1

re qu e s t 2

re s po n s e 2

re qu e s t n
re s po n s e n

Distributed Computing, Liu 14

 Session IPC examples
The dialog in each session follows a pattern prescribed in the
protocol specified for the service.
Daytime service [RFC867]:
Client: Hello, <client address> here. May I have a timestamp
please.
Server: Here it is: (time stamp follows)
World Wide Web session:
Client: Hello, <client address> here.
Server: Okay. I am a web server and speaks protocol HTTP1.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 follows).

Distributed Computing, Liu 15

 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.

Distributed Computing, Liu 16

Software Engineering for a Network Service

c l i e nt-s i de s o ftw ar e
s e r ve r -s i de s o ftw ar e
pre s e n ta tio n lo g ic
a pplica tio n lo g ic
a pplica tio n lo g ic
s e rv ice lo g ic
s e rv ice lo g ic

Distributed Computing, Liu 17

 Daytime Client-server using
Connectionless Datagram Socket
Client-side presentation logic
DaytimeClient1.java encapsulates the client-side
presentation logic; that is, it provides the interface for a
user of the client process. You will note that the code in
this class is concerned with obtaining input (the server
address) from the user, and displaying the output (the
timestamp) to the user. To obtain the timestamp, a method
call to a “helper” class, DaytimeClientHelper1.java, is
issued. This method hides the details of the application
logic and the underlying service logic. In particular, the
programmer of DaytimeClient1.java need not be aware of
which socket types is used for the IPC.

Distributed Computing, Liu 18

 Daytime Client-server using
Connectionless Datagram Socket -
continued
Client-side Application logic
The DaytimeClientHelper1.java class (Figure 6b) encapsulates the
client-side application logic. This module performs the IPC for
sending a request and receiving a response, using a specialized
class of the DatagramSocket, myClientDatagramSocket. Note
that the details of using datagram sockets are hidden from this
module. In particular, this module does not need to deal with
the byte array for carrying the payload data.

Service logic
The MyClientDatagram.java (Figure 6c) class provides the
details of the IPC service, in this case using the
datagram socket API.

Distributed Computing, Liu 19

 Advantages of separating the layers of logic
• It allows each module to 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 logic and the
service logic may focus on developing the other modules.

• The separation allows modifications to be made to the logic at

the presentation without requiring changes to be made at the
lower layers. For example, the user interface can be changed
from text-mode to graphical without requiring any change be
made to the application logic or the service logic. Likewise,
changes made in the application logic should be transparent
to the presentation layer, as we will soon illustrate with an
example client-server application.

Distributed Computing, Liu 20

 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 DaytimeServer1.java class encapsulates the server-side application logic. This module
executes in a forever loop, waiting for a request form a client and then conduct a service
session for that client. The module performs the IPC for receiving a request and sending a
response, using a specialized class of the DatagramSocket, myServerDatagramSocket.
Note that the details of using datagram sockets are hidden from this module. In particular,
this module does not need to deal with the byte array for carrying the payload data.
Service logic
The MyServerDatagram.java class provides the details of the IPC service, in this case
using the datagram socket API.

Distributed Computing, Liu 21

 Example protocol: daytime
Defined in RFC867

s e rv e r
clie n t

s e qu e n ce dia g ra m

da ta re pre s e n ta tio n : te x t (ch a ra cte r s trin g s )

da ta fo rm a t:
m : co n ta in s a tim e s ta m p, in a fo rm a t s u ch a s
W e d J a n 3 0 0 9 :5 2 :4 8 2 0 0 2
Distributed Computing, Liu 22
 Daytime Protocol
clie n t s e rv e r

m1

m2

s e qu e n ce dia g ra m

da ta re pre s e n ta tio n : te x t (ch a ra cte r s trin g s )

da ta fo rm a t:
m 1 ; a n u ll m e s s a g e - co n te n ts will be ig n o re d.
m 2 : co n ta in s a tim e s ta m p, in a fo rm a t s u ch a s
W e d J a n 3 0 0 9 : 5 2 :4 8 2 0 0 2

Distributed Computing, Liu 23

 Daytime Protocol Implementation
Sample 1 – using connectionless sockets:
DaytimeServer1.java
DaytimeClient1.java

Distributed Computing, Liu 24

 The getAddress and getPort Methods

Method (of Description

DatagramPacket class)
public InetAddress getAddress( ) Return the IP address of the remote host from a socket of
which the datagram was received.

public int getPort( ) Return the port number on the remote host from a socket
of which the datagram was received.

Distributed Computing, Liu 25

 UML Diagram for the Datagram
Daytime server
D a ta g ra m P a ce t
D a ta g ra m M e s s a g e

pre s e n t a tio n + a pplica tio n

lo g ic

D a y ti m e S e rve r 1

M y S e r ve rD a ta g r a m
S o ck e t
D a ta g r a m S o c k e t

se n dM e s sa g e ( )
re c e i ve M e s s a g e ( )
re c e i ve M e s s a g e A n d
S e n de r( )

s e rv ice lo g ic
Distributed Computing, Liu 26
UML Diagram for the Datagram
Daytime Client
pre s e n t a t io n lo g ic

D a y ti m e C l i e n t 1

D a ta g ra m P a c e t

D a y t im e C lie n t H e lp e r 1
M y C l i e n tD a ta g ra m
S ock e t D a ta g ra m S o c k e t

s e n dM e s s a ge ( )
r e ce i ve M e s s a g e ( )

a pplica t io n lo g ic
Distributed Computing, Liu 27
 Daytime Protocol Implementation
Connection-oriented Daytime Server Client:
Sample 2 – using connection-oriented
sockets:
DaytimeServer2.java
DaytimeClient2.java
DaytimeClientHelper2.java
MyStreamSocket.java

Distributed Computing, Liu 28

 UML Diagram for stream mode
Daytime Server s e rv ice lo g ic

S e rve r S o c k e t

pre s e n ta tio n an d a pplica t io n

lo g ic

D a y ti m e S e r ve r 2

M y S tre a m S o ck e t
S o ck e t

s e n dM e s s a g e ( )
re c e i ve M e s s a g e ( )
re c e i ve M e s s a g e A n d
S e n de r ( )

Distributed Computing, Liu 29

 UML Diagram for stream mode
Daytime Client
pre s e n ta tio n lo g ic

D a y ti m e C l i e n t2

D a y t im e C lie n t H e lp e r 2 M y S tre a m S o ck e t S o ck e t

se n dM e s s a ge ( )
re c e i ve M e s s a g e ( )

a pplica t io n lo g ic
s e rv ice lo g ic

Distributed Computing, Liu 30

 Testing a Network Service
Because of its inherent complexity, network software is
notoriously difficult to test.
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 (to be introduced in the next section) which is known to be
correct and which uses a compatible IPC mechanism to test the
client independent of the server; doing so allows you to develop
the client independent of the server.
Use diagnostic messages throughout each program to report the
progress of the program during runtime.
Test the client-server suite on one machine before running the
programs on separate machine.

Distributed Computing, Liu 31