Clients

A Program, Which interact with a human user or a remote servers

Typically, the users interact with the client via a GUI
The client is the machine (workstation or PC) running the front-end applications.
It interacts with a user through the keyboard, display, and pointing device such as a mouse.
The client has no direct data access responsibilities. It simply requests processes from the
server and displays data managed by the server.
Networked User Interfaces
A major task of client machines is to provide the means for users to interact with remote
servers
Two ways to support client-server interaction:
1. For each remote service - the client machine will have a separate counterpart that can
contact the service over the network.
▪ Example: an agenda running on a user's PDA that needs to synchronize with a remote,
possibly shared agenda.
▪ In this case, an application-level protocol will handle the synchronization
2. Provide direct access to remote services by only offering a convenient user interface.
▪ The client machine is used only as a terminal with no need for local storage, leading to
an application neutral solution.
▪ In the case of networked user interfaces, everything is processed and stored at the server.
▪ This thin-client approach is receiving more attention as Internet connectivity increases,
and hand-held devices are becoming more sophisticated.
Networked User Interfaces

Networked application with its own General solution to allow access

protocol to remote applications.
The X Window System

Used to control bit-mapped terminals, which include a monitor,

keyboard, and a pointing device such as a mouse.
X kernel is heart of the system.
▪ Contains all the terminal-specific device drivers - highly
hardware dependent
▪ X kernel offers a low-level interface for controlling the screen
and for capturing events from the keyboard and mouse
▪ This interface is made available to applications as a library called
Xlib.
Client-Side Software for Distribution Transparency
Access transparency
▪ Handled through client-side stubs for RPCs
▪ Same interface as at the server, hides different machine architectures
Location/migration transparency
▪ let client-side software keep track of actual location (if server changes location: client
rebinds to the server if necessary).
▪ Hide server locations from user.
Replication transparency
▪ multiple invocations handled by client stub
Client machine Server 1 Server 2 Server 3

Client Server Server Server

appl. appl. appl. appl.

Client side handles

Request replication Replicated request
Client-Side Software for Distribution Transparency
Failure transparency
▪ Mask server and communication failures: done through client middleware,
▪ e.g. connect to another machine.
Concurrency transparency
▪ Handled through special intermediate servers, notably transaction monitors, and requires
less support from client software.
Servers
A server is a process implementing a specific service on behalf of a collection of clients.
▪ Each server is organized in the same way:
▪ It waits for an incoming request from a client ensures that the request is fulfilled
▪ It waits for the next incoming request.
Types of server
1. Iterative server
2. Concurrent server
Iterative server and Concurrent server
Iterative server
▪ Iterative server handles request, then returns results to the client; any new client requests
must wait for previous request to complete (also useful to think of this type of server as
sequential).
▪ Process one request at a time
▪ When an iterative server is handling a request, other connections to that port are blocked.
▪ The incoming connections must be handled one after another.
▪ Iterative servers support a single client at a time.
▪ Much easier to build, but usually much less efficient
Concurrent server
▪ Process multiple requests simultaneously.
▪ Concurrent servers support multiple clients concurrently (may or may not use concurrent
processes)
▪ Clients queue for connection, then are served concurrently. The concurrency reduces
latency significantly.
▪ Concurrent server does not handle the request itself; a separate thread or sub-process
handles the request and returns any results to the client; the server is then free to
immediately service the next client (i.e., there’s no waiting, as service requests are
processed in parallel).
▪ A multithreaded server is an example of a concurrent server.
Where do clients contact a server?
Clients send requests to an end point, also called a port, at the machine where the server is
running.
Each server listens to a specific end point.
How do clients know the end point of a service?
1. Globally assign end points for well-known services.
Examples:
1. Servers that handle Internet FTP requests always listen to TCP port 21.
2. An HTTP server for the World Wide Web will always listen to TCP port 80.
These end points have been assigned by the Internet Assigned Numbers Authority (IANA).
With assigned end points, the client only needs to find the network address of the machine
where the server is running.
Client-to-server binding using a daemon
Many services that do not require a pre-assigned end point.
Example: A time-of-day server may use an end point that is dynamically assigned to it by its
local operating system.
A client will look need to up the end point.
Solution: a daemon running on each machine that runs servers.
The daemon keeps track of the current end point of each service implemented by a co-located
server.
The daemon itself listens to a well-known end point.
A client will first contact the daemon, request the end point, and then contact the specific
server (Figure(a))
Client-to-server binding using a superserver
Common to associate an end point with a specific service.
Implementing each service by means of a separate server may be a waste of resources.
Example: UNIX system
many servers run simultaneously, with most of them passively waiting for a client request.
Instead of having to keep track of so many passive processes, it is often more efficient to
have a single superserver listening to each end point associated with a specific service,
(Figure (b))
Stateless server
A stateless server is a server that treats each request as an independent transaction that is
unrelated to any previous request.
Example: A Web server is stateless.
▪ It merely responds to incoming HTTP requests, which can be either for uploading a file
to the server or (most often) for fetching a file.
▪ When the request has been processed, the Web server forgets the client completely.
▪ The collection of files that a Web server manages (possibly in cooperation with a file
server), can be changed without clients having to be informed.

Form of a stateless design - soft state.

 The server promises to maintain state on behalf of the client, but only for a limited time.
 After that time has expired, the server falls back to default behavior, thereby discarding
any information it kept on account of the associated client.
Stateful server
A stateful server remembers client data (state) from one request to the next.
Information needs to be explicitly deleted by the server.
Example:
▪ A file server that allows a client to keep a local copy of a file, even for performing
update operations.
▪ The server maintains a table containing (client, file) entries.
▪ This table allows the server to keep track of which client currently has the update
permissions on which file and the most recent version of that file
Improves performance of read and write operations as perceived by the client
Server Clusters
A server cluster is a collection of machines connected through a network, where each
machine runs one or more servers.
A server cluster is logically organized into three tiers
▪ First tier
▪ Second tier
▪ Third tier
 Server Clusters
First tier - consists of a (logical) switch through which client requests are routed
▪ The switch (access/replication transparency)
Second tier - application processing
▪ Cluster computing
▪ Enterprise server clusters
Third tier - data-processing servers - notably file and database servers
▪ For other applications, the major part of the workload may be here
Logical switch Application/Compute Distributed File/Database
(possibly multiple) Servers system

Dispatched
request
Client request

First tier Second tier Third tier

Issue: When a server cluster offers, multiple different machines may run different application
servers.
The switch will have to be able to distinguish services or otherwise it cannot forward requests
to the proper machines.
Many second-tier machines run only a single application.
This limitation comes from dependencies on available software and hardware, but also that
different applications are often managed by different administrators.
Consequence - certain machines are temporarily idle, while others are receiving an overload
of requests.
Solution: Temporarily migrate services to idle machines to balance load.
Use virtual machines allowing a relative easy migration of code to real machines.
Code Migration
Traditionally, communication in distributed systems is concerned with exchanging data
between processes.
Code migration in the broadest sense deals with moving programs between machines, with
the intention to have those programs be executed at the target
Process migration in which an entire process is moved from one machine to another
Code migration is often used for load distribution, reducing network bandwidth, dynamic
customization, and mobile agents.
Code migration increases scalability, improves performance, and provides flexibility.
Reasons for Code Migration:
▪ Performance
▪ Flexibility
Performance in Code Migration
Overall system performance can be improved if processes are moved from heavily-loaded to
lightly loaded machines.
How system performance is improved by code migration?
▪ Using load distribution algorithms
▪ Using qualitative reasoning
• Migrating parts of the client to the server
• Migrating parts of the server to the client
 Flexibility in Code Migration
The traditional approach to building distributed applications is to partition the application into
different parts, and decide in advance where each part should be executed.
For example,
▪ Suppose a client program uses some proprietary APIs for doing some tasks that are rarely needed,
and because of the huge size of the necessary API files, they are kept in a server.
▪ If the client ever needs to use those APIs, then it can first dynamically download the APIs and
then use them.
2. Client and Server
Client Communicate Server

Advantage of this model: Clients need not have all the

software preinstalled to do common tasks.
Disadvantage of this model : Security - blindly trusting
that the downloaded code implements only the
advertised APIs while accessing your unprotected hard Service-specific 1. Client fetches code
disk Client-side code

Code repository
Models for Code Migration
To get a better understanding of the different models for code migration, we use a framework
described in Fuggetta et al. (1998).
In this framework, a process consists of three segments.
1. The code segment: It is the part that contains the set of instructions that make up the
program that is being executed.
2. The resource segment: It contains references to external resources needed by the
process, such as files, printers, devices, other processes, and so on.
3. The execution segment: It is used to store the current execution state of a process,
consisting of private data, the stack, and, of course, the program counter.
Weak Mobility Vs. Strong Mobility

Parameters Weak Mobility Strong Mobility

Definition In this model, it is possible to transfer In contrast to weak mobility, in systems that support
only the code segment, along with strong mobility the execution segment can be
perhaps some initialization data . transferred as well .

Characteristic A transferred program is always started A running process can be stopped, subsequently
Feature from its initial state moved to another machine, and then resume
execution where it left off .

Example Java applets – which always start D’Agents ht.tps://sci-hub.hkvisa.net/10.1002/spe.449

execution from the beginning

Benefit Simplicity Much more general than weak mobility

Migration Initiation
Sender-Initiated Migration
It is initiated at the machine where the code currently resides or is being executed
Examples:
▪ Uploading programs to a compute server.
▪ Sending a search program across the Internet to a web database server to perform the
queries at that server.

Receiver-Initiated Migration
The initiative for code migration is taken by the target machine
Example: Java applets.
Alternatives for code migration
Execute at target process
Sender-Initiated
mobility
Execute in separate process
Weak mobility
Execute at target process
Receiver-Initiated
mobility
Mobility Execute in separate process
mechanism
Migrate process
Sender-Initiated
mobility
Clone process
Strong mobility

Migrate process
Receiver-Initiated
mobility
Clone process
Execute Migrated Code for weak mobility
In the case of weak mobility, it also makes a difference if the migrated code is executed by
the target process, or whether a separate process is started.
For example, Java applets are simply downloaded by a web browser and are executed in the
browser's address space.
Benefit for executing code at target process: There is no need to start a separate process,
thereby avoiding communication at the target machine.
Drawback for executing code at target process: The target process needs to be protected
against malicious or inadvertent code executions.
Migrate or Clone Process (for strong mobility)
Instead of moving a running process, also referred to as process migration, strong mobility
can also be supported by remote cloning.
In contrast to process migration, cloning yields an exact copy of the original process, but
now running on a different machine.
The cloned process is executed in parallel to the original process.
Benefit of cloning process: The model closely resembles the one that is already used in many
applications. The only difference is that the cloned process is executed on a different
machine.
In this sense, migration by cloning is a simple way to improve distribution transparency.
Migration and Local Resources
What often makes code migration so difficult is that the resource segment cannot always be
simply transferred along with the other segments without being changed.
When the process moves to another location, it will have to give up the port and request a
new one at the destination.
Process-to-Resource Bindings
1. Binding by Identifier
2. Binding by Value
3. Binding by Type
Process-to-Resource Bindings
Binding by Identifier
A process refers to a resource by its identifier. In that case, the process requires precisely the
referenced resource, and nothing else.
Examples:
▪ A URL to refer to a specific web site.
▪ Local communication endpoints (IP, port etc.)
Binding by Value
Only the value of a resource is needed. In that case, the execution of the process would not
be affected if another resource would provide the same value.
Example: Standard libraries for programming languages.
Binding by Type
A process indicates it needs only a resource of a specific type.
Example: References to local devices, such as monitors, printers and so on.
Resource Types
When migrating code, we often need to change the references to resources, but cannot affect
the kind of process-to-resource binding.
Resource Types:
Unattached resources :
▪ They can be easily moved between different machines.
▪ Example: Typically (data) files associated only with the program that is to be migrated.
Fastened resources:
▪ They may be copied or moved, but only at relatively high costs.
▪ Example: Local databases and complete web sites.
▪ Although such resources are, in theory, not dependent on their current machine, it is
often infeasible to move them to another environment.
Fixed resources:
▪ They are intimately bound to a specific machine or environment and cannot be moved.
▪ Example: Local devices, local communication end points
Managing Local Resources
Combining three types of process-to-resource bindings, and three types of resource-to-machine bindings, leads
to nine combinations that we need to consider when migrating code

Resource-to-machine Binding

Unattached Fastened Fixed

By Identifier MV (or GR) GR (or MV) GR
Process-to-
resource By Value CP (or MV, GR) GR (or CP) GR
Binding
By Type RB (or MV, CP) RB (or GR, CP) RB (or GR)

GR Establish global system wide reference

MV Move the resource
CP Copy the value of the resource
RB Re-bind to a locally available resource
Examples:
A process is bound to a resource by identifier.
i. When the resource is unattached, it is best to move it along with the migrating code.
ii. When the resource is shared by other processes establish a global reference
· a reference that can cross machine boundaries.
e.g. a URL.
iii. When the resource is fastened or fixed, the best solution is to create a global reference.

Problems with global reference

Reference may be expensive to construct.
e.g. a program that generates high-quality images for a dedicated multimedia workstation.
Fabricating high-quality images in real time is a compute-intensive task, for which reason the
program may be moved to a high-performance compute server.
Establishing a global reference to the multimedia workstation means setting up a
communication path between the compute server and the workstation.
Significant processing involved at both the server and the workstation to meet the bandwidth
requirements of transferring the images.
Nt result - moving the program to the compute server is not such a good idea, only because
the cost of the global reference is too high.
Migrating a process that makes use of a local communication end point.
Here is a fixed resource to which the process is bound by the identifier.
Two solutions:
1. Let the process set up a connection to the source machine after it has migrated and install a
separate process at the source machine that forwards all incoming messages.
Drawback - whenever the source machine malfunctions, communication with the migrated
process may fail.
2. Have all processes that communicated with the migrating process, change their global
reference, and send messages to the new communication end point at the target machine.
e.g. bindings by value.
A fixed resource.
The combination of a fixed resource and binding by value occurs when a process assumes
that memory can be shared between processes.
Establishing a global reference would require a distributed form of shared memory.
In many cases, this is not really a viable or efficient solution.
Fastened resources.
Fastened resources that are referred to by their value, are typically runtime libraries.
Normally, copies of such resources are readily available on the target machine, or should
otherwise be copied before code migration takes place.
Establishing a global reference is a better alternative when huge amounts of data are to be
copied, as may be the case with dictionaries and thesauruses in text processing systems.
Unattached resources.
The best solution is to copy (or move) the resource to the new destination, unless it is shared
by a number of processes.
In the latter case, establishing a global reference is the only option.
e.g. bindings by type.
Irrespective of the resource-to-machine binding, the solution is to rebind the process to a
locally available resource of the same type.
If the resource is not available, must copy or move the original one to the new destination, or
establish a global reference.
Migration in Heterogeneous Systems
Distributed systems are constructed on a heterogeneous collection of platforms, each having
their own operating system and machine architecture.
Migration requires that each platform be supported - the code segment can be executed on
each platform.
Must ensure that the execution segment can be properly represented at each platform.
Migrate entire computing environments
Compartmentalize the overall environment to provide processes in the same part their own
view on their computing environment.
Can decouple a part from the underlying system and migrate it to another machine.
Migration would provide a form of strong mobility for processes, as they can then be moved
at any point during their execution, and continue where they left off when migration
completes.
Solves bindings to local resources problem - local resources become part of the environment
that is being migrated.

Why migrate entire environments?
It allows continuation of operation while a machine needs to be shutdown.
e.g. in a server cluster, the systems administrator may decide to shut down or replace a
machine
can temporarily freeze an environment, move it to another machine (where it sits next to
other, existing environments), and unfreeze it.
Example: Real-time migration of a virtualized operating system (Clark et al. 2005).
Useful in a cluster of servers where a tight coupling is achieved through a single, shared
local-area network.
Migration involves two major problems:
real-time migration of a virtualized operating system
migrating bindings to local resources.
Real-time migration of a virtualized operating system:
Three ways to handle migration (which can be combined):
1. Pushing memory pages to the new machine and resending the ones that are later modified
during the migration process.
2. Stopping the current virtual machine; migrate memory, and start the new virtual machine.
3. Letting the new virtual machine pull in new pages as needed, that is, let processes start on
the new virtual machine immediately and copy memory pages on demand.
Option #2 may lead to unacceptable downtime if the migrating virtual machine is running a
live service.
Option #3 extensively prolong the migration period lead to poor performance because it takes
a long time before the working set of the migrated processes has been moved to the new
machine.
 Clark et al. propose to use a pre-copy approach which combines the Option #1, along with a brief stop-and-copy
phase as represented by the Option #2.

This combination can lead to service downtimes of 200 ms or less.