Distributed System (CACS 352) : Compiled by

Course Title:
Distributed System
(CACS 352)
BCA 6th semester
Tribhuvan University (TU)
Compiled By
Ujjwal Rijal
rijalujjwal09@gmail.com
rijalujjwal09@gmail.com 1
Unit-1
Introduction
Compiled By
Ujjwal Rijal
What is Distributed System?
 A distributed system is a collection of autonomous computing
elements that appears to its users as a single coherent system.
 This definition refers to two characteristic features of
distributed systems.
 The first one is that a distributed system is a collection of
computing elements each being able to behave independently of
each other.
 A computing element, which will generally refer to as a node, can
be either a hardware device or a software process.
 A second feature is that users (be they people or applications)
believe they are dealing with a single system. This means that one
way or another the autonomous nodes need to collaborate.
 How to establish this collaboration lies at the heart of developing
distributed systems.
Characteristics of
Distributed System
 There are specially and characteristically two primary
characteristic features of distributed systems and they are
discussed below:
I. Collection of autonomous computing elements
o This illustrates that a distributed system is a collection of computing
elements each being able to behave independently of each other.
o A computing element, which will generally refer to as a node can be
either a hardware device or a software process.
o Modern distributed systems can, and often will consist of all kinds of
nodes, ranging from very high performance computers to small plug
computers or even smaller devices.
o A fundamental principle is that nodes can act independently from
each other, although it should be obvious that if they ignore each
other, then there is no use in putting into the same distributed
system.
Characteristics of
Distributed System
II. Single coherent system
o It illustrates that users (be they people or applications) believe they are dealing
with a single system. This means that one way or another the autonomous nodes
need to collaborate.
o How to establish this collaboration lies at the heart of developing distributed
systems.
o As mentioned, a distributed system should appear as a single coherent system.
In some cases, researchers have even gone so far as to say that there should be
a single-system view, meaning that end users should not even notice that they
are dealing with the fact that processes, data, and control are dispersed across
a computer network.
o Achieving a single-system view is often asking too much, for which reason, in our
definition of a distributed system, we have opted for something weaker, namely
that it appears to be coherent.
o Roughly speaking, a distributed system is coherent if it behaves according to the
expectations of its users.
o More specifically, in a single coherent system, the collection of nodes as a whole
operates the same, no matter where, when, and how the interaction between a
user and the system takes place.
Design Goals of
Distributed System
 In this section, we discuss four important goals
that should be met to build a distributed system
worth the effort.
 A distributed system should make resources easily
accessible; it should hide the fact that resources
are distributed across a network; it should be
open; and it should be scalable.
 Now, they are discussed in detail as:
o Supporting Resource Sharing
o Making Distribution Transparent
o Openness
o Scalability
o Pitfalls / Fallacies rijalujjwal09@gmail.com 6
Design Goals of
Distributed System
 Supporting Resource Sharing
o An important goal of distributed system is to make it easy for users
and applications to access and share remote resources.
o Resources can be virtually anything, but typical examples include
peripherals, storage facilities, data, files, services, and networks, to
name just a few.
o There are many reasons for wanting to share resources. One obvious
reason is that of economics. For example, it is cheaper to have a
single high-end reliable storage facility be shared than having to buy
and maintain storage for each user separately.
o However, resource sharing in distributed systems is perhaps best
illustrated by the success of file-sharing peer-to-peer networks like
BitTorrent. These distributed systems make it extremely simple for
users to share files across the internet.
Design Goals of
Distributed System
 Making Distribution Transparent
o Another important goal of distributed system is to hide
the fact that it processes and resources are physically
distributed across multiple computers, possibly separated
by large distances.
o In other words, it tries to make the distribution of
processes and resources transparent or tries to ensure
distribution transparency i.e. invisible, to end users and
applications.
Design Goals of
Distributed System
 Types of Distribution Transparency
o Access transparency, Location transparency,
Relocation transparency, Migration transparency,
Replication transparency, Concurrency transparency,
Mobility transparency, Performance transparency,
Scaling transparency, and Failure transparency.
o Now, they are discussed below:
Design Goals of
Distributed System
I. Access Transparency
o It deals with hiding differences in data representation and the
way that objects can be accessed.
o At a basic level, we want to hide differences in machine
architectures, but more important is that we reach agreement on
how data is to be represented by different machines and
operating systems.
o For example, a distributed system may have computer systems
that run different operating systems, each having their own file-
naming conventions.
o Differences in naming conventions, differences in file operations,
or differences in how low-level communication with other
processes is to take place, are the examples of access issues that
should preferably be hidden from the users and the applications.
o Examples: File system operations in NFS (Network File System),
Navigation in the Web, SQL Queries, etc. rijalujjwal09@gmail.com
10
Design Goals of
Distributed System
II. Location Transparency
o An important group of transparency types concerns the
location of a process or a resource.
o Location transparency refers to the fact that users can
not tell where an object is physically located n the system.
Naming plays an important role in achieving location
transparency.
o An example of such a name is Uniform Resource Locator
(URL). A typical URL could have the
form http://www.example.com/index.html, which
indicates a protocol (http), a hostname
(www.example.com), and a file name (index.html).
o Examples: File system operations in NFS, Pages in the
Web, Tables in distributed databases, etc.
Design Goals of
Distributed System
III. Relocation Transparency
o The entire site may have been moved from one data centre
to another, yet users should not notice. The URL gives no
clue as to whether the file has always been at its current
location or was recently moved there.
o This was the case of relocation transparency, which is
becoming increasingly important in the context of cloud
computing.
Design Goals of
Distributed System
IV. Migration Transparency
o Where relocation transparency refers to being moved by
the distributed system, migration transparency is offered
by a distributed system when it supports the mobility of
processes and resources initiated by the users, without
affecting ongoing communication and operations.
o A typical example is communication between mobile
phones; regardless whether two people are actually
moving, mobile phones will allow them to continue their
conversation.
o Other examples could be online tracking and tracing of
goods as they are being transported from one place to
another, and teleconferencing using devices that are
equipped with mobile internet.
Design Goals of
Distributed System
V. Replication Transparency
o Replication plays an important role in distributed systems.
For example, resources may be replicated to increase
availability or to improve performance by placing a copy close
to the place where it is accessed.
o Replication transparency deals with hiding the fact that
several copies of a resource exist, or that several processes
are operating in some form of lockstep mode so that one can
take over when another fails.
o To hide replication from users, it is necessary that all
replicas have the same name. Consequently, a system that
supports replication transparency should generally support
location transparency as well, because it would otherwise be
impossible to refer to replicas at different locations.
o Examples: Distributed DBMS, Mirroring Web Pages, etc.
Design Goals of
Distributed System
VI. Concurrency Transparency
o Concurrency transparency signifies that concurrent access
to a shared resource leaves that resource in a consistent
state.
o Consistency can be achieved through locking mechanisms,
by which users are, in turn, given exclusive access to the
desired resource.
o A more refined mechanism is to make use of transactions,
but this may be difficult to implement in a distributed
system, notably when scalability is an issue.
o Examples: NFS, Automatic teller machine network,
Database Management System (DBMS), etc.
Design Goals of
Distributed System
VII. Mobility Transparency
o Allows the movement of information objects within a
system without affecting the operations of users or
application programs
o Examples: NFS, Web Pages, etc.
VIII. Performance Transparency

o Allows the system to be reconfigured to improve
performance as loads vary.
o Example: Distributed make.
Design Goals of
Distributed System
IX. Scaling Transparency

o Allows the system and applications to expand in scale
without change to the system structure or the application
algorithms.
o Examples: World-Wide-Web, Distributed Database, etc.
Design Goals of
Distributed System
X. Failure Transparency
o Failure transparency means that a user or an application does
not notice that some piece of the system fails to work
properly, and that the system subsequently and automatically
recovers from that failure.
o Masking failures is one of the hardest issues in distributed
systems, and is even impossible when certain apparently
realistic assumptions are made.
o The main difficulty in masking and transparently recovering
from failures lies in the inability to distinguish between a dead
process and a painfully slowly responding one.
o For example, when contacting a busy web server, a browser will
eventually time out and reports that the web page is
unavailable. At that point, the user can not tell whether the
server is actually down or that the network is fully congested.
Design Goals of
Distributed System
 Openness
o An open distributed system is a system that offers services according to
the standard rules that describe the syntax and semantics of those
services.
o For example, in computer networks, standard rules govern the format,
contents, and meaning of messages sent and received. Such rules are
formalized in the protocols.
o Open systems are characterized by the fact that their key interfaces are
published. They are based on a uniform communication mechanism and
published interface for access to shared resources.
o These types of systems can be constructed from heterogeneous hardware
and software.
o The openness of distributed systems is determined primarily by the
degree to which new resource-sharing services can be added and be made
available for use by a variety of client programs.
o For example, Facebook and Twitter have API that allows developers to
develop their own software interactively. rijalujjwal09@gmail.com 19
Design Goals of
Distributed System
 Scalability
o Scalability of the system should remain efficient even with a significant increase in
the number of resources and users connected.
o Moreover, a system is said to be scalable if it can handle the addition of users and
resources without suffering a noticeable loss of performance or increase in
administrative complexity.
o According to Neuman(1994), scalability of a system can be measure along at least
three different dimensions, and they are:
With respect to its size
 It means that we can easily add more users and resources to the system. The problem
associated with this dimension is the problem of overloading.
With respect to geography
 A geographically scalable system is one in which the users and resources may lie far
apart. The problem associated with this dimension is the problem of communication
reliability.
With respect to administration
 It means that an administratively scalable system can still be easier to manage even if
it spans many independent administrative organizations. The problem associated with
this dimension is the problem of administrative mess.
Design Goals of
Distributed System
 Pitfalls / Fallacies
 Pitfall means for a hidden or unsuspected danger or difficulty.
 Distributed systems differ from traditional software because components are
dispersed across a network. Not taking this dispersion into account during design time
is what makes so many systems needlessly complex and results in mistakes that need to
be patched later on.
 Peter Deutsch, then at Sun Microsystems, formulated these mistakes as the
following false assumptions that everyone makes when developing a distributed
application for the first time:
o The network is reliable.
o The network is secure.
o The network is homogeneous.
o The topology does not change.
o Latency is zero.
o Bandwidth is infinite.
o Transport cost is zero.
o There is one administrator.
 These kinds of pitfalls should be strictly taken into account during the design of a
distributed application or system.
Types of
Distributed System
 A distributed system can be classified

into the following five main categories:
o Client-Server systems
o Peer-to-Peer systems
o Middleware
o Three-tier
o N-tier
Types of
Distributed System
I. Client-Server Systems
o This type of system requires the client to request a resource,
after which the server gives the requested resource. When a
client connects to a server, the server may serve multiple
clients at the same time.
o Client-Server systems are also referred to as “Tightly Coupled
Operating Systems”. This system is primarily intended for
multiprocessors and homogeneous multicomputer.
o Client-Server systems function as a centralized server since
they approve all the requests issued by the client systems.
o It is a distributed application structure that partitions tasks
or workloads between the providers of a resource or service,
called servers, and service requesters, called clients.
Types of
Distributed System
o A server host runs one or more server programs,

which share their resources with the clients. They
are usually multiple clients in communication with a
single server.
o The clients send requests to the server, and the
server responds to the client requests
appropriately.
o The client/ server model introduces two roles that
can be assumed by processes, i.e. the role of
service user (client) and the role of service
provider (server).
Types of
Distributed System
Types of
Distributed System
II. Peer-to-Peer Systems
o In contrast to the tightly coupled systems, the computer
networks used in these applications consist of a collection of
processors that do not share memory or a clock. Instead, each
processor has its own local memory.
o The processors communicate with one another through various
communication lines, such as high- speed buses or the
telephone lines.
o These systems are usually referred to as loosely coupled
systems (or distributed systems). The aim of the peer-to-peer
architecture is to exploit the resources in a large number of
participating computers for the fulfilment of a given task or
an activity.
Types of
Distributed System
Types of
Distributed System
III. Middleware
o Middleware enables the interoperability of all
applications running on the different operating systems.
Those programs are capable of transferring all data to
one another by using these services.
o Middleware is an infrastructure that appropriately
supports the development and execution of distributed
applications. It provides a buffer between the
applications and the network.
Types of
Distributed System
Types of
Distributed System
o In a sense, middleware is the same to a distributed

system as what an OS is to a computer; a manager of
resources offering its applications to efficiently
share and deploy those resources across a network.
o Next to resource management, it offers services that
can also be found in most of the operating systems
including:
 Facilities for inter-application communication.
 Security services.
 Accounting services.
 Masking of and recovery from failures, etc.
Types of
Distributed System
IV. Three Tier
o The information about the client is saved n the intermediate
tier rather than in the client, which simplifies development.
This type of architecture is most commonly used in online
applications.
o In the three-tier architecture, an intermediate process
connects the clients and servers. The intermediary can
accumulate frequently used server data to guarantee enhanced
performance and scalability.
o In database-based 3-tier client-server architecture, normally
there are three essential components; a client computer, an
application server, and a database server.
Types of
Distributed System
o The application server is the middle tier server which runs the
business application. The data is retrieved from database
server and it is forwarded to the client by the middle tier
server.
o Database-oriented middleware offers an Application
Programming Interface (API) access to a database.
o In 3-tier architecture, it is easier to modify or even replace
any tier without affecting the other tiers. The separation of
application and database functionality achieves better load
balancing.
o Moreover, necessary security guidelines can be put into effect
within the server tiers without affecting the clients.
Types of
Distributed System
Types of
Distributed System
V. N-Tier
o When a server or application has to transmit requests to other
enterprise services on the network, then n-tier systems are used.
o Multi-tier architecture is a client-server architecture in which the
functions such as presentation, application processing, and data
management are physically separated.
o By separating an application into tiers, developers obtain the option
of changing or adding a specific layer, instead of reworking the
entire application.
o It provides a model by which developers can create flexible and
reusable applications.
o The most general use of multi-tier architecture is the three-tier
architecture. A three-tier architecture is typically composed of a
presentation tier, and a data storage tier, and may execute on a
separate processor.
Types of
Distributed System
ASSIGNMENT - 1
ASSIGNMENT
1. Advantages/ Merits/ Pros of Distributed System.

2. Disadvantages/ Demerits/ Cons of the Distributed
System.
3. Prepare a case study on The World Wide Web
(WWW). Note: You need to discuss about the web
pages and its types, different types of protocols
across the web, web services, web server and its
types, scripting languages, and discussion about
the web and its contents, and so on.
Course Title:
Distributed System
(CACS 352)
BCA 6th semester-Tribhuvan University (TU)
Compiled by Ujjwal Rijal

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 1

Unit-2
Architecture

 Architectural Styles
• Distributed system architectures are bundled up with components and connectors.
• Components can be individual nodes or important components in the architecture whereas
connectors are the ones that connect each of these components.
• Component: A modular unit with well-defined replaceable and reusable interfaces.
• Connector: A communication link between modules which mediates coordination or cooperation
among the components.
• So, the idea behind distributed system architectures is to have these components presented on
different platforms, where components can communicate with each other over a communication
network in order to achieve specific objectives.

Contd. ….
• Distributed system architectures can be categorized into the following five categories on a
general emphasis or basis:
 Layered Architecture
 Object Based Architecture
 Data Centred Architecture
 Event Based Architecture
 Hybrid Architecture
• Now, they are discussed below:

Contd. ….
 Layered Architecture
• One way to achieve modularity in the distributed system is the Layered approach. This layer breaks up
the operating system into different layers.
• A common example for this is OSI model that incorporates a layered architecture when interacting with
each of the components.
• In this approach, the bottom layer is the hardware and the topmost layer is the user interface (UI).
• This allows implementers to change the inner workings, and increases modularity.
• As long as the external interface of the routines does not change, developers have more freedom to
change the inner workings of the routines.
• The main advantage with layered structure is the simplicity of construction and proper debugging. And
the main difficulty is defining the various layers.
• Also this OS structure tends to be less efficient than other implementations.
• An image demonstrating the layered approach is as follows:

Contd. ….
Fig: Layered Architecture of Distributed System

Contd. ….
• As seen from the above image, each upper layer is built on the bottom layer. All the
layers hide some structures, operations, etc. from their upper layers.
• One problem with the layered structure is that each layer needs to be carefully defined.
This is necessary because the upper layers can only use the functionalities of the layers
below them.
• This is highly advantageous structure because all the functionalities are on different
layers and hence, each layer can be tested and debugged separately.

Contd. ….
Advantages of Layered Architecture
• Dysfunction of one layer will not affect the entire operating system.
• Easier testing and debugging due to isolation among the layers.
• Adding new functionalities or removing the obsolete ones is very easy, etc.
Disadvantages of Layered Architecture
• It is not always possible to divide the functionalities, many a times they are inter-
related and cannot be separated.
• Sometimes, a large number of functionalities is there and number of layers increase
greatly. This might lead to degradation in performance of the system.
• No communication between the non-adjacent layers, etc.

Contd. ….
 Object Based Architecture

• This architectural style is based on the loosely coupled arrangement of objects. This has no specific
architecture like layers.
• Like in layers, this layer does not have a sequential set of steps that needs to be carried out for a
given call.
• Each of the components are referred to as objects, where each object can interact with other objects
through a given connector or interface.
• These components are much more direct where all the different components can interact directly
with other components through a direct method call.
• An image demonstrating the object based architecture is as follows:

Contd. ….
Fig: Object Based Architecture of Distributed System

Contd. ….
• We can clearly vibe about the communication between the objects as method invocations. These
are generally called Remote Procedure Calls (RPC).
• Some popular examples are Java RMI, Web Services and REST API Calls.
• This architectural style has the following properties:
 It is less structured.
 Component = Object.
 Connector = RPC or RMI(Remote Method Invocation).

Contd. ….
 Data Centred Architecture
• This architecture is based on a data center, where the primary communication happens via a central
data repository.
• This common repository can be either active or passive. This is more like a producer consumer
problem where the producer produces items to a common data store, and the customer can request
data from it.
• This common repository could even be simple database. But, the idea is that the communication
between the objects happens through this shared common storage.
• This architecture supports different components or objects by providing a persistent storage space
for those components such as MySQL database.
• Some popular examples are distributed file systems, producer consumer problem, and web based
data services.
• An image demonstrating the data centred architecture is as follows:

Contd. ….
Fig: Data Centred Architecture of Distributed System

Contd. ….
 Event Based Architecture

• In this architecture, the entire communication of a system happens through the events i.e. when an
event is generated, it will be sent to the bus system.
• With this approach, everyone else will be notified telling that such an event has occurred. So, if
anyone is interested, that node can pull the event from the bus and use it.
• Sometimes these events could be data, or even URLs to resources. So the receiver can access
whatever the information is given in the event and process accordingly.
• Processes communicate through the propagation of events and these events occasionally carry data.
• Some examples of this architecture are: publisher-subscriber system, Enterprise Service Bus (ESB)
and akka.io.
• An image demonstrating the event based architecture is as follows:

Contd. ….
Fig: Event Based Architecture of Distributed System

 Middleware Organization
• Most of the distributed systems in the present context lack the uniformity and consistency.
• One way distributed systems can achieve uniformity and consistency is through a common layer to
support the underlying hardware and operating systems.
• This common layer is known as middleware, where it provides services beyond what is already
provided by operating systems, to enable various features and components of a distributed system,
in order to enhance its functionality better.
• This layer provides a certain data structures and operations that allow processes and users to inter-
operate and work together in a consistent way.
• The image demonstrating middleware layer of distributed system is as follows:

Contd. ….
Fig: Middleware in Distributed System

Contd. ….
• In particular, there are two important types of design patterns that are often applied to the
organization of middleware:
 Wrappers / Adapters
 Interceptors
 Wrappers
• It is also known as Adapter.
• A wrapper or an adapter is a special component that offers an interface acceptable to a client
application, of which the functions are transformed into those available at the component.
• In short, it solves the problem of incompatible interfaces and plays a crucial role in achieving
openness which ultimately plays an important role in extending systems with existing components.

Contd. ….
 Interceptors
• An interceptor is nothing but a software construct that will break the usual flow of control and
allow other code to be executed.
• Interceptors are a primary means for adapting middleware to the specific needs of an application
and it too plays a vital role in achieving openness.
• The working principle of an interceptor can be best demonstrated through remote-object
invocation and let us demonstrate it as follows:
The basic idea is that an object A can call a method that belongs to an object B, while the latter
one resides on a different machine than A.
Now, a remote-object invocation is carried out in following three steps:

Contd. ….
• Object A is offered a local interface that is exactly the same as the interface offered by object B,
then A calls the method available in that interface.
• The call by A is transformed into a generic object invocation, made possible through a general
object-invocation interface offered by the middleware at the machine where A resides.
• Finally, the generic object invocation is transformed into a message that is sent through the
transport-level network interface as offered by A’s local operating system.

 System Architectures
• Deciding on software components, their interaction, and their placement leads to an instance of a
software architecture, also known as system architecture.
• The primary system architectures to be discussed are:
1. Centralized Organizations
 Client-Server Architecture
2. Decentralized Organizations
 Peer-to-Peer (P2P) Architecture
(Discuss Yourself)

Course Title:
Distributed System
(CACS 352)


Unit-3
Processes

 Introduction to Process
• A process is an instance of a program running in a computer. In other words, the running state of a
program is known as process.
• Moreover, a process is a sequential program in execution. It defines the fundamental unit of
computation for the computer.
• A process has a problem code, input, output and a state.
• A process is the unit of work in modern time-sharing OSs.
• Note that a process is more than a program. It includes the current activity as represented by the
value of program counter (PC) and the content of the processor register.
• Also remember that a process execution must progress in a sequential manner. The overall
operation of execution of a progress is monitored and maintained in a Process Control Block
(PCB).

Contd. ….
• The following figure shows a simplified layout of a process inside a main memory:
Stack
Heap
Data
Text
Fig: Layout of a process inside main memory

 Difference between a Process and a Program
Process Program
i. It is a sequence of instruction execution. i. It consists of a set of instructions in a
programming language.
ii. A process is a dynamic object. ii. A program is static in nature.
iii. A process is loaded into the main memory. iii. A program is loaded into the secondary storage
device.
iv. The time span of a process is limited, iv. The time span of a program is unlimited,
comparatively. comparatively.
v. The process is an active entity. v. The program is a passive entity.
vi. The resource requirement is much higher in vi. A program just requires memory for storage or
case of a process, etc. resource requirement is lower in comparison to a
process, etc.

 Process State/ Process Lifecycle
• When a process executes, it passes through different states. These states may differ in
different OSs, and the names of these states are also not standardized.
• The OS maintains management information about a process in PCB. Modern OS allows a
process to be divided into multiple threads of execution, which share all the process
management information except for information directly related to its execution. This
information is held in a Thread Control Block (TCB).
• Threads in a process can execute different parts of the program code at the same time.
• Threads can also execute the same parts of the code at the same time, but with
different execution state:
 They have independent current instructions i.e. they have independent program
counters.
 They are working with different data i.e. they are working with independent registers.

Contd. ….
• In general, a process can have one of the following five states at a time:
Fig: Process state diagram

Contd. ….
• The state diagram of a process in the above figure illustrates the five stages of a process
execution and they are discussed below:
I. Start
• This is the initial state when a process is created or first started.
II. Ready
• The ready state signifies that the process is writing to be assigned to a processor for the
execution.
III. Running
• The running state signifies that the process is actually using the CPU resources and the
instructions are being executed as per the working mechanism of OS scheduler.

Contd. ….
IV. Waiting or Blocked

• This state signifies that the process moves into the waiting state if it needs to wait for a
resource or for some events, such as waiting for user input, or waiting for a file to become
available.
V. Terminated or Exit
• This state signifies that the process has finished its execution.
• Once the process finishes its execution, or it us terminated by the OS, it is moved to the
terminated state where it waits to be removed from the main memory.

Contd. ….
 Suspended Process
 The prime characteristics of a suspended process are as follows:
• Suspended process is not immediately available for execution.
• The process may or may not be waiting on an event.
• For preventing the execution, process is suspended by OS, parent process, process itself and an
agent.
• Process may not be removed from the suspended state until the agent orders the removal.
Prime Reasons for Process Suspension
• Swapping
• Timing
• Interactive user request
• Parent process request

Contd. ….
Swapping
• Swapping is used to move all of a process from main memory to disk. OS needs to release
required main memory to bring in a process that is ready to execute.
Timing
• Process may be suspended while waiting for the next time interval.
Interactive user request
• Process may be suspended for debugging purpose by the user.
Parent process request
• Process may be suspended by the parent process to modify the suspended process or to co-
ordinate the activity of various descendants.

 Process Hierarchy
• The process of creating new process from their parent process and again creating new
process from previously newly created process in tree like structure is called process
hierarchy.
• Windows has no concept of process hierarchy.
• Modern general purpose operating systems permit a user to create and destroy processes. In
UNIX, this is done by the fork system call, which creates a child process, and the exit
system call, which terminates the current process.
• After a fork system call, both the parent and the child keep running and each can fork off
other processes.
• The root of the tree is a special process created by the OS during start-up.
• The following figure illustrates the concept of process hierarchy:

Contd. ….
Fig: Process Hierarchy

 Introduction to Thread
• A process is divided into small tasks and each task is called as a thread. A thread is a single
sequence stream within a process.
• Moreover, a thread is a flow of control within a process. Processes are used to group the
resources together, and threads are the entities scheduled for execution on the CPU.
• A thread uses a flow of execution through the process code with its own program counters,
register set, stack space and life cycle.
• A thread is similar to a sequential program i.e. like a process, a thread also has its
beginning and end. But a thread itself is not a running program because it cannot run on its
own. So, it runs within a running program.
• A thread is a light-weight process because it runs within a process and it makes the use of
the resources that were actually allocated to the process.
• In a process, threads allow multiple execution of the streams.

Contd. ….
• Threads are not independent of one another like processes, as a result, threads share with
other threads their code section, data section, and OS resources.
• Threads are very useful n modern programming because one of the tasks may block, and it
is desired to allow the other tasks to proceed without blocking.
• For example: In a word processor, a background thread may check spelling and grammar
while a foreground thread processes user inputs (keystrokes), while yet a third thread loads
images from the hard drive, and fourth does periodic automatic backups of the file being
edited during manipulation, and so on.
• In short, we regard the best outcome of the threads as the concept of “Multithreading”.

 General Properties of Threads
• Only one system call can create more than one thread (Lightweight Process).
• Threads share data and information.
• Threads have their own Program counter (PC), register set and stack space.
• Thread management consumes no or fewer system calls as the communication between
threads can be achieved using shared memory.
• The isolation property of the process increases its overhead in terms of resource
consumption criteria, etc.

 Similarities between a Thread and a Process
• Like processes, threads share CPU and only one thread is active (running) at a time.
• Like processes, threads within a process execute sequentially.
• Like processes, thread can create children.
• And, Like processes, if one thread is blocked, then another thread can run.

 Differences between a Thread and a Process
Thread Process
i. A thread can share memory and files. i. A process cannot share the same memory.
ii. Thread creation is not time consuming task. ii. Process creation is a time consuming task.
iii. Thread execution is fast comparatively. iii. Process execution is slow comparatively.
iv. It takes less time to terminate a thread. iv. It takes more time to terminate a process.
v. It takes less time to switch between two threads. v. It takes more time to switch between two processes.
vi. Threads are tightly coupled. vi. Processes are loosely coupled.
vii. Threads are the light-weight processes as they require vii. Processes are heavy-weight programs as they require
fewer resources for the execution. more resources for the execution.
viii. Communication between threads is easy and viii. Communication between processes is difficult and
efficient. complex.
ix. System calls are not required. ix. System calls are required for communication.
x. They are suitable for exploiting parallelism, etc. x. They are not suitable for exploiting parallelism, etc.

 Implementation of Thread/ Types of Thread
• Thread can be implemented in the following two ways:

 User-Level Threads.
 Kernel-Level Threads.
Now, they are discussed below:

Contd. ….
 User-Level Thread
• In a user-level thread, all of the task of thread management is done by the application i.e. in
the user space and kernel is not aware of the existence of thread.
• The thread library contains code for creating and destroying thread, for message passing
and sharing the data between the threads, for scheduling thread execution, and for saving
and restoring thread context-switching activities.
• The application (i.e. the work in the user space) begins with a single thread and starts
running that thread.
• Creating a thread, switching between threads, and synchronizing threads are done via
procedure calls i.e. no kernel involvement.
• User level threads are hundred times faster than kernel level threads.
• The following figure shows the structure of a user-level thread:

Contd. ….
User level threads
Fig: User-Level Thread

Contd. ….
Advantages of User -Level Thread

• User-level threads do not require modification to OSs.
• Each thread is simply represented by a PC, registers, stack and a small control block, all stored
in the user process address space.
• Threads are simply managed, which means that creating a thread, switching between threads
and synchronization between threads can all be done without intervention of the kernel.
• User-level threads are fast to create and efficient to manage i.e. thread switching is not much
more expensive than a procedure call, etc.
Disadvantages of User -Level Thread
• There is a lack of co-ordination and communication between threads and OS kernel.
• User-level threads require non-blocking system calls i.e. a multithreaded kernel. Otherwise,
entire process will be blocked in the kernel, even if there are runnable threads left in the
processes, etc.

Contd. ….
 Kernel -Level Thread

• In a kernel level thread, the work of thread management is done by the kernel. There is no
thread management code in the application area i.e. in the user space.
• Kernel level threads are directly supported by the OS. Any application can be programmed to
be multithreaded.
• All of the threads within an application are supported within a single process.
• The kernel maintains information center for the process as a whole and for individual threads
within the process.
• Thus, to cut it short, we can say that OS-managed threads are called kernel-level threads or
light-weight processes.
• The following figure shows the structure of a kernel-level thread:

Contd. ….
user space
space
Fig: Kernel-Level Thread

Contd. ….
Advantages of Kernel -Level Thread

• Kernel can simultaneously schedule multiple threads from the same process on multiple
processors.
• If one thread in a process is blocked, then the kernel can schedule another thread of the
same process.
• The kernel routine themselves can be multithreaded.
• Kernel level threads are specially good for applications that frequently block, etc.
Disadvantages of Kernel -Level Thread
• The kernel level threads are slow to create and inefficient to manage than the user level
threads as they are hundred times slower than the user-level threads.
• It requires a full thread control block (TCB) for each thread to maintain information about
threads. As a result, there is significant overhead and increased complexity in kernel, etc.

Contd. ….
Fig: User-level threads vs. Kernel-level threads

Contd. ….
User-level threads Kernel-level threads
Table: Summary of User-level vs. Kernel-level threads

 The Thread Model or The Concept of Multithreading
• The use of multiple threads in a single program all running at the same time and
performing different tasks is called multithreading.
• There are two types of threads to be managed in a modern system i.e. user threads and
kernel threads.
• All modern operating systems support kernel level threads, allowing the kernel to perform
multiple simultaneous tasks and/or to service multiple kernel system calls. This is called
the case of multi-threading.
• In a specific implementation, the user threads must be mapped to kernel threads, using
one of the following strategies or types or models of multithreading:
 Many-To-Many Model
 Many-To-One Model
 One-To-One Model

Contd. ….
 Many-To-Many Model
• In this model, many user level threads multiplex to the kernel level threads of smaller or
equal numbers.
• The number of kernel threads may be specific to either a particular application or a
particular machine.
• Users have no restrictions on the number of threads created. Also, blocking kernel system
calls do not block the entire process.
• In this model, users can create as many user threads as necessary and the corresponding
kernel threads can run in parallel on a multi-processor platform.
• The figure below shows the many-to-many model of multithreading:

Contd. ….
Fig: Many-To-Many Thread Model

Contd. ….
 Many-To-One Model
• Many-to-one model maps many user level threads to one kernel level thread.
• Thread management is done in user space. When the thread makes a blocking system call,
then the entire process will be blocked.
• Only one thread can access the kernel at a time, so multiple threads are unable to run in
parallel on multiple processors i.e. many-to-one model does not allow individual process to
be split across multiple CPUs.
• The below figure shows the many-to-one model of multithreading:

Contd. ….
Fig: Many-To-One Thread Model

Contd. ….
 One-To-One Model
• In this thread model, there is one to one relationship of user level threads to the kernel level
threads.
• This model provides more concurrency than the many-to-one model by allowing another
thread to run during blocking.
• This model also allows parallelism. The only overhead is for each thread, corresponding
kernel thread should be created.
• The below figure shows the one-to-one model of multithreading:

Contd. ….
Fig: One-To-One Thread Model

 Virtualization (The Concept of Virtual Machine)
• Virtualization creates a virtual version of a device or resource, such as server, storage device,
network or even an operating system where the framework divides the resource into one or
more execution environments.
• Virtual machine abstracts the hardware of our PC such as CPU, disk drivers, memory, Network
Interface Card (NIC), etc. into many different execution environments as per our requirements,
hence giving us a feel that each execution environment is a single computer. For example:
Virtual Box.
• Virtualization technology enables a single PC or server to simultaneously run multiple operating
systems or multiple sessions of a single OS.
• A machine with virtualization software can host numerous applications, including those that run
on different operating systems, on a single platform.
• The host OS can support a number of virtual machines, each of which has the characteristics of
a particular OS.
• The solution that enables virtualization is a virtual machine manager (VMM), or
hypervisor.
• Hypervisor is one of many hardware virtualization techniques that allows multiple operating
systems, termed guests, to run concurrently on a host computer.
Contd. ….
Fig: Virtual Machine Concept

Contd. ….
Types of Hypervisor
• There are two different types of hypervisor and they are as follows:
Type 1 hypervisor
• It directly runs on the physical hardware (usually a server), taking the place of the
operating system.
• Here, we typically use a separate software product to create and manipulate VMs on the
hypervisor.
Type 2 hypervisor
• It runs as an application within a host OS and usually targets a single-user desktop or
notebook platforms.
• With a Type 2 hypervisor, we manually create a VM and then install a guest OS in that
VM.

Contd. ….
Types of Virtualization
• There are generally following five types of virtualization:

 Desktop Virtualization
 Application Virtualization
 Server Virtualization
 Network Virtualization
 Storage Virtualization.
• Now, they are discussed below:

Contd. ….
1. Desktop Virtualization
• It is achieved when the host server can run virtual machines using a hypervisor.
• A hypervisor can directly be installed on the host machine or over the operating systems,
like, Windows, Mac, and Linux.
• Virtualized desktops don’t use the host system’s hard drive; instead, they run on a remote
central server.
• This type of virtualization is useful for the development and testing teams who need to
develop or test the applications on different operating systems.
• The figure illustrating the working mechanism of desktop virtualization is as follows:

Contd. ….
Fig: Desktop Virtualization

Contd. ….
2. Application Virtualization
• Application virtualization is the process of installing an application on a central server that
can virtually be operated on multiple systems.
• For end users, the virtualized application works exactly like a native application installed
on a physical machine.
• With application virtualization, admins can control and modify access permissions to the
application without logging into the user’s desktop.
• Another advantage of this virtualization is portability. It allows users to access virtualized
applications even on non-Windows devices, such as iOS or Android.
• The figure illustrating the working mechanism of application virtualization is as follows:

Contd. ….
Fig: Application Virtualization

Contd. ….
3. Server Virtualization
• Server virtualization is the process of partitioning the resources of a single server into
multiple virtual servers. These virtual servers can run as separate machines.
• Server virtualization allows businesses to run all the multiple independent OSs (guests or
virtual) with different configurations using a single (host) server.
• Server virtualization, thus saves the hardware costs involved in keeping a host of the
physical servers.
• The figure illustrating the working mechanism of server virtualization is as follows:

Contd. ….
Fig: Server Virtualization

Contd. ….
4. Network Virtualization
• Network virtualization helps to manage and monitor the entire computer network as a
single administrative entity.
• Admin can keep a track of various elements of network infrastructure such as routers and
switches from a single software-based administrator’s console.
• Network virtualization offers various advantages, such as, it reduces network provisioning
time from weeks to minutes, place and move workloads independently of physical
topology, improve network security within the data center, etc.
• The figure illustrating the working mechanism of network virtualization is as follows:

Contd. ….
Fig: Network Virtualization

Contd. ….
5. Storage Virtualization
• Storage virtualization is the process of pooling physical storage of multiple network storage
devices so it looks like a single storage device.
• Storage virtualization facilitates archiving, easy backup, and recovery tasks.
• Storage virtualization helps admins to allocate, move, change and setup resources
efficiently across the organizational infrastructures.
• The figure illustrating the working mechanism of storage virtualization is as follows:

Contd. ….
Fig: Storage Virtualization

Assignment-2
• Illustrate the advantages and disadvantages of Virtualization and discuss them in brief.

 Clients
• In the previous chapters, we discussed the client-server model, the roles of clients and
servers, and the ways they interact.
• Let us now take a closer look at the anatomy of clients and servers, respectively. We start in
this section with a discussion of clients. Servers are discussed in the next section.
 Networked User Interfaces
• A major task of client machines is to provide the means for users to interact with the
remote servers. There are roughly two ways in which this interaction can be supported.
• First, for each remote service, the client machine will have a separate counterpart that can
contact the service over the network.
• A typical example is a calendar running on a user’s smartphone that needs to synchronize
with a remote, possibly shared calendar.
• In this case, an application-level protocol will handle the synchronization, as shown in
the below figure:

Contd. ….
Fig: A networked application with its own protocol

Contd. ….
• A second solution is to provide direct access to remote services by only offering a
convenient user interface.
• Effectively, this means that the client machine is used only as a terminal with no need for
local storage, leading to an application-neutral solution as shown in the below figure:
Fig: A general solution to allow access to remote applications

Contd. ….
• This thin-client approach is receiving more attention as internet connectivity increases, and
handheld devices are becoming more sophisticated and it eases the task of the system
management effectively.
• Thus, in the case of networked user interfaces, everything is processed and stored at the
server level.
• Example of Thin-Client approach is the X Window System.
• Perhaps one of the oldest and still widely-used networked user interfaces is the X Window
System. The X Window System, generally referred to simply as X, is used to control bit
mapped terminals, which include a monitor, keyboard, and a pointing device such as a
mouse.
• In a sense, X can be viewed as that part of an operating system that controls the terminal.

Contd. ….
 Client-Side Software for Distribution Transparency
• Client software comprises more than just user interfaces. In many cases, parts of the processing
and data level in a client-server application are executed on the client side as well.
• A special class is formed by embedded client software, such as for Automated Teller Machines
(ATMs), cash registers, barcode readers, TV set-top boxes, etc.
• In these cases, the user interface is a relatively a small part of the client software, in contrast to
the local processing and communication facilities.
• Besides the user interface and other application-related software, client software comprises
components for achieving distribution transparency.
• Access transparency is generally handled through the generation of a client stub from an
interface definition of what the server has to offer. The stub provides the same interface as
available at the server, but hides the possible differences in machine architectures, as well as
the actual communication.

Contd. ….
• There are different ways to handle location, migration, and relocation transparency. Using a
convenient naming system is crucial, which we shall discuss later.
• In similar way, many distributed systems implement replication transparency by means of
client-side solutions.
• For example, imagine a distributed system with replicated servers; such replication can be
achieved by forwarding a request to each replica as shown in the below figure:
Fig: Transparent replication of a server using a client-side solution

Contd. ….
• Client-side software can transparently collect all responses and pass a single response to
the client application.
• Finally, consider failure transparency. Masking communication failures with a server is
typically done through client middleware.
• For example: client middleware can be configured to repeatedly attempt to connect to a
server, or perhaps try another server after several attempts.
• There are even situations in which the client middleware returns data it had cached during a
previous session, as is sometimes done by web browsers that fail to connect to a server.
• Concurrency transparency can be handled through special intermediate servers, notably
transaction monitors, and requires less support from client software. Likewise, persistence
transparency is often completely handled at the server.

 Servers
• A server is a piece of computer hardware or software that provides functionality for other
programs or devices, called clients. This architecture is called client-server model.
• Servers can provide various functionalities, often called services, such as sharing data or
resources among multiple clients, or performing computation for a client.
• Let us now take a closer look at the organization of servers. In the following section, we
first concentrate a number of general design issues for servers, followed by a discussion of
server clusters.
 General Design Issues for Servers in Distributed System
• A server is a process implementing a specific service on behalf of a collection of clients.
• In essence, each server is organized in the same way: it waits for an incoming request from
a client and subsequently ensures that the request is taken care of, after which it waits for
the next incoming request.

Contd. ….
1. Iterative versus Concurrent Servers
• There are several types of sever design choices to organize servers and among them, the
following two are more commonly used:
 Iterative Server
• The server itself handles the request and, if necessary, returns a response to the requesting
client.
• It is a single-threaded server which processes the requests in a queue. Essentially, requests are
not executed in parallel at any time on the server.
 Concurrent Server
• It does not handle the request itself, but passes it to a separate thread or another process, after
which it immediately waits for the next incoming request.
• A multithreaded server is an example of a concurrent server. An alternative implementation of a
concurrent server is to fork a new process for each new incoming request. This approach is
followed in many UNIX systems.
• The thread or process that handles the request is responsible for returning a response to the
requesting client.
Contd. ….
2. Contacting a Server; end points
• Another issue is where the clients contact a server. In all the cases, 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?
• One approach is to globally assign end points for well-known services. For example: servers that
handle internet FTP requests always listen to TCP port 21. Likewise, an HTTP server for the
WWW will always listen to TCP port 80.
• These end points have been assigned by the Internet Assigned Numbers Authority (IANA). With
the assigned end points, the clients only need to find the network address of the machine where
the server is running.
• There are many services that do not require a pre-assigned end point. One solution is to have a
special daemon running on each machine that runs servers.
• The daemon keeps tracks 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 contacts the specific server, as shown in the below figure:

Contd. ….
Fig: Client-to-Server binding using a daemon

Contd. ….
3. Interrupting a Server
• Another issue that needs to be taken into account when designing a server is whether and how a server
can be interrupted.
• For example: consider a user who has just decided to upload a huge file to a FTP server. Then,
suddenly realizing that it is the wrong file, he wants to interrupt the server to cancel further data
transmission.
• There are several ways to do this. One approach that works only too well in the current internet is for
the user abruptly exit the client application, immediately restart it, and pretend nothing happened. The
server will eventually tear down the old connection, thinking the client has probably crashed.
• A much better approach for handling communication interrupts is to develop the client and server such
that it is possible to send out-of-band data, which data that is to be processed by the server before any
other data from that client.
• One solution is to let the server listen to a separate control end point to which the client sends out-of-
band data, while at the same time listening to the end point through which the normal data passes.
• Another solution is to send out-of-band data across the same connection through which the client is
sending the original request.
Contd. ….
4. Stateless versus Stateful Servers
• A final, important design issue, is whether or not the server is stateless.
 Stateful Servers
• They keep a state of their connected clients. For example, push servers are Stateful servers since the
server needs to know the list of clients it needs to send messages to.
 Stateless Servers
• A stateless server does not keep information on the state of its clients, and can change its own state
without having to inform any client.
• A web server, for example, is stateless. It merely responds to incoming HTTP requests, which can either
be for uploading a file to the server or for fetching a file.
• When the request has been processed, the web server forgets the client completely. Likewise, the
collection of files that a web server manages, can be changed without clients having to be informed.
• Pull servers are the examples of stateless servers where the clients send requests to the servers when
required.
• The advantage of stateless servers are that the server crash will not impact clients – more resilient to
failures, its also more scalable, since clients take some workloads.

Contd. ….
Differences between Stateful and Stateless Servers

Contd. ….
 Object Servers
• An object server is a server tailored to support distributed objects. The important difference
between a general object server and other servers is that an object server by itself does not
provide a specific service.
• Specific services are implemented by the objects that reside in the server. Essentially, the server
provides only the means to invoke local objects, based on requests from remote clients. As a
consequence, it is relatively easy to change services by simply adding and removing objects.
• An object server thus acts as a place where objects live. An object consists of two parts: data
representing its state and the code for executing its methods.
• Whether or not these parts are separated, or whether method implementations are shared by
multiple objects, depends on the object server.
• Also, there are differences in the way an object server invokes its objects. For example, in a
multithreaded server, each object may be assigned a separate thread, or a separate thread may be
used for each invocation request.

Contd. ….
Fig: Organization of an object server supporting different activation policies

 Code Migration
• Code migration is the broadest sense that deals with moving programs between machines, with
the intention to have those programs be executed at the target.
• In some cases, as in process migration, the execution status of a program, pending signals, and
other parts of the environment must be moved as well.
Reasons for Migrating Code
• Traditionally, code migration in distributed systems took place in the form of process migration
in which an entire process was moved from one machine to another.
• Moving a running process to a different machine is a costly and complicated task, and there had
better be a good reason for doing so. That reason has always been performance.
• The basic idea is that overall system performance can be improved if processes are moved from
the heavily-loaded to lightly-loaded machines.
• Load is often expressed in terms of the CPU length or CPU utilization, but other performance
indicators are used as well.
• Load distribution algorithms by which decisions are made concerning the allocation and
redistribution of tasks with respect to a set of processors, play an important role in compute-
intensive systems. Moreover, due to the heterogeneity of the underlying platforms and computer
networks, performance improvement through code migration is achieved.
Contd. ….
Fig: The principle of dynamically configuring a client to communicate with a server

Course Title:
Distributed System
(CACS 352)

Compiled by Ujjwal Rijal ||

1 rijalujjwal09@gmail.com
Unit-4
Communication
 Introduction to Communication
 Inter-process communication is at the heart of all distributed systems. It makes no sense
to study distributed systems without carefully examining the ways that processes on
different machines can exchange information.
 Communication in distributed systems is always based on low-level message passing as
offered by the underlying network.
 Here, about the communication in distributed systems, at first, we discuss about the
rules that communicating processes must stand up to, known as protocols.
 Then, after this, we discuss about three widely-used models for communication:
Remote Procedure Call (RPC), Message-Oriented Middleware (MOM) offered by
transport layer as part of middleware solution, and data streaming.
 And finally, we discuss about the general problem of sending data to the multiple
receivers, called the multicasting communication.

Contd. ….
 Communication in Distributed Systems based on low

level message passing offered by underlying network
 Three popular models of communication:

 Remote Procedure Calls (RPC)
 Message-oriented Middleware (MOM)
 Data Streaming
 Sending data to multiple receivers or Multicasting

Contd. ….
 Focus of this presentation is Interprocess Communication. Interprocess

Communication is part of the Client/Server Computing Model
 A client is an application or a process that requests a service from some other
application or process.
 A server is an application or a process that responds to a client request.
 Both client/server applications perform specialized functions in a distributed
computing environment.
 Intraprocess communication used between homogeneous systems. Example :
using named pipes, named queues, shared memory etc.

Contd. ….
 In between the end users and large pool of computing

resources, many applications act as both a client and a
server, depending on the situation.
 Interprocess communication is necessary to communicate

between heterogeneous systems.

 Fundamentals of Communication
 Layered Protocols
 Middleware Protocols

Contd. ….
 Two main types of Protocols:
 Protocols govern the format, contents and meaning of messages.

 Connection-oriented: Sender and receiver establish a
connection and negotiate the protocol to use before exchanging
data. At the end of communication, terminate or release the
connection. An example:TCP
 Connectionless: No connection is set up in advance. Sender

transmits message when ready. An example: UDP

Contd. ….
Main differences between connection-
oriented and connectionless protocols
1. Connection-oriented is reliable, while the other is not.
2. Connection-oriented is fully duplex.
3. Connection-oriented is byte-stream service with no
structure.
4. Error checking an essential component of unreliable
connectionless protocol.
5. Connectionless protocol transfers packets of data and uses
a protocol port address to specify receiver process, etc.
Contd. ….
Fig: Layers, Interfaces, and Protocols in OSI Model

Contd. ….
 Lower-Level Protocols
 Implemented in physical layer and data link layer of the stack. Groups data bits
into frames and adds a pattern called checksum at either end of frame
 Network layer chooses best path from sender to receiver by routing
 Transport Protocols
• TCP
• UDP
 Higher Level Protocols
• FTP
• HTTP

 Middleware Protocols
 Examples are Authentication and Authorization protocols,
commit protocols in transaction databases
 Middleware protocols support high level communication
services
• Protocols that allow a process to call a procedure or invoke an
object on a remote machine transparently. An example RPC/RMI
• Protocols that support the setting up and synchronizing of streams
for transferring real-time data such as multimedia applications. An
example: SCTP
• Protocols that support reliable multicast services to aWAN

Contd. ….
Fig: An adapted reference model for networked communication

Contd. ….
 Types of Communication
• Persistent communication: Message submitted for transmission stored
by communication middleware as long as it takes to deliver it to the receiver.
Neither sending application nor receiving application need to be executing.
• Transient communication: Message stored by communication system
only as long as sending and receiving application are executing.
• Asynchronous communication: Sender continues immediately after
submitting message for transmission. Message temporarily stored by
middleware on submission.
• Synchronous communication: Sender blocks until message received and
processed, and receiver returns acknowledgement.

 Remote Procedure Call (RPC)
 Remote procedure calls can simplify the way IPCs are conducted
through the network.
 Client applications use the client side network API to call RPCs.
 Server side of the network API turns the RPCs into local function calls.
 Return value being transmitted back to the client application again
through the network.
 The OSI layers are transparent to the client application, as if it is making
a local function call.
 The RPC provided by Windows enable applications that use RPC to
communicate with applications running with other operating systems
that support DCE (Distributed Computing Environment). RPC
automatically supports data conversion to account for different
hardware architectures and for byte-ordering between dissimilar
environments.

Contd. ….
 Synchronous RPC Operation:

 Process on machine A calls procedure on machine B, the calling process
on A is suspended and execution of the called procedure takes place on B.
 Information is transported from caller to callee in the parameters and
comes back in the procedure result.
 No message passing visible to programmer.
 Client and Server stubs are used.
 Client stub takes its parameters and packs them into a message (parameter
marshalling) and sends them to the server stub.

Contd. ….
Parameter Passing
 Passing Value Parameters
• Client stub takes parameters and puts them in the message. It also puts
the name or number of the procedure to be called in the message
• When message arrives at server, server stub examines the message to
see which procedure is needed and then makes appropriate call. Stub
takes the result and packs it into a message. Message is sent back to
client stub.
• Client stub unpacks the message to extract the result and returns it to
waiting client procedure

Contd. ….
 Passing Reference Parameters

• Pointers and references passed by copying the data structure such as
array into message and sent to server
• Server stub calls server with a pointer to this array
• Server makes changes using this pointer that also affects the message
buffer inside server stub
• Server finishes its work, original message sent back to client stub
which copies it back to the client.This is similar to copy/restore.

Contd. ….
 Asynchronous RPC
 Client continues immediately after issuing RPC request and receiving
acknowledgement from server, it is not blocked.
 Server sends immediately a reply or acknowledgement to the client the
moment RPC request is received
 Server then calls requested procedure
 One-way RPC: Client does not wait for even an acknowledgement from
server. Reliability not guaranteed as client has no acknowledgement from
server.
 Deferred synchronous RPC: It is a combination of two asynchronous
RPCs, where client polls the server periodically to see whether results are
available yet rather than server calling back the client.
 Message-Oriented Communication
 RPC assumes that receiver process is executing at the time a request is

issued
 Message-oriented communication such as message-queuing systems is

therefore needed to allow processes to exchange information even if
one party is not executing at the time the communication is initiated.
 Message-oriented-model (MOM) offered by transport layer, as part of

middleware solution

Contd. ….
 Berkeley Sockets
 Sockets interface introduced in 1970s in Berkeley Unix
 Standardizes the interface of the transport layer to allow programmers the use of messaging
protocols through simple set of primitives
 Another interface XTI stands for X/Open Transport Interface, also formerly called Transport
Layer Interface (TLI) developed by AT&T
 Sockets and XTI similar in their model of network programming but differ in their set of
primitives
 Socket forms an abstraction over the communication end point to which an application can write
data that are sent over the underlying network and from which incoming data can be read.
 Servers execute the first four primitives in table
 When calling the socket primitive, the caller creates a new communication end point for a specific
transport protocol. Internally, the OS reserves resources to accommodate sending and receiving
messages for the specific protocol.

Contd. ….
• Bind primitive associates a local address with a newly-created socket. For example, server should
bind the IP address of its machine together with a known port # to a socket
• Binding tells the OS that the server wants to receive messages only on the specified address and
port
• Listen primitive is called only in the case of connection-oriented communication. It is a
nonblocking call that allows the local OS to reserve enough buffers for a specified # of
connections that the caller is willing to accept
• A call to accept primitive blocks the caller until a connection request arrives. When the request
arrives, the local OS creates a new socket with same properties as the original one and returns it to
caller. Server can wait for another connection request on the original socket
• Connect primitive on client requires that the caller specifies the transport level address to which a
connection request is to be sent
• Client is blocked until a connection is set up, after which info can be exchanged using
send/receive
• Closing the connection is symmetric as both server and client call the close primitive

Contd. ….
Primitive Meaning
Socket Create a new communication end point
Bind Attach a local address to a socket
Listen Announce willingness to accept

connections
Accept Block caller until connection request
arrives
Connect Actively attempt to establish a connection
Send Send some data over the connection
Receive Receive some data over the connection
Close Release the connection

Contd. ….
 Message-Oriented Persistent Communication
 Message Oriented Middleware(MOM) or message queuing systems

provide support for persistent asynchronous communication
 Intermediate-term storage capacity for messages. Does not require

sender/receiver to be active during message transmission
 Slower than Berkeley sockets and MPI

Contd. ….
 Message-Queuing Model
 Applications communicate by inserting messages in specific queues
 Messages are forwarded over a series of communication servers and

delivered to the destination, even if it was down when message was
sent
 Each application has its own private queue to which other applications
can send messages

Contd. ….
 Sender is informed that the message will be eventually

inserted in the receiver’s queue. No time is specified.
 Neither sender nor receiver need to be executing when

message is placed in the queue
 Loosely coupled communication with sender and receiver

executing independent of each other.

Contd. ….
Primitive Meaning
Put Append a message to a specified queue. A

nonblocking call by sender.
Get Block until specified queue is non-empty and

remove the first message
Poll Check a specified queue for messages and

remove the first. Never block.
Notify Install a handler as a callback function to be

called when a message is put into a specified
queue

Contd. ….
 Architecture of Message Queuing System

 Source queue to put message is local to sender
 Message can be read only from local queue
 Message put into a queue will contain the specification of a destination

queue to which it should be transferred
 Message queuing system responsible to provide the queues to

sender/receiver and transfer messages from source to destination queue.

Contd. ….
 Message queuing system maintains mapping of queues

distributed across multiple machines to network locations –
a distributed database of queue names to network locations,
similar to DNS.
 Queues managed by Queue Managers, who interact with the

application that is sending or receiving a message. Special
queue managers operate as routers/relays that forward
incoming messages to other queue managers

Contd. ….
 Message-queuing system may grow into a complete

application level overlay network on top of existing
computer network
 Relays/routers help build scalable messaging systems
 Relays allow secondary processing of messages, for example,
a message may need to be logged for reasons of fault
tolerance or security
 Relays can be used for multicasting purposes. Incoming
message put into each send queue.

 E-mail Systems
• E-mail systems use underlying transport services. Example, mail
protocol for the Internet-SMTP, a message is transferred by
setting up a direct TCP connection to the destination mail server.
Generally no routing is used.
• Provide direct support for end users when compared to message-
queuing system
• E-mail systems have specific requirements such as automatic
message filtering, support for advanced messaging databases to
retrieve old messages etc
• Message queuing system enables persistent communication
between processes.Wide range of applications including e-mail.

 Multicast Communication
 Sending data to multiple receivers
 Explicit communication paths set up could be at Application

Level for peer-to-peer solutions
 Without explicit communication paths, gossip based

information dissemination provides simple but less efficient
way to implement multicasting.

Contd. ….
 Application of level multicasting

 Nodes organize into an overlay network that is used to disseminate
information to its members
 Network routers not involved in group membership
 Overlay network could be organized into a tree or a mesh network.

Former provides a unique overlay path between every pair of nodes,
while latter has each node connected to multiple neighbors – higher
robustness in the event a connection breaks

Contd. ….
 Multicast Session
 Node generates a multicast identifier mid (randomly chosen 160 bit key). It then
looks up succ(mid) that is the node responsible for this key and promotes it to
become the root of the multicast tree that is used to send data to interested
nodes
 To join the tree, a node P executes operation LOOKUP(mid) that allows a
lookup message with request to join the multicast group mid to be routed from P
to succ(mid).
 On the way up to the root, join request will add forwarder nodes or helpers for
the group
 Multicasting implemented by a node sending a multicast message towards the
root by executing LOOKUP(mid) after which message can be sent along the tree.

 Case Study: Java RMI
 In computing, the Java Remote Method Invocation (RMI) is a Java
API that performs remote method invocation, the object-oriented
equivalent of remote procedure call (RPC), with support for direct
transfer of serialized Java classes and distributed garbage-collection.
 In other words, Java RMI is a mechanism that allows an object
residing in one system (JVM) to access/ invoke an object running on
another JavaVirtual Machine (JVM).
 RMI is used to build distributed applications; it provides remote
communication between Java programs. It is provided in the
package java.rmi.

Contd. ….
 Goals of RMI
 Following are the goals of RMI:
 To minimize the complexity of the application.
 To preserve type safety.
 Distributed garbage collection.
 Minimize the difference between working with local and remote
objects, etc.

Contd. ….
 Architecture of an RMI Application
 In an RMI application, we write two programs, a server
program (resides on the server) and a client program (resides on
the client).
 Inside the server program, a remote object is created and reference
of that object is made available for the client (using the registry).
 The client program requests the remote objects on the server and
tries to invoke its methods.
 The following diagram shows the architecture of an RMI
application:

Contd. ….
Fig: Architecture of RMI Application

Contd. ….
 Let us now discuss the components of this architecture.
 Transport Layer: This layer connects the client and the server. It
manages the existing connection and also sets up new connections.
 Stub: A stub is a representation (proxy) of the remote object at
client. It resides in the client system; it acts as a gateway for the
client program.
 Skeleton: This is the object which resides on the server side.
Stub communicates with this skeleton to pass request to the remote
object.
 RRL (Remote Reference Layer): It is the layer which manages
the references made by the client to the remote object.
Contd. ….
 Working of an RMI Application
 The following points summarize how an RMI application
works:
 When the client makes a call to the remote object, it is received by the
stub which eventually passes this request to the RRL.
 When the client-side RRL receives the request, it invokes a method
called invoke() of the object remoteRef. It passes the request to the
RRL on the server side.
 The RRL on the server side passes the request to the Skeleton (proxy
on the server) which finally invokes the required object on the server.
 The result is passed all the way back to the client.

Contd. ….
 To write an RMI Java application, one would have to follow
the steps given below:
 Define the remote interface.
 Develop the implementation class (remote object).
 Develop the server program.
 Develop the client program.
 Compile the application.
 Execute the application.

Contd. ….
 Marshalling and Unmarshalling
 Whenever a client invokes a method that accepts parameters on a
remote object, the parameters are bundled into a message before
being sent over the network. These parameters may be of primitive
type or objects. In case of primitive type, the parameters are put
together and a header is attached to it. In case the parameters are
objects, then they are serialized. This process is known
as Marshalling.
 At the server side, the packed parameters are unbundled and then
the required method is invoked. This process is known
as Unmarshalling.
Contd. ….
 RMI Registry
 RMI registry is a namespace on which all server objects are placed.
Each time the server creates an object, it registers this object with
the RMIregistry (using bind() or reBind() methods). These are
registered using a unique name known as bind name.
 To invoke a remote object, the client needs a reference of that object.
At that time, the client fetches the object from the registry using its
bind name (using lookup() method).
 The following illustration explains the entire process of
RMI registry:

Contd. ….
Fig: Process of Working Mechanism of RMI Registry

 Case Study: Message-Passing Interface (MPI)
 A standard defined for message passing
 Hardware and platform independent
 Designed for parallel applications and transient

communication.
 Makes use of underlying network

Contd. ….
• Assumes that serious failures such as process crashes or network partitions are
fatal and do not require automatic recovery
• MPI assumes communication takes place within a known group of processes
• Each group is assigned an identifier
• Each process within a group is also assigned a local identifier
• A (groupID, processID) pair uniquely identifies the source or destination of a
message, and is used instead of a transport-level address
• Several possibly overlapping groups of processes involved in a computation,
executing at the same time
• MPI has messaging primitives to support transient communication shown in
next table

Contd. ….
Primitive Meaning
MPI_bsend Append outgoing message to a local send
buffer
MPI_send Send a message and wait until copied to local
or remote buffer
MPI_ssend Send a message and wait until receipt starts
MPI_sendrecv Send a message and wait for reply
MPI_isend Pass reference to outgoing message, and
continue
MPI_issend Pass reference to outgoing message, and
wait until receipt starts
MPI_recv Receive a message; block if there is none
MPI_irecv Check if there is an incoming message, but

do not block
Contd. ….
• Transient asynchronous communication is supported by MPI_bsend primitive
• Sender submits a message for transmission which is copied to a local buffer in MPI
runtime system. Sender continues after message is copied. Local MPI runtime system
will remove the message from its local buffer and transmit as soon as a receiver has
called a receive primitive
• MPI_send is a blocking send operation with implementation dependent semantics
• It may either block the caller until the specified message has been copied to the MPI
runtime system at the sender’s side, or until the receiver has initiated a receive
operation
• MPI_ssend implements synchronous communication by which the sender blocks until
its request is accepted for further processing
• MPI_sendrecv when called by sender, sends a request to the receiver and blocks until
the latter returns a reply.This corresponds to normal RPC.
Contd. ….
• MPI_isend allows the sender to pass a pointer to the message and

the MPI runtime system takes care of the communication. Sender
continues.
• MPI_issend allows the sender to pass a pointer to MPI runtime
system. When runtime system indicates it has processed the
message, sender knows that receiver has accepted the message.
• Caller is blocked until message arrives when MPI_recv is called
to receive a message
• Asynchronous variant MPI_irecv called by receiver indicates it is
prepared to accept message

 Conclusion
In this presentation, following topics were discussed:
 Three popular models of communication in distributed
systems:
 Remote Procedure Calls (RPC)

 Message-oriented Middleware (MOM)
 Data Streaming
 Sending data to multiple receivers or Multicasting.

Course Title:
Distributed System
(CACS 352)


Unit-5
Naming
 Name, Identifiers and Addresses
 Names are used to share resources, to uniquely identify entities, to refer to locations,
and more.
 A name in a distributed system is a string of bits or characters that is used to refer to an
entity. An entity in a distributed system can be practically any resource such as hosts,
printers, disks, files, processes, users, mailboxes, newsgroups, web pages, graphical
windows, messages, network connections, and so on.
 To operate an entity, it needs to be accessed from an access point, which is also called
an address. For example, to print a file, we need to access it at an access point.
 An address is thus just a special kind of name: it refers to an access point of an entity. A
name for an entity that is independent of an address is referred to as Location
independent.
 Identifier is a reference to an entity that is often unique and never reused.

Contd. ….
 The properties of true identifier are as follows:
 An identifier refers to at most one entity.
 Each entity is referred to by at most one identifier.
 An identifier always refers to the same entity.
 In many computer systems, addresses and identifiers are represented in
machine-readable form only, i.e. in the form of bit strings.
 For example: an Ethernet address is essentially a random string of 48 bits.
Likewise, memory addresses are typically represented as 32-bit or 64-bit
strings.
 Naming system maintains a name-to-address binding to resolve name (or
identifier) to address.

 Features of a Good Naming System
 Location transparency
 It means that the name of an object should not reveal any hint as to the physical location
of the object i.e. an object’s name should be independent of the physical connectivity or
topology of the system, or the current location of the object.
 Location independency
 The requirement of the location independency calls for a global naming
facility with the following features:
o An object at any node can be accessed without the knowledge of its physical location.
o An object at any node can issue an access request without the knowledge of its own
physical location. This property is also known as user mobility.
 Replication transparency
 A naming system should support the use of multiple copies of the same object in a user-
transparent manner i.e. if not necessary, a user should not be aware that multiple copies
of an object are in use.
Contd. …
 Scalability
 A naming system must be capable of adapting to the dynamically changing
scale of a distributed system that normally leads to a change in size of the
name space i.e. a change in the system scale should not require any change in
the naming or locating mechanisms.
 Uniform naming convention
 Instead of using non-uniform naming conventions, a good naming system
should use the same naming convention for all types of objects in the system.
 Multiple user-defined names for the same object
 A naming system must provide the flexibility to assign multiple user-defined
names to the same object.
 In this case, it should be possible for a user to change or delete his or her
name for the object without affecting those of other users.

Contd. …
 Group naming
 A naming system should allow many different objects to be identified by the same
name. Such a facility is useful to support broadcast facility or to group objects for
conferencing or other applications.
 Meaning names
 A good naming system should support at least two levels of object identifiers,
one convenient for human users and another convenient for machines.
 Performance
 A naming system should be efficient in the sense that the number of messages
exchanged in a name-mapping operation should be as small as possible.
 Fault-tolerance
 A naming system should be capable of tolerating, to some extent, faults that
occur due to the failure of a node or a communication link in a distributed system
network i.e. the naming system should continue functioning, perhaps in a
degraded form, in the event of these failures.
 Types of Naming System
 The types of naming systems are as follows:
 Flat naming: Resolves identifiers to addresses.
 Structured naming: Resolves structured human-friendly names to
addresses.
 Attributed-based naming: Resolves descriptive names to addresses.

 Structured Naming
 Flat names are good for machines, but are generally not very convenient
for humans to use. As an alternative, naming systems generally support
structured names that are composed from simple, human-readable names.
 Not only the file naming, but also host naming on the internet follows this
approach of structured naming.
 Name spaces
 Names are commonly organized into what is called a name space. Name
spaces for structured names can be represented as a labelled, directed graph
with two types of nodes (leaf node and directory node):
 Leaf node: It represents a named entity and has the property that it has no
outgoing edges.
 A leaf node generally stores information on the entity it is representing, for
example, it address – so that a client can access it.
Contd. ….
 Directory node: It has a number of outgoing edges, each labelled with a
name, as shown in the below figure.
 Each node in a naming graph is considered as another entity in a distributed
system, and in particular, has an associated identifier.
 A directory node stores a table called directory table in which an outgoing
edge is represented as a pair (node identifier, edge label).
o The naming graph shown in the below figure has one root node, namely n0,
which has only outgoing but no incoming edges.
o Each path in a naming graph can be referred to by the sequence of labels
corresponding to the edges in that path, such as N:[label1, label2, …., labeln],
where N refers to the first node in the path. Such a sequence is called a
path name.
o If the first node in a path name is the root of the naming graph, then it is called
an absolute path name. Otherwise, it is called a relative path name.

Contd. ….
Fig: A general naming graph with a single root node (directed acyclic graph)

Contd. ….
o It is important to realize that names are always organized in a name space.
o A global name is a name that denotes the same entity, no matter where that
name is used in a system.
o In other words, a global name is always interpreted with respect to the same
directory node.
o A local name is a name whose interpretation depends on where that name is
being used.
o Put differently, a local name is essentially a relative name whose directory in
which it is contained (implicitly) is known.
o A path name in file systems is generally represented as a single string in
which the labels are separated by a special separator character slash “/”. This
character is also used to indicate whether a path name is absolute or not.
o For example, in the above figure, instead of using n0:[home, steen, mbox],
i.e. the actual path name is /home/steen/mbox.

Contd. ….
o Note also that when there are several paths that lead to the same node, that
node can be represented by different path names.
o For example, node n5 in the above figure can be referred to by
/home/steen/keys (absolute path) as well as /keys (relative path to
/home/steen).
 Name Resolution
 Name spaces offer a convenient mechanism for storing and retrieving
information about entities by means of names.
 A path name should be possible to look up any information stored in the node
referred to by that name.
 Hence, the process of looking up a name is called the name
resolution.

Contd. ….
 Closure mechanism
 Name resolution can take place only if we know how and where to start.
 In the figure of previous example, the starting node was given, and we assumed we
had access to its directory table.
 Knowing how and where to start name resolution is generally referred to as a
closure mechanism.
 Linking and Mounting
 An alias or link is another name for the same entity. An environment variable
is an example of an alias.
 The directory node storing the node identifier is called a mount point.
Accordingly, the directory node in the foreign name space is called a mounting
point.
 Normally, the mounting point is the root of a name space.
 During name resolution, the mounting point is looked up and resolution proceeds
by accessing its directory table.

Contd. ….
 Implementation of a Name space
 A name space forms the heart of a naming service i.e. a service that allows
users and processes to add, remove, and look up names.
 A naming service is implemented by name servers. If a distributed system is
restricted to a local-area network, it is often feasible to implement a naming
service by means of only a single name server.
 However, in large-scale distributed systems with many entities, possibly
spread across a large geographical area, it is necessary to distribute the
implementation of a name space over multiple name servers.
o Name space distribution
 To effectively implement a name space hierarchically, it is
convenient to partition it into logical layers and they are as follows:
 Global layer, Administrational layer, and Managerial layer.
Contd. ….
 Global layer
 It is formed by highest-level nodes i.e. the root node and other directory
nodes logically close to the root called children. For example:
organizations, group of organizations.
 Administrational layer
 This layer is formed by directory nodes that are managed together within a
single organization.
 It represents the group of entities that belong to the same organization or
administrational unit. For example: there may be a directory node for each
department in an organization.
 Managerial layer
 It consists of nodes that may typically change regularly. For example: nodes
representing hosts in the local network.
 This layer includes nodes representing shared files, user-defined directories
and files.
Contd. ….
Fig: Example of Partitioning of the DNS name space into three logical layers
Contd. ….
 Implementation of Name resolution
 The distribution of a name space across multiple name servers affects the
implementation of name resolution.
 Let us assume that name servers are not replicated and that no client-side
caches are used. Each client has access to a local name resolver, which is
responsible for ensuring that the name resolution process is carried out.
 There are two ways to implement name resolution and they are:
 Iterative name resolution
 Recursive name resolution

Contd. ….
Fig: Principle of iterative name resolution

Contd. ….
Fig: Principle of recursive name resolution

Contd. ….
 Example:The Domain Name System (DNS)
 DNS is a global system for translating IP addresses to human-readable domain
names. The DNS server takes the hostname and resolves it into a numeric IP
address, which then web browser can connect to.
Fig: Purpose of DNS

Contd. ….
 The following six steps map the hostname to an IP address:
 The user passes the hostname to the file transfer client.
 The file transfer client passes the hostname to the DNS client.
 Each computer, after being booted, knows the address of one DNS server. The
DNS client sends a message to a DNS server with a query that gives the file
transfer server name using the known IP address of the DNS server.
 The DNS server responds with the IP address of the desired file transfer
server.
 The DNS server passes the IP address to the file transfer client.
 The file transfer client now uses the received IP address to access the file
transfer server.

Contd. ….
Fig: Example of using DNS service

Contd. ….
 Types of Name space
 To be unambiguous, the names assigned to machines must be carefully
selected from a name space with complete control over the binding between
the names and IP addresses.
 A name space that maps each address to a unique name can be
organized in two ways:
 Flat name space
 Hierarchical name space

Contd. ….
 Flat Name space
 It is a name assigned to an address and is a sequence of characters without
structure.
 The main disadvantage of a flat name space is that it cannot be used in a large
system such as the Internet because it must be centrally controlled to avoid
ambiguity and duplication.
 Hierarchical Name space
 A hierarchical name space is divided into different areas, which can be
thought of as sub-namespaces.
 Each area is its own sub-namespace within the overall namespace.
 Therefore, each object must have a unique name only within its sub-
namespace in order to have an unambiguously resolvable name within the
namespace hierarchy.
Contd. ….
 Domain Name space
 To have a hierarchical name space, a domain name space was designed.
 In this design, the names are defined in an inverted-tree structure with the
root at the top.The tree can have only 128 levels: level 0 (root) to level 127.
Compiled by Ujjwal Rijal || Fig: Domain Name Space

Contd. ….
 Label
 Each node in the tree has a label, which is a string (63 characters maximum).
The root label is a null string (empty string).
 DNS requires that children of a node which have different labels to ensure
uniqueness of the domain names.
 Domain Name
 A full domain name is a sequence of labels separated by dots (.).
 Domain names are always read from the Node to the Root.
 If a label is terminated by a null string, then it is called a fully
qualified domain name (FQDN).
 The FQDN must end with a null label but because null means nothing, the
label ends with a dot(.). For example, the domain name is the FQDN of a
computer named host1 installed at the BCA department of TU i.e.
host1.bca.tu.edu.
Contd. ….
 If a label is not terminated by a null string, then it is called a
partially qualified domain name (PQDN).
 A PQDN starts from a node, but it does not reach the root.
 It is used by when the name to be resolved belongs to the same site as the
client. Here, the resolver can supply the missing part, called the suffix, to
create an FQDN.
 For example, if a user at the tu.edu. site wants to get the IP address of the
host1 computer, the he or she can define the partial name i.e. host1. The
DNS client adds the suffix bca.tu.edu. before passing the address to the
DNS server.

Contd. ….
Fig: Domain names and labels

Contd. ….
 DNS in the Internet
 DNS is a protocol that can be used in different platforms.
 In the Internet, the DNS (tree) is divided into three different sections:
generic domain, country domains, and the inverse domains.
 However, due to the rapid growth of the Internet, it became extremely
difficult to keep track of the inverse domains, which could be used to find the
name of a host when given the IP address.
 The inverse domains are now deprecated i.e. disapproved (see RFC 3425).
 Generic Domains
 The generic domains define the registered hosts according to their generic
behaviour. Each node in the tree defines a domain, which is an index to the
DNS database.
 Generic domain labels (14 possible) are listed in the below table:
Contd. ….

Contd. ….
 Country Domains
 The country domains section uses two-character country abbreviations (e.g.
np for Nepal).
 DNS Query Types

 There are three types of queries in the DNS system: recursive query,
iterative query, and non-recursive query.
 Recursive Query
 In a recursive query, a DNS client provides a hostname, and the DNS Resolver
must provide an answer – it responds with either a relevant resource record,
or an error message if it can’t be found.
 The resolver starts a recursive query process, starting from the DNS root
server, until it finds the Authoritative Name Server that holds the IP address
and other information for the requested hostname.
Contd. ….
 Iterative Query
 In an iterative query, a DNS client provides a hostname, and the DNS
Resolver returns the best answer it can.
 If the DNS resolver has the relevant DNS records in its cache, then it returns
them. If not, it refers the DNS client to the Root server, or another
Authoritative Name Server which is nearest to the required DNS zone.
 The DNS client must then repeat the query directly against the DNS server it
was referred to.

Contd. ….
 Non-recursive Query
 A non-recursive query is a query in which the DNS Resolver already knows
the answer.
 It either immediately returns a DNS record because it already stores it in local
cache, or queries a DNS Name Server which is authoritative for the record,
meaning it definitely holds the correct IP for that hostname.
 In both cases, there is no need for additional rounds of queries (like in
recursive or iterative queries). Rather, a response is immediately returned to
the DNS client.

Contd. ….
 DNS Messages
 DNS has two types of messages: query and response. Both types have
the same format.
 The query message consists of a header and question records; the
response message consists of a header, question records, answer
records, authoritative records, and additional records.
Compiled by Ujjwal Rijal || Fig: Query and Response Messages

Contd. ….
 Header
 Both query and response messages have the same header format with some
fields set to zero (0) for the query messages.
 The header is 12 bytes and its format is shown in the below figure:
Fig: DNS Message Header Format

Contd. ….
 Query Section
 This is a section consisting of one or more question records. It is present on
both query and response messages.
 Answer Section
 This is a section consisting of one or more resource records. It is present only
on response messages. It includes the answer from the server to the client.
 Authoritative Section
on response messages. It gives information (domain name) about one or more
authoritative servers for the query.
 Additional Information Section
on response messages. It provides additional information that may help the
client i.e. the resolver.
Contd. ….
 Types of Records
 Two types of records are used in DNS i.e. the question records and
the resource records.
 The question records are used in the question section of the query and
response messages.
 A question record is used by the client to get information from a server. It
contains the domain name.
 And the resource records are used in the answer, authoritative and
additional information sections of the response messages.
 Resource records means what is returned by the server to the client. Here,
each domain name (each node on the tree) is associated with a record called
the resource record.
 The server database consists of the resource records.

 Attribute-Based Naming
 Flat and structured names generally provide a unique and location-
independent way of referring to entities.
 In many cases, it is much more convenient to name, and look up entities by
means of their entities. Each attribute says something about the entity.
 Lookup operations can be extremely expensive as they require to match the
requested attribute values, against the actual values.
 Thus, it is crucial within a distributed environment to keep important
information structured and quickly available.

Contd. ….
 Directory Services
 A service that stores collections of bindings between names and attributes, and that
looks up entries that match attribute-based specifications is called a directory
service.
 Examples are Microsoft’s Active Directory Services, X.500 and its cousin
LDAP, and so on.
 Directory services are sometimes called yellow page services, and the
conventional name services are correspondingly called white page services,
in an analogy with the traditional types of telephone directory.
 Directory services are also known as attribute-based name services. With
directory services, entities have a set of associated attributes that can be used for
searching.
 In some cases, the choice of attributes can be relatively simple. For example, in
an e-mail system, messages can be tagged with attributes for the sender, recipient,
subject, and so on.

Contd. ….
 Hierarchical Implementation: LDAP
 LDAP stands for Lightweight Directory Access Protocol.
 In the ideal case, a central server keeps the data in a directory and
distributes it to all the clients using a certain protocol.
 The data is structured in a way that a wide range of applications can access
them. That way, it is not necessary for every single calendar tool and e-mail
client to keep its own database – a central repository can be accessed
instead. This notably reduces the administration effort for the concerned
information.
 The use of an open and standardized protocol like LDAP ensures that as
many different client applications as possible can access such information.
 The design of a directory service like LDAP is not laid out to support
complex update or query mechanisms. All applications accessing this service
should gain access quickly and easily.

Contd. ….
 LDAP was originally planned as a lean flavour of the Directory Access
Protocol (DAP), which was developed for accessing X.500.
 The X.500 standard regulates the hierarchical organization of the directory
entities.
 LDAP is relieved of few functions of the DAP. Without having to miss the
X.500 entry hierarchy, we profit from LDAP’s cross-platform capabilities
and save resources, and the use of TCP/IP makes it substantially easier to
establish interfaces between a locking application and a LDAP service.
 LDAP, meanwhile, has evolved and is increasingly employed as a stand-alone
solution without X.500 support.
 LDAP supports referrals with LDAPv3 (the protocol version in package
openldap2), making it possible to realize distributed databases.
 The usage of SASL (Simple Authentication and Security Layer) is also new.

Contd. ….
 A directory in this context is a type of database optimized for
quick and effective reading and searching:
o To make numerous concurrent reading access possible, the writing access is
limited to a small number of updates by the administrator.
o Because writing accesses can only be executed in a restricted fashion, a
directory service is employed for administering mostly unchanging, static
information.
o When static data is administered, updates of the existing data sets are very
rare. When working with dynamic data, specially when data sets like bank
accounts or accounting are concerned, the consistency of the data is of the
primary importance.

Contd. ….
 Structure of an LDAP Directory Tree
 An LDAP directory has a tree structure. All entries (called objects) of the
directory have a defined position within this hierarchy. This hierarchy is
called the directory information tree (DIT).
 The complete path to the desired entry, which unambiguously identifies it,
is called distinguished name (DN).
 The single nodes along the path to this DN entry are called relative
distinguished name (RDN).
 Objects can generally be assigned to one of two possible types:
Container:These objects can themselves contain other objects.
Leaf:These objects sit at the end of a branch and have no sub-ordinate objects.

Contd. ….
Fig: Structure of an LDAP Directory

Contd. ….
 Decentralized Implementations
 Notably with the advent of peer-to-peer systems, researchers have also been
looking for solutions for decentralized attribute-based naming systems.
 In particular, peer-to-peer systems are often used to store files. Initially, files
could not be searched – they could only be looked up by their keys.
 However, having the possibility to search for a file based on descriptors can
be extremely convenient, where each descriptor is nothing but an
(attribute, value) pair.
 Obviously, querying every node in a peer-to-peer system to see if it contains
a file matching one or more of such pairs is infeasible.
 What we need is a mapping of (attribute, value) pairs to index servers,
which, in turn, point to files matching those pairs.

 Case Study: The Global Name Service
 A Global Name Service (GNS) was designed and implemented by
Lampson and colleagues at the DEC Systems Research Center to provide
facilities for resource location, mail addressing and authentication.
 The service should accommodate changes in the names of the individuals,
organizations and groups that it holds, and changes in the naming structure
such as those that occur when one company is taken over by another.
 The GNS manages a naming database that is composed of a tree of
directories holding names and values.
 Directories are named by multi-part pathnames referred to a root, or
relative to a working directory, much like file names in a UNIX file system.
 Each directory is also assigned an integer, which serves as a directory
identifier (DI). A directory contains a list of names and references.
 The values stored at the leaves of the directory tree are organized into value
trees, so that the attributes associated with names can be structured values.

Contd. ….
Fig: GNS directory tree and value tree for user Peter.Smith

Contd. ….
 Names in the GNS have two parts: <directory name, value name>.
The first part identifies a directory; the second refers to a value tree, or
some portion of a value tree.
 For example, in the above figure, in which DIs are illustrated as small
integers. The attributes of a user Peter.Smith in the directory QMW would
be stored in the value tree named <EC/UK/AC/QMW,
Peter.Smith/password>, and several mail addresses, each of which would
be listed in the value tree as a single node with the name
<EC/UK/AC/QMW, Peter.Smith/mailboxes>.

Contd. ….
 Accommodating Changes
 It focuses about the aspects of the design that are concerned with
accommodating growth and change in the structure of the naming database.
 At the level of clients and administrators, growth is accommodated through
extension of the directory tree in the usual manner.
 But we may wish to integrate the naming trees of two previously separate
GNS services. For example, how could we integrate the database rooted
at the EC directory shown in the above figure with another database for
NORTH AMERICA?
 The new figure below shows a new root, WORLD, introduced with the
existing roots of the two trees to be merged.
 EC and NORTH AMERICA are working roots – initial contexts against
which names beginning with the root “/” are to be looked up.
Contd. ….
Fig: Merging trees under a new root

Contd. ….
 The GNS also supports the restructuring of the database to accommodate
organizational change.
 Suppose that the United States becomes part of the European community.
 The below figure shows the new directory tree. But if the US subtree is
simply moved to the EC directory, names beginning WORLD/NORTH
AMERICA/US will no longer work.
 The solution adopted by the GNS is to insert a “symbolic link” in place of
the original US entry.
 The GNS directory lookup procedure interprets the link as a redirection to
the US directory in its new location as shown in the below figure.

Contd. ….
Fig: Restructuring the directory

Course Title:
Distributed System
(CACS 352)


Unit-6
Coordination
 Introduction
 Coordination and synchronization are two closely related phenomena. In
process synchronization, we make sure that one process waits for
another to complete its operation.
 While dealing with data synchronization, the problem is to ensure that
two sets of data are the same.
 When it comes to coordination, the goal is to manage the interactions
and dependencies between activities in a distributed system.
 From this perspective, one could state that coordination encapsulates
synchronization.

 Clock Synchronization
 Synchronization in distributed systems is more complicated than in centralized
ones because the former has to use distributed algorithms.
 In general, distributed algorithms have the following properties:
 The relevant information is scattered among multiple machines.
 Processes make decisions based only on local information.
 A single point failure in the system should be avoided.
 No common clock or other precise global time source exists.
 The first three points all say that it is unacceptable to collect all the information
in a single place for processing.
 The last point in the list is also crucial. In a centralized system, time is
unambiguous. In a distributed system, achieving agreement on time is not trivial.

 Logical Clocks
 Logical Clocks refer to implementing a protocol on all machines within
your distributed system, so that the machines are able to maintain
consistent ordering of events within some virtual timespan.
 A logical clock is a mechanism for capturing chronological and causal
relationships in a distributed system. Distributed systems may have no
physically synchronous global clock, so a logical clock allows global
ordering on events from different processes in such systems.
 For Example: It is adequate that all machines agree that it is 7:00, even if it is
really 7:02. Thus, for certain class of algorithms, it is the internal consistency of
the clocks that matters, not whether they are particularly close to the real time.
For these algorithms, it is conventional to speak of the clocks as logical clocks.
 When the additional constraint is present that the clocks must not only be the
same, but also must not deviate from the real time by more than a certain
amount, the clocks are called physical clocks.
Contd. ….
 Lamport’s Logical Clocks
 To synchronize logical clocks, Lamport defined a relation called
happens-before. The expression a→b is read as event a happens
before event b, and means that all processes agree that first event a
occurs, then afterward, event b occurs.
 The happens-before relation can be observed directly in two
situations:
 If a and b are the events in the same process, and a occurs before b, then
a→b is true.
 If a is the event of a message being sent by one process, and b is the event of
the message being received by another process, then a→b is also true. A
message cannot be received before it is sent, or even at the same time it is
sent, since it takes a finite, non-zero amount of time to arrive.

Contd. ….
 Happens-before is a transitive relation, so if a → b and b → c, then
a → c. If two events, x and y, happen in different processes that do not
exchange messages (not even indirectly via third parties), then x → y is not
true, but neither is y → x.
 These events are said to be concurrent, which simply means that nothing
can be said (or need to be said) about when the events happened or which
event happened first.
 In short, it can be stated that Lamport’s algorithm corrects the
clock.

Contd. ….
Example: Consider three processes P1, P2 and P3, each with its own clock. The
processes run on different machines, each with its own clock, running at its own
speed.
When the clock has ticked 6 times in process P1, it has ticked 8 times in process P2
and 10 times in process P3.
Each clock runs at a constant rate, but the rates are different due to differences in the
crystals.
At time 6, process P1 sends message m1 to process P2, the clock in process P2 reads
16 when it arrives.
If the message carries the starting time, 6, in it, process P2 will conclude that it took
10 ticks to make the journey.

Contd. ….
Fig: Three processes, each with its own clock, running at different rates

Contd. ….
o Now, consider message m3. It leaves process P3 at 60, and arrives at P2 at
56. Similarly, message m4 from P2 to P1 leaves at 64 and arrives at 54. These
values are clearly impossible. It is the situation that must be prevented.
o Lamport’s solution follows directly from the happens-before relation. Since

m3 left at 60, it must arrive at 61 or later. Therefore, each message carries
the sending time according to the sender’s clock. When a message arrives
and the receiver’s clock shows a value prior to the time the message was
sent, the receiver fast forwards its clock to be one more than the sending
time. In the below figure, we see that m3 now arrives at 61. Similarly, m4
arrives at 70.

Contd. ….
Fig: Lamport’s algorithm corrects the clocks.

Contd. ….
o Using this method, we now have a way to assign time to all the
events in a distributed system subject to the following
conditions:
 If a happens before b in the same process, C(a) > C(b). [C(x) is time value
of event x].
 If a and b represent the sending and receiving of a message, then
C(a)<C(b).
 For all the events a and b, C(a) ≠ C(b).
o This algorithm gives us a way to provide a total ordering of all
the events in the system.

Contd. ….
 Vector Clocks
 Vector clock is an algorithm that generates partial ordering of events and
detects causality violations in a distributed system.
 These clocks expand on scalar time to facilitate a causally consistent view of
the distributed system, they detect whether a contributed event has caused
another event in the distributed system.
 It essentially captures all the causal relationships. This algorithm helps us
label every process with a vector (a list of integers) with an integer for each
local clock of every process within the system. So, for N given processes,
there will be vector/ array of size N.

Contd. ….
 The algorithm follows by:
 Initially, all the clocks are set to zero.
 Every time, an internal event occurs in a process, the value of the processes’
logical clock in the vector is incremented by 1.
 Also, every time a process sends a message, the value of the processes’
logical clock in the vector is incremented by 1.
 Moreover, each element is updated by taking the maximum of the value in
its own vector clock and the value in the vector in the received message (for
every element).

 Physical Clocks
 Although Lamport’s algorithm gives an unambiguous event ordering, the
time values are assigned to events are not necessarily close to the actual
time at which they occur.
 In some systems (e.g. real time systems), the actual clock time is
important. For these types of systems, external physical clocks are
required.
 For reasons of efficiency and redundancy, multiple physical clocks are
generally considered desirable, which yields two problems:
 How do we synchronize them with real – world clocks?
 How do we synchronize the clocks with each other?

Contd. ….
 The basis for keeping global time is called Universal Coordinated Time,
but is abbreviated as UTC. UTC is the basis of all modern civil
timekeeping and is a worldwide standard.
 To provide UTC to people who need precise time, some 40 shortwave
radio stations around the world broadcast a short pulse at the start of each
UTC second.
 The accuracy of these stations is about ∓1 msec, but due to random
atmospheric fluctuations that can affect the length of the signal path, in
practice the accuracy is no better than ∓10 msec.
 Several earth satellites also offer a UTC service. The Geostationary
Environment Operational Satellite can provide UTC accurately to 0.5
msec, and some other satellites do even better.

Contd. ….
 Clock Synchronization Algorithms
 If one machine has a UTC receiver, the goal becomes keeping all the other
machines synchronized to it.
 If no machines have UTC receivers, each machine keeps track of its own time,
and the goal is to keep all the machines together as well as possible.
 Many algorithms have been proposed for doing this synchronization and all the
algorithms have the same underlying model for the system.
 A software clock in a computer is derived from that computer’s hardware clock.
In particular, each machine is assumed to cause an interrupt “f” times a second.
 When this timer goes off, the interrupt handler adds 1 to a counter that keeps
track of the number of ticks (interrupts) since some agreed upon time in the
past.
 This counter acts as a software clock “C”, resonating at frequency “f”.
Contd. ….
Fig: Relation between clock time and UTC when clocks tick at different rates
Contd. ….
 Network Time Protocol (NTP) → (Cristian’s Algorithm)
 A common approach in many protocols and originally proposed by Cristian
is to let clients contact a time server.
 The latter can accurately provide the current time, for example, because it is
equipped with a UTC receiver or an accurate clock.
 The problem, of course, is that when contacting the server, message delays
will have outdated the reported time.
 The trick is to find a good estimation for these delays.
 Cristian’s algorithm can also give external synchronization if the time server
is synced with external clock reference
 NTP requires a special node with a time source
 NTP is prone to failure of the central server.
Contd. ….
 In this method, each node periodically sends a message to the server. When
the time server receives the message it responds with a message T, where T is
the current time of server node.
Fig: Getting the current time from a time server

Contd. ….
 Let us assume that the propagation delays from A to B is roughly the same as
B to A, meaning that δTreq = T2 – T1 ≈ T4 – T3 = δTres. In that case, A can
estimate its offset (θ) relative to B as:
(T2 – T1) + (T4 – T3) (T2 – T1) +(T3 – T4)
θ = T3 + – T4 =
𝟐 𝟐
 In the case of NTP, this protocol is set up pairwise between servers. In other
words, B will also probe A for its current time.
 The offset (θ) is computed as given above, along with the estimation δ for
the delay:
(T4 – T1) + (T3 – T2)
δ=
𝟐

Contd. ….
 The Berkeley’s Algorithm
 In NTP algorithms, the time server is passive. Other machines periodically
ask it for the time. All it does is to respond to their queries.
 In Berkeley UNIX, exactly the opposite approach is taken. Here, the time
server (actually a time daemon) is active, polling every machine from time
to time to ask what time it is there.
 Based on the answers, it computes an average time and tells all the other
machines to advance their clocks to the new time or slow their clocks
down until some specified reduction has been achieved.
 This method is suitable for a system in which no machine has a UTC
receiver. The daemon’s time must be set manually by the operator
periodically.

Contd. ….

 Mutual Exclusion (Mutex)
 Mutual exclusion is the mechanism that prevents interface and ensures
consistency when accessing the resources. It ensures that concurrent
processes make a serialized access to shared resources or data. It is similar
to the critical section problem of operating system.
 In distributed system, neither shared variables (semaphores) nor a lock
kernel can be used in order to implement mutual exclusion. Thus, mutual
exclusion has to be based exclusively on message passing, in the context of
unpredictable message delays and no complete knowledge of the state of
the system.
 The primary objective of a mutual exclusion algorithm is to maintain
exclusion i.e. to guarantee that only one request accesses the critical
section at a time.
Contd. ….
 Essential Requirements/ Characteristics for Mutual Exclusion
 Freedom from Deadlocks: Two or more sites should not endlessly wait for
messages that will never arrive.
 Freedom from Starvation: A site should not be forced to wait independently
to execute critical section while other sites are repeatedly executing critical
section.
 Fairness: Fairness indicates that requests must be executed in the order they are
made. Since a physical global clock does not exist, time is determined by the
logical clocks. Here, fairness implies freedom from starvation, but not vice –
versa.
 Fault Tolerance: A mutual exclusion algorithm is fault tolerant if in the wake of
a failure, it can recognize itself so that it continues to function without any
disruptions and disturbances.

Contd. ….
 Performance Criteria for Mutual Exclusion
 Bandwidth Consumed: Number of messages sent in each entry and
exit operation.
 Client Delay: Incurred by a process at each entry and exit operation.
 Throughput: Rate at which the collection of processes as a whole can
access the critical section assuming some communication is necessary
between the successive processes.

Contd. ….
 Mutual Exclusion Algorithms
 A mutex is also a common name for a program object that negotiates
mutual exclusion among threads, also called a lock.
 Following are the algorithms for mutual exclusion:
I. Centralized Algorithms
II. Distributed Algorithms
III.Token Ring Algorithm
 Now, they are discussed below:

Contd. ….
I. Centralized Algorithms
 Here, one process is selected as the coordinator of the system with the
authority of giving access to other processes for entering the critical
region or section.
 If any process wants to enter the critical region, then it has to take the
permission from the coordinator process. This permission is taken by
sending a REQUEST message.

Contd. ….

Contd. ….
II. Distributed Algorithms
 Here, no particular assumptions on the network topology are required,
except connectivity; the communication graph may be arbitrary.
 The process communicate by using messages only and there is no global
controller. Furthermore, no process needs to know or learn the global
network topology.
 In that sense, the algorithm is more general than the MUTEX algorithms
which make use of a prior knowledge of the network topology.
 When a process wants to enter a critical region, then it builds a
message containing:
 Name of the critical region.
 It’s process number.
 It’s current time.

Contd. ….
 The process sends this message to all the processes in the network. When
another process receives this message, it takes the action pertaining on its
state and the critical region mentioned.
 For this, three cases are possible here:
 If the message receiving process is not in the critical region and does not
wish to enter it, then it sends it back.
 Receiver is already in the critical region and does not reply.
 Receiver wants to enter the same critical region and has not done yet. So,
it compares the timestamp of the incoming message with the one it has
sent to others for permission. The lowest one wins and can enter the
critical region.
o Finally, when the process exists from the critical region, then it
sends OK message to inform everyone.

Contd. ….

Contd. ….
III.Token Ring Algorithm
 Here, we have a bus network (e.g. Ethernet), with no inherent ordering of
the processes.
 In software, a logical ring is constructed in which each process is assigned
a position in the ring.
 The ring positions may be allocated in numerical order of network
addresses or some other means.
 It does not matter what the orderings is. All that matters is that each
process knows who is next in line after itself.

Contd. ….
Algorithm:
 Token is initially given to one process.
 When a process requires to enter section, it waits until it gets token from
its left neighbour and retains it. After it got the token, it enters the critical
section. After it left the critical section, it passes token to its neighbour in
clockwise direction.
 If a process gets the token but does not require to enter a critical section,
it immediately passes token along a ring.

Contd. ….

 Distributed Election Algorithm
 Election algorithm is an algorithm choosing a unique process to play a
particular role.
 Any processes can be elected but only one process must be elected and all
other processes must agree on the decision.
 Election is done after a failure of current coordinator or failure of process
currently holding the token.
 An election process is conducted typically in two phases:
 Select a leader with the highest priority.
 Inform all the processes about the winner.

Contd. ….
 Distributed Election Algorithms
 The distributed election algorithms are categorized into
the following two types:
I. Bully Algorithm
II. Ring Algorithm
 Now, they are discussed below:

Contd. ….
I. Bully Algorithm
 A process has to know the identifier of all other processes; the process
with the highest identifier, among those which are up, is selected.
 Any process could fail during the election procedure. When any process
notices that the coordinator is no longer responding to requests, it initiates
an election.
 A process Pi holds an election as follows:
 Pi sends an ELECTION message to all the processes with higher numbers.
 If no one responds, Pi wins the election and becomes coordinator.
 If one of the higher-ups answers, it takes over and Pi’s job is done.

Contd. ….

Contd. ….

Contd. ….
II. Ring Algorithm
 We assume that the processes are arranged in a local ring; each process
knows the address of one process, which is its neighbour in the clockwise
direction.
 The algorithm elects a single coordinator, which is the process with the
highest identifier.
 Election is started by a process which has noticed that the current
coordinator has failed.
 The process places its identifier in an election message that is passed to the
following process.
 When a process receives an election message, then it compares the
identifier in the message with its own.

Contd. ….
 If the arrived identifier is greater, it forwards the received election
message to its neighbour; if the arrived identifier is smaller, then it
substitutes its own identifier in the election messages before forwarding it.
 If the received identifier is that of the receiver itself, then this message is
through the ring.
 The distributed election ring algorithm is best demonstrated
through the following figure:

Contd. ….

 Location System
 Large distributed systems that are dispersed across a wide-area network
is often necessary to take proximity into account.
Global Positioning System (GPS)
 GPS is a satellite-based navigation distributed system made up of a
network of 24 satellites placed into an orbit by the U.S. Department of
the Defense.
 It is the most popular system among many global navigation satellite
systems (GNSS).
 For any given point and at any time, these systems allow us to know the
exact location of that point with an accuracy of a few meters of less.
 To do this, they use a constellation of satellites to which information is
transmitted from the study point, and use that transmission to compute
the coordinates of the point.
Contd. ….
 Distances are measured from a GPS unit (user segment) to a certain
number of satellites. Knowing those distances and the exact position of
satellites, the position of the unit can be computed precisely.
 GPS was originally intended for military applications, but in the 1980s,
the U.S. government made the system available for the civilian use.
 GPS works in any weather conditions, anywhere in the world, 24 hours
a day.
 There are no subscription fees or setup charges to use GPS.
 Accuracy can be pinpointed to within one (1) meter with special
military-approved equipment.
 GPS equipment is widely used in science, known as Geographical
Information Sciences (GISci), and has now become sufficiently low-cost
that almost anyone can own a GPS receiver.
Contd. ….
 In order to compute a position, consider first the two-dimensional case, as
shown in the below figure, in which three satellites are drawn, along with
the circles representing points at the same distance from each respective
satellite.We see that the intersection of the three circles is a unique point.
Fig: Computing node’s position in a two-dimensional space

 Distributed Event Matching
 Event matching, or more precisely, notification filtering, is at the heart of
publish-subscribe systems.
 The problem illustrates the following:
 A process specifies through a subscription S in which events it is
interested.
 When a process publishes a notification N on the occurrence of an event,
the system needs to see if S matches N.
 In the case of a match, the system should send the notification N, possibly
including the data associated with the event that took place, to the
subscriber.

Contd. ….
Centralized Implementations
 A simple, naive implementation of event matching is to have a fully
centralized server that handles all the subscriptions and notifications.
 In such a scheme, a subscriber simply submits a subscription, which is
subsequently stored.
 When a publisher submits a notification, that notification is checked
against each and every subscription, and when a match is found, the
notification is copied and forwarded to the associated subscriber.

 Gossip–Based Coordination
 Here, we look at aggregation, large-scale peer sampling service,
and overlay construction respectively.
Aggregation
 Gossiping can be used to discover nodes that have a few outgoing wide-
area links, to subsequently apply directional gossiping.
 Another interesting application area is simply collecting, or actually
aggregating information.
 Consider the following information exchange:
Every node Pi initially chooses an arbitrary number, say vi. When node Pi
contacts node Pj, they each update their value as:
(vi + vj)
vi, vj
𝟐

Contd. ….
A large-scale peer sampling service
 Another solution to the gossip-based coordination is to construct a fully
decentralized peer-sampling service, or PSS for short.
 As PSS turns out, and somewhat counter-intuitive, a PSS can be built using
an epidemic protocol.
 A gossip protocol or epidemic protocol is a procedure or process of
computer peer-to-peer communication that is based on the way
epidemics spread.
 Some distributed systems use peer-to-peer gossip to ensure that data is
disseminated to all the members of a group.
 Each node maintains a list of its neighbours, where, ideally, each of these
neighbours represent a randomly chosen live node from the current set of
nodes.This list of neighbours is also referred to as a partial view.
Contd. ….
 In the solution, it is assumed that nodes regularly exchange entries from
partial view. Each entry identifies another node in the network, and has
an associated age that indicates how old the reference to that node is.
 Two threads are used, as shown in the below figure:
Fig: Communication between the active and passive thread in a peer-sampling service.
Contd. ….
 The different selection operations are specified as follows:
 selectPeer: Randomly select a neighbour from the local partial view.
 selectToSend: Select some other entries from the partial view, and
add to the list intended for the selected neighbour.
 selectToKeep: Add the received entries to partial view, remove
repeated items, and shrink view to the different items.

Contd. ….
Gossip-based Overlay Construction
 Although it would seem that structured and unstructured peer-to-peer
systems form strict independent classes, this need actually not be case.
 One key observation is that by carefully exchanging and selecting entries
from partial views, it is possible to construct and maintain specific
topologies of overlay networks.
 This topology management is achieved by adopting two-
layered approach as shown in the below figure:

Contd. ….

Contd. ….
 The lowest layer constitutes an unstructured peer-to-peer system in
which nodes periodically exchange entries of their partial views with the
aim to provide a peer-sampling service.
 Accuracy in this case refers to the fact that the partial view should be
filled with the entries referring to randomly selected live nodes.
 The lowest layer passes its partial view to the highest layer, where an
additional selection of entries take place.
 This then leads to a second list of neighbours corresponding to the
desired topology.

Course Title:
Distributed System
(CACS 352)

Unit-7
Consistency and
Replication
 Introduction to Replication
 Replication is the process of storing multiple data in more than one
site or node.
 It is useful in improving the availability of data.
 It is simply copying data from a database from one server to
another server so that all the users can share the same data without
any inconsistency.
 The result is a distributed database in which users can access data
relevant to their tasks without interfering with the work of others.
 Thus, in conclusion, replication is the mechanism of maintaining
multiple copies of data at multiple nodes or sites.

Contd. ….

 Reasons for Replication
 The main aim of replication is to provide backup on the scenario of
failure.
 There are Four main reasons for replication and they are:
I. It creates the reliability of a system.
 If one replica is unavailable or crashes, use another
 Protect against corrupted data
II. It improves the performance of a system.
 Scale with size of the distributed system (replicatedWeb servers)
 Scale in geographically distributed systems (Web proxies)

Contd. ….
III. The key issue is the need to maintain consistency of
replicated data.
 If one copy is modified, others become inconsistent.
IV. Another final fourth main reason for data replication is
fault tolerance.
 Ensures the correctness of data in addition to availability.
 If a server fails, then the data can be accessed from other servers.

 Advantages of Data Replication
 To provide a consistent copy of data across all the database nodes.
 To increase the availability of data.
 The reliability of data is increased through data replication.
 Data Replication supports multiple users and gives high
performance.
 To remove any data redundancy, the databases are merged and slave
databases are updated with outdated or incomplete data.
 Since replicas are created there are chances that the data is found
itself where the transaction is executing which reduces the data
movement.
 To perform faster execution of queries, etc.

 Disadvantages of Data Replication
 More storage space is needed as storing the replicas of same data at
different sites consumes more space.
 Data Replication becomes expensive when the replicas at all
different sites need to be updated.
 Maintaining Data consistency at all different sites involves complex
measures, etc.

 Replication and Scaling
 Replication and caching are used for system scalability.
 Multiple copies improve performance by reducing access latency
but have higher network overheads of maintaining consistency.
 Example: An object is replicated N times.
 Consider the Read frequency R and the write frequency W
 If R <<W, high consistency overhead and wasted messages
 Consistency maintenance is itself an issue
 What semantics to provide?
 Tight consistency requires globally synchronized clocks.

Contd. ….
 The solution is to loosen consistency requirements.
 Variety of consistency semantics possible.
 Consistency model (consistency semantics)
 Contract between processes and the data store
 If processes obey certain rules, data store will work correctly.
 All models attempt to return the results of the last
write for a read operation.
 Differ in how last write is determined/defined.

 Data–Centric Consistency Models
 Traditionally, consistency has been discussed in the context of read
and write operations on shared data, available by means of
(distributed) shared memory, a (distributed) shared database, or a
(distributed) file system.
 Nowadays a broader term data store is used. A data store may be
physically distributed across multiple machines.
 Each process that can access data from the store is assumed to have
a local copy available of the entire store.
 A data operation is classified as a write operation when it
changes the data, and is otherwise classified as a read
operation.
Contd. ….
Fig:The general organization of a logical data store, physically

distributed and replicated across multiple processes.
Contd. ….
 A consistency model is a contract between processes and the data
store.
 It says that if processes agree to obey certain rules, then the store
promises to work correctly.
 Example, three processes P1, P2, P3 and three shared variables x,
y, z originally initialized to zero in 3 replicas – each process reads
values from a different replica:
Fig:Three concurrently-executing processes.

Contd. ….
Strict Consistency
 Definition: Any read on a data item X returns a value
corresponding to the result of the most recent write on X.
 This definition implicitly assumes the existence of absolute global
time. Naturally available in uni-processor systems, but impossible
to implement in distributed systems.
Fig: Behavior of two processes, operating on the same data item.

(a) Strictly consistent store (b) Store that is not strictly consistent.
Contd. ….
Sequential Consistency
 It was first defined by Lamport in the context of shared memory
for multiprocessor systems.
 In general, a data store is said to be sequentially
consistent when it satisfies the following conditions:
 The result of any execution is the same as if the (read and write)
operations by all processes on the data store were executed in some
sequential order and the operations of each individual process
appear in this sequence in the order specified by its program.
 All processes see the same interleaving of (write) operations.

Contd. ….

Contd. ….
Causal Consistency
 Causal consistency requires a total order of causally related
write operations only.
 A read is causally related to the write that provided the data the read got.
 A write is causally related to a read that happened before this write in
the same process.
 If write1 → read, and read → write2, then write1 → write2.
 Necessary condition for causal consistency:
 Writes that are potentially causally related must be seen by all processes
in the same order.
 Concurrent writes may be seen in a different order on different
machines.
Contd. ….
Fig: This sequence is allowed with a causally-consistent store,

but not with a sequentially or strictly consistent store.
 Note:
W1(x)a → W2(x)b, but W2(x)b || W1(x)c

Contd. ….

Contd. ….
Summary of Consistency Models

D e s c r i p t i o n
Consistency
Strict Absolute time ordering of all shared accesses matters.
Sequential All processes see all shared accesses in the same order.
Accesses are not ordered in time.
Causal All processes see causally-related shared accesses in the

same order.

 Client–Centric Consistency Models
 Goal: Show how we can perhaps avoid system-wide consistency, by
concentrating on what specific clients want, instead of what should be
maintained by servers.
 Background: Most largescale distributed systems (i.e., databases)
apply replication for scalability, but can support only weak consistency:
 DNS: Updates are propagated slowly, and inserts may not be
immediately visible.
 News: Articles and reactions are pushed and pulled throughout the
Internet, such that reactions can be seen before postings.
 Lotus Notes: Geographically dispersed servers replicate documents,
but make no attempt to keep (concurrent) updates mutually consistent.
 WWW: Caches all over the place, but there need be no guarantee that
you are reading the most recent version of a page.
Contd. ….
Consistency for Mobile Users
 Example: Consider a distributed database to which you have access
through your notebook. Assume your notebook acts as a front end to the
database.
 At location A you access the database doing reads and updates.
 At location B you continue your work, but unless you access the same
server as the one at location A, you may detect inconsistencies:
 Your updates at A may not have yet been propagated to B.
 You may be reading newer entries than the ones available at A.
 Your updates at B may eventually conflict with those at A.
 Note: The only thing you really want is that the entries you updated
and/or read at A, are in B the way you left them in A. In that case, the
database will appear to be consistent to you.
Contd. ….
Eventual Consistency
Fig: The principle of a mobile user accessing different replicas

of a distributed database.
Contd. ….
Monotonic Reads
 A data store is said to provide monotonic-read consistency if
the following condition holds:
 If a process reads the value of a data item x, any successive
read operation on x by that process will always return that
same or a more recent value.
 Example-1: Automatically reading your personal calendar updates
from different servers. Monotonic Reads guarantees that the user sees
all updates, no matter from which server the automatic reading takes
place.
 Example-2: Reading (not modifying) incoming mail while you are on
the move. Each time you connect to a different email server, that server
fetches (at least) all the updates from the server you previously visited.
Contd. ….
MonotonicWrites
 If an A write operation by a process on a data item x is
completed before any successive write operation on x by the
same process.
 Example: Updating a program at server S2 , and ensuring that all
components on which compilation and linking depends, are also placed
at S2 .
 Example: Maintaining versions of replicated files in the correct order
everywhere (propagate the previous version to the server where the
newest version is installed).

Contd. ….

Contd. ….
Read Your Writes
 The effect of a write operation by a process on data item
x, will always be seen by a successive read operation on x
by the same process.
 Example: Updating your Web page and guaranteeing that your
Web browser shows the newest version instead of its cached copy.

Contd. ….

Contd. ….
Writes Follow Reads
 The effect of a write operation by a process on data item x, will always
be seen by a successive read operation on x by the same process.
 Example: Updating your Web page and guaranteeing that your Web
browser shows the newest version instead of its cached copy.
 A write operation by a process on a data item x following a previous read
operation on x by the same process, is guaranteed to take place on the
same or a more recent value of x that was read.
 Example: See reactions to posted articles only if you have the original
posting (a read ``pulls in'' the corresponding write operation).

Contd. ….

 Replica Management
 The effect Model: We consider objects (and don't worry
whether they contain just data or code, or both).
 Distinguish different processes: A process is capable of
hosting a replica of an object or data:
 Permanent replicas: Process/machine always having a replica.
In many cases, the number of permanent replicas is small. For
example, a website.
 Server-initiated replicas: Process that can dynamically host a
replica on request of another server in the data store. For example, a
web server placed in Kathmandu.
 Client-initiated replicas: Process that can dynamically host a
replica on request of a client (client cache).

Contd. ….
Fig:The logical organization of different kinds of copies of a data store

into three concentric rings.
Contd. ….
Content Distribution / Update Propagation
 Replica management also deals with propagation of (updated) content to
the relevant replica servers.
 State versus Operations
 There are three possibilities of propagation update:
 Propagate only notification/invalidation of update (often used for
caches).
 Transfer data from one copy to another (distributed databases).
 Propagate the update operation to other copies (also called active
replication).
 No single approach is the best, but depends highly on available
bandwidth and read-to-write ratio at replicas.

Contd. ….
 Pull versus Push Protocols
 Pushing updates: server-initiated approach, in which update is
propagated regardless whether target asked for it.
 Pulling updates: client-initiated approach, in which client requests to
be updated.
Issue Push-based Pull-based
State at server List of client replicas and caches None
Messages sent Update (and possibly fetch update later) Poll and update
Response time at Immediate (or fetch-update time) Fetch-update time

client

Contd. ….
Managing replicated objects
 As we mentioned, data-centric consistency for distributed objects comes
naturally in the form of entry consistency.
 Although conceptually associating a lock with an object is simple, it does
not necessarily provide a proper solution when an object is replicated.
 There are two issues that need to be solved for implementing
entry consistency:
 We need a means to prevent concurrent execution of multiple
invocations on the same object.
 In case of a replicated object, we need to ensure that all changes to the
replicated state of the object are the same.

 Consistency Protocols
 A consistency protocol describes an implementation of a specific
consistency model.
 The most widely used models are: sequential consistency,
weak consistency with synchronization variables, and atomic
transactions.
 The main approaches of consistency protocols are:
 Primary-based protocols
 Replicated-write protocols
 Cache-coherence protocols

Contd. ….
Primary-based Protocols
 Used in traditional client-server systems that do not support
replication.
 Traditionally applied in distributed databases and file systems that
require a high degree of fault tolerance. Replicas are often placed on
same LAN.
 Establishes only a fully distributed, non-replicated data store. Useful
when writes are expected to come in series from the same client (e.g.,
mobile computing without replication)
 Distributed shared memory systems, but also mobile computing in
disconnected mode (ship all relevant files to user before
disconnecting, and update later on).
 Examples of primary-based protocols include remote-write
protocols and local-write protocols.
Contd. ….
o Remote-write (Primary-backup) Protocols
Fig: The principle of primary-backup protocol

Contd. ….
o Local-write Protocols
Fig: Primary-backup protocol in which the primary

migrates to the process wanting to perform an update.
Contd. ….
Replicated-write Protocols
 In replicated-write protocols, write operations can be carried out at multiple
replicas instead of only one, as in the case of primary-based replicas.
 A distinction can be made between active replication, in which an operation
is forwarded to all replicas, and consistency protocols based on majority
voting.
 Active replication: Updates are forwarded to multiple replicas, where
they are carried out. There are some problems to deal with in the face of
replicated invocations.
 Replicated invocations: Assign a coordinator on each side (client and
server), which ensures that only one invocation, and one reply is sent.
 Quorum-based protocols: Ensure that each operation is carried out in
such a way that a majority vote is established: distinguish read quorum and
write quorum.
Contd. ….
Cache-coherence Protocols
 Caches form a special case of replication, in the sense that they are generally
controlled by clients instead of servers.
 However, cache-coherence protocols, which ensure that a cache is consistent
with the server-initiated replicas are, in principle, not very different from the
consistency protocols discussed so far.
 Two separate criteria are often maintained to classify caching
protocols: coherence detection strategy and coherence
enforcement strategy.
 Coherence detection strategy says that caching solutions may differ when
inconsistencies are actually detected.
 Another design issue for cache-coherence protocols is the coherence
enforcement strategy, which determines how caches are kept consistent
with the copies stored at servers. The simplest solution is to disallow shared
data to be cached at all.
 Caching and Replication in Web
 TheWeb is arguably the largest distributed system ever built.
 Originating from a relatively simple client-server architecture, it is
now a sophisticated system consisting of many techniques to ensure
the better performance and availability requirements.
 These requirements have led to numerous proposals for caching
and replicating the dynamic Web content.
 Client-side caching in the Web generally occurs at two
places.
 In the first place, most browsers are equipped with a relatively
simple caching facility. Whenever a document is fetched, it is
stored in the browser’s cache from where it is loaded the next
time.
Contd. ….
 In the second place, a client’s site often runs a Web proxy. A
Web proxy accepts the requests from local clients and passes these
to theWeb servers.
 When a response comes in, the result is passed to the client.
 The advantage of this approach is that the proxy can cache the
result and return that result to another client, if necessary.
 In other words, a Web proxy can implement a shared cache.
 With so many documents being generated on the fly, the server
generally provides the document in pieces instructing the client to
cache only those parts that are not likely to change when the
document is requested the next time.

Contd. ….
 In addition to caching at browsers and proxies, Internet Service
Providers (ISPs) also generally place caches in their networks.
 Such schemes are mainly used to reduce network traffic and to
improve the performance, which is good for both the ISP and the
end-users.
 However, with multiple caches along the request path from client
to server, there is a risk of increased latencies when caches do not
contain the requested information.

Course Title:
Distributed System
(CACS 352)

Unit-8
Fault Tolerance
 Introduction to Fault Tolerance
 Fault means defect within hardware or software. Fault
tolerance is defined as the characteristic by which a system can
mask the occurrence and recovery from failures.
 In other words, a system is said to be fault tolerant if it can
continue to operate in the presence of failures.
 A system is said to be k-fault tolerant system if it is able to function
properly even if k-nodes of the system suffers from concurrent
failures.

 Requirements of Fault Tolerant System
 Availability: It is defined as the property that a system is ready to be
used immediately. In other words, a highly available system is one that
will most likely be working at a given instant in time.
 Reliability: It refers to the property that a system can run
continuously without failure. In other words, a highly reliable system is
one that will most likely continue to work without interruption during
a relatively long period of time.
 Safety: It refers to the situation that when a system temporarily fails
to operate correctly, nothing catastrophic happens.
 Maintainability: It refers to how easy a failed system can be
repaired. In other words, a highly maintainable system may also show a
high degree of availability, especially if failures can be detected and
repaired automatically.
 Security: Avoidance or tolerance of deliberate attacks of the system.
 Types of Faults
 Node fault: A fault that occurred at an individual node participating in
the distributed system. For example, a machine in a distributed system
fails due to some error in database configuration of that machine.
 Program fault: A fault that occurred due to some logical or syntactical
errors in the code. For example, a program that is designed to filter
the data by category but instead filtered by other means.
 Communication fault: A fault that occurred due to unreliable
communication channels connecting the node. For example, a node
sending data “010110” to another node but due to some problem in
communication channel, the receiver receives “010111”.
 Timing fault: The fault that occurred due to mismatch on timing of
any particular response. For example, a server replies too late or a
server is provided with data too soon i.e. has no enough buffer to hold
the data.
 Failure Models
 A system is said to fail when it cannot meet its promises.
 In particular, if distributed system is designed to provide its users with a
number of services, the system has failed when one or more of those
services cannot be provided.
 An error is a part of a system’s state that may lead to a failure. The
cause of an error is called fault.
 To get a better grasp on how serious a failure actually is, several
classification schemes have been developed.
 One such scheme is shown below:

Contd. ….
Table: Different types of Failures

 Process Resilience
 Process resilience is a mechanism to protect the system against faulty
process by replicating and distributing computations in a group.
 The group can be of the following two types:
1. Flat Group
 In flat group, all the processes within a group have equal roles and
control is completely distributed to all the processes.
 The flat group is symmetrical and has no single point of failure.
 If one of the processes crashes, then the group simply becomes smaller,
but can otherwise continue.
 A disadvantage is that decision making is more complicated. For
example, to decide anything, a vote often has to be taken, incurring
some delay and overhead.
Contd. ….
Fig: Communication in a flat group

Contd. ….
2. Hierarchical Group
 The hierarchical group has the opposite properties of the properties
of the flat group.
 All the communications are handled by a single process designated as
coordinator.
 Loss of the coordinator brings the entire group to a grinding halt, but
as long as it is running, it can make decisions without bothering
everyone else.
 In practice, when the coordinator in a hierarchical group fails, its role
will need to be taken over and one of the workers is elected as the
new coordinator.

Contd. ….
Fig: Communication in a hierarchical group

 Reliable Client-Server Communication
 In many cases, fault tolerance in distributed systems concentrates on
faulty processes.
 However, we also need to consider communication failures because a
communication channel may exhibit crash, omission, timing, and
arbitrary failures.
 The five different classes of failures that can occur during
client-server communication are as follows:
1.The client is unable to locate the server.
2.The request message from the client to the server is lost.
3.The server crashes after receiving a request.
4.The reply message from the server to the client is lost.
5.The client crashes after sending a request.
Contd. ….
 Each of these above mentioned categories possesses different
problems and requires different solutions, and the solutions
are as follows:
1. Report back to client.
2. Resend the message.
3. Use of remote procedure calls (RPC) semantics.
4. Operations should be idempotent (send multiple requests).
5. Kill the orphan computation.

 Reliable Group Communication
 Reliable group communication means that a message which is sent to a
process group should be delivered to each member of that group.
 If we separate the logic of handling messages from the core functionality
of a group member, then we can conventionally make the distinction
between receiving messages and delivering messages.
 A message is received by a message-handling component, which, in turn,
delivers a message to the component containing the core functionality of
a group member.
 Informally, a message that is received by process P will also be delivered
by the process P.
 The distinction between receiving and delivering messages is
shown in the below figure:

Contd. ….
Fig: Distinction between receiving and delivering messages

Contd. ….
 Let us make a distinction between reliable communication in the
presence of faulty processes, and reliable communication when
processes are assumed to operate correctly.
 In the first case, group communication is considered to be reliable when
it can be guaranteed that a message is received and subsequently
delivered by all non-faulty group members.
 If a sender intended to have a message delivered by each member of a
group G, but that, for whatever reason, at the time of delivery, we
actually have another group G' ≠ G, we should ask ourselves if the
message can be delivered or not.

 Distributed Commit
 Distributed commit deals with methods to ensure that either all the
processes commit to the final result or none of them do. It ensures
consistency of the distributed system.
 Distributed commit is often established by means of a coordinator.
 This coordinator tells all other processes that are also involved, called
participants, whether or not to (locally) perform the operation in
question.This scheme is called a one-phase commit protocol.
 For example, in the case of distributed transactions, a local commit
may not be possible because this would violate concurrency control
constraints.

Contd. ….
 In practice, more sophisticated schemes are needed, the most common
one being used is the two-phase commit protocol.
 The main drawback of this protocol is that it cannot generally efficiently
handle the failure of the coordinator. That’s why, a three-phase
commit protocol has been developed.

Contd. ….
Two-phase commit (2PC)
 The client who initiated the computation acts as coordinator. Processes
required to commit act as the participants.
 Phase
1. a. Coordinator sends vote-request to participants.
b.When participants receive vote-request, they reply vote-commit or
vote-abort. If they send vote-abort, then they abort their local
computations.
2. a. Coordinator collects all votes. If all commit, then coordinator sends
global-commit to all participants. Else, it sends global-abort.
b. Each participant waits for commit or abort and handles
accordingly.
Contd. ….
Fig(a):The finite state machine for the coordinator in 2PC

Fig(b):The finite state machine for the participant in 2PC

 Recovery
 Recovery is the mechanism to handle failure. It helps to recover correct
state of the system after failure.
 The whole idea of error recovery is to replace an erroneous state with
an error-free state.
Forms of Error Recovery
 In backward recovery, the main issue is to bring the system from its
present erroneous state back into a previously correct state.
 In forward recovery, when the system has entered an erroneous
state, instead of moving back to a previous check-pointed state, an
attempt is made to bring the system in a correct new state from which it
can continue to execute.

Contd. ….
Recovery Techniques
 Coordinated Checkpoint
 It is an attractive check-pointing strategy as it is domino-free and
requires a minimum number of checkpoints (max. two) to be stored per
process on stable storage.
 In coordinated checkpoint, all processes synchronize to jointly write
their state to local storage.
 It is, therefore, also known as “Synchronous Checkpointing”.
 In this scheme, the synchronization of processes is required for
checkpointing and so, extra checkpointing messages are required to be
exchanged between processes.

Contd. ….
 Independent Checkpoint
 Here, each process periodically checkpoints independent of other
processes. Upon failure, locate a consistent cut background.
 It needs to rollback until consistent cut is found.
 As processes take local checkpoints independent of each other, this
method is also referred to as independent checkpointing, its
implementation requires that dependencies are recorded in such a way
that processes can jointly rollback to a consistent global state.

Contd. ….
 Message Logging
 It is a common technique used to build systems that can tolerate
process crash failures.
 These protocols require that each process periodically records its local
state and log the messages received since recording that state.
 When a process crashes, then a new process is created in its place.
 An orphan process is a process that survives the crash of another
process but whose state is inconsistent with the crashed process after
its recovery.

UNIT-8 Security
1 UNIT- 9 Security 6/18/2023

Why Security in Distributed Systems?
• Distributed Systems rely on sharing of resources across different
networked entities
• Most vital/secret data handled by distributed components
• A single security flaw compromises the whole system

• Malware and viruses can spread from one part of the system to
another
easily
• Users across the world may have access to the system
• Cyber criminals, hackers
• Security lapses result in

• Loss of confidence, Claims for damages, Loss of privacy

Overview
Security
Management
Access Control • Key Management
• Access Control • Authorization
Secure Channels Matrix Management
• Protection Domains
• Authentication
Introduction • Message Integrity
and Confidentiality
• Threats, policies
and mechanisms
• Cryptography

Overview
Security
Introductory Cryptographic Secure

Concepts Systems Channels
Security Policy and

threats Mechanisms
Introduction to Security
• What services do you expect from secure Distributed

Systems?
• Secure DS should provide

• Confidentiality of Information
• Information is disclosed only to authorized parties
• Integrity of Information
• Alterations to system’s assets is made only in an authorized
way
Secure DS are immune against possible security threats that compromise

confidentiality and integrity

Security Threats
• What are the security threats when two entities
communicate?
Eve/
Chuck
Let us meet at 12 PM
Alice Bob

Types of Security Threats (1)
1. Interception
• Unauthorized party has gained access to
a Eve
service or data Alice: Let us
meet at 12 PM
• Example: Illegal copying of files, Alice Bob
Eavesdropping over network
2. Interruption
• Services or data become unavailable,
unusable or destroyed Eve
• Example: Denial-of-Service (DoS) Attacks

(*##0DF
Alice: Let* us
DF
meet!34#*
at 12 PM
Alice Bob

Types of Security Threats (2)
3. Modification
• Unauthorized changing of data or
tampering Eve
with services Alice: Let us meet
at12
at 3 PM
PM
• Example: Changing a program to Alice Bob
secretly log the activities
4. Fabrication
• Additional data or activity is
generated that would normally not Eve
exist Alice: Let us meet
at 12 PM
• Example: Replay attacks
Alice Bob

Security Policy and Mechanisms
• To build a secure DS, we need to
Formulate Security Policies Build Security Mechanisms
• Specifies what is to be done • Specifies how policies are

implemented
Describe the security requirements: Implement mechanisms to:
• which actions the entities are • Protect data transferred

allowed to take • Verify identity of an entity
• which actions are prohibited • Secure access permissions

Security Mechanisms
Four core components of security mechanisms
Cryptographic Algorithms and Secure Channels

1. Encryption
• Transform the data to something that attacker cannot understand
2. Authentication
• Verifies the claimed identity of the user, host or other entity
Access Control
3. Authorization
• Verifies if the entity is authorized to perform an operation
4. Auditing
• To trace which clients accessed what, and which way

Overview
Security

Types of Cryptographic
Protocols
systems hash functions

Cryptographic systems
• Cryptography is the study of techniques for secure communication
in the presence of third parties
Active Intruder
Passive can listen and
C modify C, and C
Intruder can
PInatsrsuidveerIntruder insert messages Active Intruder
listen to C C’
C=EK(P)
Plain text
message
P Encryption Communication Decryption P=DK(C)

Algorithm Channel Algorithm
Cipher text
Sender K K Receiver
Encryption key Decryption key
UNIT-C=E K(P) ➔ C is obtained by encrypting the plain text P with key K

9 Security
12 6/18/2023
4/15/2022 P=DK(C) ➔ P is obtained by decDrisytrpibtuitendgSytshteemcbyipPrhasehrantteGxauttaPmwith key K 12
Types of Cryptographic Systems
• Two types
1. Symmetric Cryptosystem (Shared-key system)
2. Asymmetric Cryptosystem (Public-key system)

Symmetric Cryptographic System
• Same key is used to encrypt and decrypt the data
𝑃 = 𝐷𝐾 𝐸𝐾 𝑃
• The shared key KA,B between Alice A and Bob B should

be kept secret
• Also known as secret-key or shared-key systems
𝐶
Alice Bob
𝐶 = 𝐸𝐾 𝑃 𝑃 = 𝐷𝐾 𝐶

Public-key Cryptographic System
• The key for encryption (KE) and decryption(KD) are different
• But, KE and KD form a unique-pair

𝑃 = 𝐷𝐾𝐷 𝐸𝐾𝐸 𝑃
• One of keys is made public, and another made private
• Denotation: Public key of A = 𝐾+ ; Private key of A = 𝐾−

𝐴 𝐴
• Public-key systems can be used for:

• Encryption
• Authentication

Encryption in Public-key system
• Scenario: Alice (A) wants to send to Bob (B)
• Problem: Only Bob should be able to decrypt the message
• Approach:
• At A: Encrypt using B’s public key
• At B: Decrypt using B’s private key
𝑚′
A B
𝑚′ = 𝐸𝐾+ 𝑚 𝑚 = 𝐷𝐾𝐵− 𝑚′
𝐵
Drawback: How does ‘B’ know that ‘A’ sent the message?

Authentication in Public-key system
• Scenario: Alice (A) wants to send a message to Bob (B)
• Problem: Bob wants to make sure that message came from Alice
(and
not from some intruder)
• Approach:
• At A: Encrypt using A’s private key
• At B: Decrypt using A’s public key
𝑚′
A B
𝑚′ = 𝐸𝐾𝐴− 𝑚 𝑚 = 𝐷𝐾+ 𝑚′
𝐴
Drawback: How to ensure that ONLY ‘B’ gets the message?

Combining encryption and authorization
• Scenario: Alice (A) wants to send a message to Bob (B)
• Many algorithms use a combination of the above two methods to:

• Ensure that only Bob can decrypt the message
• Bob can verify that Alice has sent the messages
𝑚′′
A B
𝑚′ = 𝐸𝐾𝐴− 𝑚 𝑚′ = 𝐷𝐾𝐵− 𝑚′′

𝑚′′ = 𝐸𝐾+ 𝑚′ 𝑚 = 𝐷𝐾+ 𝑚′
𝐵 𝐴
• Approach: Encrypt/Decrypt using a combination of keys
• A widely used method in many secure algorithms
• What happens if intruder ‘C’ modifies message ‘m’ sent by ‘A’?

Some part of message ‘m’ should contain data that is verifies the message

Cryptographic Hash Functions
• A hash function 𝐻(𝑚) maps an input message 𝑚 to a
hash value ℎ
• Message 𝑚 is of any arbitrary length
• Hash ℎ is fixed length
ℎ=𝐻 𝑚
• Often, ℎ is called as the “message digest” of 𝑚
• How does a cryptographic hash function differ from a

regular hash function?

Properties of Cryptographic Hash
Functions
1. One-Way Function
• Finding hash ℎ from 𝑚 is easy, but not vice-versa
• Computationally infeasible to find 𝑚 that corresponds to a given hash ℎ
2.Weak-collision resistance
• Given a message, it is hard to find another message that has the same
hash value
• Given 𝑚 and ℎ = 𝐻 𝑚 , it is computationally infeasible to find 𝑚′ ≠ 𝑚
such that
𝐻(𝑚) = 𝐻(𝑚 ′ )
3.Strong-collision resistance
• Given a hash function, it is hard to find two messages with the same
hash value
• Given 𝐻 . , it is computationally infeasible to find two messages 𝑚 and
𝑚′ such
that 𝐻(𝑚) = 𝐻(𝑚 ′ )

Encryption/Decryption Functions
• Recall: An encryption function 𝐸𝐾(𝑚𝑝) encrypts a plain-text
message
𝑚 𝑝 to an cipher-text message 𝑚𝑐 using a key 𝐾
𝑚𝑐 = 𝐸𝐾 𝑚𝑝
• Similarly, decryption function 𝐷𝐾 𝑚𝑐 :
𝑚 𝑝 = 𝐷𝐾 𝑚𝑐
• Encryption/Decryption Functions have the same

properties as Cryptographic Hash Functions
• One-way functions
• Weak and Strong collision resistance
Additional Properties of
Encryption/Decryption Functions
• Infeasible Key Extraction *
• Given a plain-text 𝑚 𝑝 and its cipher-text 𝑚 𝑐 , it is hard to find
the key
𝐾 such that 𝑚𝑐 = 𝐸𝐾 𝑚𝑝
• Key Collision Resistance *

• Given a plain-text and a key 𝐾, it is hard to find another key
𝐾′ that produces the same cipher-text
• Given a plain-text 𝑚 𝑝 and a key 𝐾 such that cipher-text 𝑚𝑐 =

𝐸𝐾 𝑚𝑝 , it is hard to find another key 𝐾′ that produces the
same cipher-text 𝑚𝑐

4/15/2022 Distributed System by Prashant Gautam 22
* Property names given are meant for understanding, and is not widely used in the community
Overview
Security

Cryptographic
Types of
hash Protocols
systems
functions
Symmetric Public-key
DES RSA Hybrid
systems systems

Protocols in Cryptosystems
• We will study three protocols in cryptosystems

• Data Encryption Standard (DES)
• Encryption/Decryption in Symmetric Cryptosystems
• RSA protocol
• Encryption/Decryption in Public-Key cryptosystems
• Hybrid Cryptographic protocol

• A combination of Symmetric and Public-Key based system

DES Protocol
• Purpose: Encryption/Decryption in Symmetric Cryptosystems
• Encryption and Decryption relies on a 56-bit master key (𝐾𝑀)

• Operates on a 64-bit block of input data to encrypt/decrypt
64-bit plain-text
... DES 64-bit Cipher-text
Encryption ...
KM Algorithm
56-bit key
64-bit Cipher-text
... DES 64-bit plain-text
Decryption ...
KM Algorithm
56-bit key

DES Encryption Algorithm
1. Permute a 64-bit block
2. 16 rounds of identical operations

Input block Master Key
3. In each round i ... KM
i. Divide the block into 2 halves Li and Ri
ii. Extract 48-bit key K ifrom K M L1 ...R1
Round 1
K1
iii. Mangle the bits in Li and Ri using Ki f(L1,R1,K1)
to produce Ri+1 L2 R2
iv. Extract Ri as Li+1
L15 R15
Round 16
K16
4. Perform an inverse permutation f(L16,R16,K16)
on the block L16-R16 to produce
L16 R16
the encrypted output block
...
Encrypted output block

Discussion about DES
• DES encryption and decryption is relatively fast
• DES has disadvantages of a Symmetric Cryptosystem

• Requires sender and receiver to exchange KM
• For N-user system, DES needs N(N-1)/2 master key pairs
• History of DES:
• DES was invented in 1974
• In 1997, it was shown that DES can be easily cracked using
brute-
force attacks
• Triple-DES is in use in some systems

• It applies DES three times using two keys

RSA protocol
• Invented by Rivest, Shamir and Adleman (RSA) as a
protocol for Public-key systems
• Approach:
1. Choose two very large prime numbers, p and q
2. Compute n = pq Example*
3. Compute z = (p-1)(q-1) p=7; q=19

4. Choose a number e that is relatively prime to n = 7*19 = 133
z
• e is co-prime to z z = 6*18 = 108
5. Compute the number d such that de % z = 1 e=5
• This is equivalent to
finding de = 1 + kz for
some integer k
d=65 for m=325
• Depending on the requirement, d and e can be used ic and private
as publ
keys
• d is used for decryption; e is used for encryption

4/15/2022 Distributed System by Prashant Gautam 28
* The numbers chosen in the example are for illustration. Prime numbers with 100s of digits are chosen in the actual RSA algorithm
Example: RSA protocol for
encryption (1)
• Scenario: Alice (A) wants to send to Bob (B)
• Problem: Only Bob should be able to decrypt the message
• Given d and e are the two keys computed by RSA, which row
indicates correct choice of keys?
Correct/ Alice Bob

Incorrect
Private Public Private Public 𝑚′
𝐾𝐴− 𝐾𝐴+ 𝐾𝐵− 𝐾𝐵+
A B
x d e
𝑚′ = 𝐸𝐾+ 𝑚 𝑚 = 𝐷𝐾𝐵− 𝑚′
x e d 𝐵
Correct d e
x e d

Example: RSA protocol for encryption (2)
Calculated Values
At the sender: p=7; q=19; n=133; d=65; e=5
Example
• Split the message into fixed-length blocks of
size s (0 <= s < n) s = 132
• For each block mi mi = 6

• Sender calculates the encrypted message ci such ci = 65 (mod 133)
that ci =mie (mod n) = 62
• Send ci to the receiver
At the receiver:
• Receive ci from sender
• For each block ci mi = 6265 (mod 133)
• Compute actual message m i = cid (mod n) =6
• Merge all ci’s to obtain the complete message

Discussion about RSA
• RSA has advantages of Public-key system

• Harder to break the code
• For a N-user system, RSA needs only 2N keys
• Computation time of RSA is much larger than DES

• Approximately 100-1000 times slower

Hybrid Cryptographic protocols
• Large scale distributed systems use a combination of symmetric

and public-key protocols
• Leveraging the advantages of both schemes

• Encryption based on Public-key are more secure
• Authenticate using RSA
• Exchange the “secret key” using RSA for a session
• Encryption based on Symmetric keys are faster

• Exchange large data using the above “secret key”

Beyond Cryptographic Mechanisms
• Many users, clients and servers need to dynamically

send messages in a distributed system
• How can an end-to-end secure distributed system be built using the
cryptographic mechanisms?
• How can each message and user be protected against security
threats?
• How do clients and processes authenticate?
• What protocols are needed for these? What is their complexity?

Overview
Security
Introductory Cryptographic
Secure Channels
Concepts Systems
Message Integrity
Cryptographic
Types of systems Protocols Authentication and
hash functions Confidentiality
Authentication
Shared Secret Key Authentication
using a Key
based using Public-key
Distribution
Authentication Cryptography
Center

Secure Channels
• A Secure Channel is an abstraction of secure communication

between communication parties in a DS
• A Secure Channel protects senders and receivers against:

• Interception
• By ensuring confidentiality of the sender and receiver
• Modification and Fabrication of messages
• By providing mutual authentication and message integrity
protocols
• We will study
• Authentication
• Confidentiality and Message Integrity

Authentication
• Consider a scenario where Alice wants to set up a
secure channel with Bob
• Alice sends a message to Bob (or trusted third party) for
mutual authentication
• Message integrity should be ensured for all communication

between
Alice and Bob
• Generate a “session key” to be used between Alice and Bob
• Session-keys ensure integrity and confidentiality
• When the channel is closed, the session key is destroyed

Types of Mutual Authentication Protocols
1. Shared Secret Key based Authentication

2. Authentication using a Key Distribution Center
3. Authentication using Public-key Cryptography

Shared Secret Key based Authentication
• The scheme is also known as “Challenge-Response protocol”
• Let KA,B be the shared secret key between Alice and Bob
The Challenge-Response Protocol

1. ‘A’ sends her identity to ‘B’
A
2. ‘B’ sends a challenge RB back to ‘A’
RB
3. ‘A’ responds to the challenge by encrypting
Alice
RB with KA,B (denoted by KA,B (RB)), and
Bob
KA,B (RB)
sending it back to ‘B’
RA
4. ‘A’ challenges ‘B’ by sending RA
5. ‘B’ responds to the challenge by sending KA,B (RA)
the encrypted message KA,B(RA)
4/15/2022 A and B are mutually autDhisetribnutteidcSaystteemdbyPrashant Gautam 39
Overview
Security
Management
Access Control • Key Management
• Access Control • Authorization
Secure Channels Matrix Management
• Protection Domains
• Authentication
Introduction • Message Integrity
and Confidentiality
• Threats, policies
and mechanisms
• Cryptography

Authentication Using a Key
Distribution Center
• Shared secret key based authentication is not
scalable
• Each host has exchange keys with every other host
• Complexity: O(N2)
• The complexity is reduced by electing one node as

“Key Distribution Center” (KDC)
• KDC shares a secret-key with every host
• No pair of hosts need to share a key
• Complexity: O(N)

Basic Model of a KDC based Authentication
Ticket
A, B
KDC
Alice
Bob
KA,KDC(KA,B) , KB,KDC(KA,B)
A, KB,KDC(KA,B)
• We will study a widely used KDC protocol called Needham-

Schroeder Authentication Protocol

Needham-Schroeder Authentication Protocol
• A multi-way challenge response protocol
Nonce: A random number that is used only once

What happens if:
1. Nonce is not included
Response to Nonce RA1
in M2?
Ticket 2. B is not included in
M1 M2?
RA1 , A, B
KDC
M2 3. RA2 is returned in M4,
KA,KDC(RA1 , B, KA,B , KB,KDC(A, KA,B) ) instead of
(RA2-1)?
Alice
Bob
M3
KA,B(RA2), KB,KDC(A,KA,B)
4. Chuck has an old key
M4 KA,B and intercepts
KA,B(RA2 -1, RB)
M3, and replays M3
M5
KA,B(RB -1) at a later point of
time to Alice?

Authentication Using a Public-Key Cryptography
• Recall:
• K+N: Public key of user N
• K-N: Private key of user N
K+B(A, RA)
Alice
Bob
K+A(RA, RB, KA,B )
KA,B (RB)

Overview
Security
Secure Channels
Concepts Systems
Message Integrity Secure Group

Authentication
and Confidentiality Communication
Shared Secret Key Authentication Authentication

based using a Key using Public-key
Authentication Distribution Center Cryptography

Message Integrity and Confidentiality
• Encryption is used for providing Confidentiality

• But, how to provide Message Integrity?
• Encryption protects message modification by third party
adversaries
• How to protect modification at senders or receivers?
What if Alice
What if Bob says denies that
that he had Both parties have to keep SIGNED she sent M1?
asked for $500
in M2?
versions of the messages
M1 I will buy your horse for $200

Alice Bob
M2 OK. Deal. $200
Digital Signatures
• The sender and the receiver will keep digitally signed

copies of the messages
• One way of creating digital signatures is by using RSA
m m
K-A m K+B K-B

m
K-A(m) K-A(m)
Alice’s Computer Bob’s Computer
Dig. Signed K+ (m, K- (m))

B A Bob saves the digitally
message of A signed message from A

Issues with Naïve Digital Signatures
• The validity of the digitally signed message holds as
long as
A’s private key remains a secret
• ‘A’ can claim that her private key was stolen
• If ‘A’ changes her private key, the signed message

becomes
invalid
• A centralized authority can keep track of when keys are
changed
• Encrypting the entire message with private key is costly

• RSA is slower, and encryption of long data is not preferred
• Any ideas on how to improve?

Digital Signature with Message Digest
• Instead of attaching the encrypted message, attach the

message digest
m m
m K+B K-B m
-
Hash H(m) KA
K-A(H(m)) K-A(H(m))
Alice’s Computer Bob’s Computer
K+B(m, K -A(H(m))) Bob saves the digitally

signed message from A
Bob can verify the signature by comparing the hash of received message, and the
hash attached in the digitally signed message

Overview
Security
Secure Channels
Concepts Systems
Message
Secure Group
Authentication Integrity and Communication
Confidentiality

Secure Group Communication
• Scenario: Client has to communicate with a group of replicated
servers
• Replication can be for fault-tolerance or performance improvement
• Client expects that the response is secure
• Naïve Solution:
• Client collects the response from each server
• Client authenticates every response
• Client takes a majority vote
• Drawback of naïve approach

• Replicated of servers should be transparent to the client
• Reiter et al. proposed a transparent and secure group authentication
protocol (Secure Group Authentication Protocol)

Secure Group Authentication Protocol
• Problem: Authenticate a group of replicated servers at the client in
a transparent way
• Main Idea:
• Multiple servers share a secret
• None of them know the entire secret
• Secret can be revealed only if all/most of them cooperate
• The approach is similar to k-fault tolerant systems

• Tolerate intrusion (faults) of c servers out of N servers if c <= N
• We will study the algorithm in two phases:

1. Generating Shared Secret Signatures
2. Enhancing transparency

1. Generating Shared Secret Signatures
• For each client call: Parameters: N=5; c=2
• Each server Si returns the response (ri)
• In addition, it sends a signed message
S1 S2 S3 S4 S5
digest: sig(Si,r i) = K- si( md(r i) )
• For each response, client computes
mdc (ri) = H(ri)
sig(S1,r1) r1
• Hence, client has N triplets sig(S2,r2) r2
Select another
Ri = < ri, mdc (ri), sig(Si,ri)> sig(S3,r3) combination r3
Hash
sig(S4,r4) r4
• Client takes c+1 combinations of triplets sig(S5,r5) r5
No
• For each combination vector [R, R’ and R’’] d
• Computes a create a single digest using mdc (r1)
a special decryption function D(V) D(V) d=md(r) mdc (r 2)

mdc (r3)
d = D(V) = D(sig(S,r), sig(S’,r’),sig(S’’,r’’)) Yes
mdc (r4)
NOTE: d is a vector of responses r is OK mdc (r 5)
Client
• If d[x] = respective mdc (ri), then ri is correct

2. Enhancing transparency
• Each server broadcasts a message [ri,sig(Si,ri)] to other servers
• When the server has received k+1 messages

• Compute valid signature D(V) for one combination of responses r
• If success, then transmit [V,r] to the client
• When client receives a response, it re-verifies the correctness of

r

Discussion: Secure Group Authentication
Protocol
• The protocol can be generalized to (m,n)-threshold

scheme
• A message is divided into n-pieces (shadows)
• m shadows can be used to reconstruct the message
• (m-1) or fewer shadows cannot reconstruct
• In the above protocol:

• m = c+1 = Number of valid signatures required
• n = N = Number of replicated servers

Overview
Security
Introductory Cryptographic Security

Secure Channels Access Control
Concepts Systems Management
Message
Secure Group General Access Controlling
Authentication Integrity and
Communication Control Issues outsider attacks
Confidentiality
Access Control
Access Control Protection Controlling DoS
List and Firewalls
Matrix Domains Attacks
Capabilities

Access Control
• Access Control (AC) verifies the access rights of a subject requesting an

access to an object
Request an operation
Subject Object
• A General model for Access Control

Request an Authorized
operation Reference request
Subject Object
Monitor
• A reference monitor records which subjects may do what
• How is Access Control different from Authorization?

• Authorization = granting access rights
• Access Control = verifying access rights

Access Control Matrix
• A matrix M that keeps track of which operations can a subject invoke on

an object Objects
• M [s,o] lists which operations subject s can perform on
O1 Om
object o
S1
Subjects
• The reference monitor will look up AC Matrix S2
before authorizing the request

Sn
• Scalability of AC Matrix
• For a large DS with many users, most of the entries R W X
√ x x
are empty
• Two implementations of AC Matrix:

1. Access Control Lists
2. Capabilities

1. Access Control List
• AC Matrix is stored as a list

• Similar to how a graph of nodes and edges are stored as an adjacency
list
Obj 1 Sub 1 Sub 5 Sub x
Obj 2 Sub 3 Sub 5
Obj m Sub 5 Sub n
R W X
√ x x

2. Capabilities
• AC Matrix can also be decomposed row-wise
• Capability for a user is a list of objects and the associated permissions

for a given user
Sub 1 Obj 1 Obj 5 Obj y
R W X
√ x x
• The ‘capability’ object can be issued by Reference Monitor to a user, and

can reside at the user side
• But should be protected (digital signature)

Comparison of ACL and Capabilities
Using ACL Using Capabilities
Create Access ACL Obj-r Create Access Obj-r

Request to (s,r) Request to (s,r) C
if (s in ACL &&
Object r as Object r as
r in ACL) if (r in C)
Subject-s Subject-s. Pass
grant access; grant access;
capability C
Client Server
Client Server
• The server is not interested in

The server stores the ACL whether it knows the client
• Server should check Capability

Protection Domains
• Motivation: Access Control using ACL and Capabilities is still not scalable in
very large DS
Objects
O1 Om
• Organizing Permissions: PD1
Protection
Domains
• Object permission is given to a protection domain (PD) PD2
• Each PD row consists of (object, permission) pair

PDn
• User Management: PD: Admin
• Group uses into a “protection domain” R W X
• Users belong to one or more protection domain √ √ √
• e.g., employees, admin, guests

PD: Employees
• Before granting the access, check permissions
R W X
from user’s PDs √ x √
PD: Guests
R W X
61 UNIT- 9 Security x 6/18/2023
x x
69
A matrix 4is/1s5h/2o0w22nonly for representation. Similar to AC MDisattrribiuxt,ePdDSysctaemnbbyePirmashpalnetmGaeuntatmedusing
techniques similar to ACL
Hierarchical Protection Domains
• Domains can be organized into hierarchical groups
• Advantage
• Managing group membership is easy World
• Disadvantage World Anonymous
• Looking up for a member is costly

Emp_AMS Emp_NY Emp_SFO
• An optimization:
• Let each user carry a certificate of all the
groups they belong to
• Reference monitor validates the certificate
(similar to the Capabilities approach)

Overview
Security
Introductory Cryptographic Secure Security

Access Control
Concepts Systems Channels Management
Controlling
General Access
outsider
Control Issues attacks
Access Control
Access Control Protection Controlling DoS
List and Firewalls
Matrix Domains Attacks
Capabilities

Controlling Outsider Attacks
• Above discussed schemes are good for preventing against small

number of users who belong to a DS
• But, what if any user on the Internet can access the resources
of DS
• Search engines, Sending mails, …
• Above approaches are complicated, inefficient and time-

consuming when a DS is exposed to the rest-of-the-world
• We discuss two coarse grained Access Control schemes

• Firewall
• Controlling Denial of Service (DoS) attacks

Firewall
• Firewall provides access control by regulating the flow of network
traffic to/from
a LAN
• Firewall disconnects any part of the DS from outside world

• The internal LANs route packets through Packet Filtering
Routers (PFR) and Application Gateway (AG)
• Incoming/outgoing packet contents (e.g., src/dest IP) are examined by
PFRs
• PFRs selectively forward the incoming/outgoing packets to/from AG
Connections to Packet Packet Connections to

the internal Filtering Application Filtering the external
network Router Gateway Router network
Internal LAN External LAN

Denial of Service Attacks
• Denial of Service (DoS) attacks maliciously

prevents authorized processes from accessing the
resources
• Example: Flood a search server with TCP requests
• DoS attacks from a single source can be easily

prevented
• Triggering DoS attacks from multiple sources

(Distributed DoS or DDoS) is hard to detect
• Attackers hijack a large group of machines
• DDoS is hard to detect

Types of DoS Attacks
Two types
1. Bandwidth Depletion
• Send many messages to a server
• Normal messages cannot reach the server
2. Resource Depletion
• Trick the server to allocate large amount of resources
• Example: TCP SYN flooding
• Initiate a lot of TCP connections on server (by
sending TCP SYN packets)
• Do not close the connections
• Each connection request blocks some memory for some
time

Preventing DoS Attacks
Idea: Detect DDoS by continuously monitoring network traffic at
routers
Three types:
• Monitor at ingress routers:
• Monitor incoming traffic for large flow towards a destination
• Drawback: Too late to detect since regular traffic is already blocked
• Monitor at egress routers:

• Monitor traffic when packets leave organization’s network
• e.g., Drop packets whose source IP does not belong to the org’s network
• Monitor at core internet routers:

• Monitor at routers at the core of the Internet Service Providers (ISPs)
• e.g., Drop packets when rate of traffic to a specific node is
disproportionately larger
than the rate of traffic from that node

Overview
Security
Introductory Cryptographic Secure Access Security

Concepts Systems Channels Control Management
General Controlling
Key
Access outsider
Management
Control Issues attacks
Controlling Key Key

Firewalls
DoS Attacks Generation Distribution

Key Management
• We have studied how to use keys for authentication and
encryption
• Examples of key-generation that we studied:

• Session key
• Generated and distributed by public-private key pair
• Public-Private Key
• Generated by algorithms. How is it securely distributed?
• How to boot-strap secure key generation and distribution in a

DS?
• There are two main approaches in key management:

• Diffie-Hellman Algorithm (For key generation over insecure channels)
• Key distribution

Diffie-Hellman Key Generation
• Diffie-Hellman algorithm establishes a shared key between two entities

across an insecure channel

Diffie-Hellman Algorithm
Alice Eve Bob
Selects two large numbers n and g with

certain mathematical properties
Choose a secret number x Choose a secret number y
Alice transmits [n, g, gx mod n] n, g, y, n, g, gx mod n

gx mod n
n, g,
x y
n, g, x, g mod n, g mod n gx mod n, Bob transmits [gy mod n]
gy mod n
Alice computes Bob computes

(gy mod n)x = gxy mod n (gx mod n)y = gxy mod n
SHARED SECRET KEY = SHARED SECRET KEY =

gxy mod n gxy mod n

Discussion of Diffie-Hellman
Algorithm
• D-H algorithm can be used in:

• Symmetric Cryptosystems
• Secret key gxy mod n can be generated between A and
B even in
the presence of insecure channel
• Public-key Cryptosystems
• A’s private key = x
• A’s public key = gx mod n
• But, how to securely distribute public keys?

Key Distribution
• Key distribution in Symmetric Cryptosystems

• Out-of-band key exchange
• Diffie-Hellman algorithm
• Complex for a large DS
• Key distribution in Public-key Cryptosystems

• Main problem: How do we authenticate the entity that
transmitted
the public key?
• We will study an approach called Public-key certificates

Public-key Certificate
• In practice, we trust a well-know Certification Authority (CA)
• Example of a CA: VeriSign
• Public key of CA (K+ CA) is well-known

• e.g., It is built-in with browsers
• How does Bob validate public key of Alice?

• Each user (Alice) has a public-key certificate cert(A, K+ A) that issued by CA
• Bob verifies if the received (A, K+ A) matches that in the certificate

High-level Summary of Security Chapter
Security
Introductory Cryptographic Secure Access Security

Concepts Systems Channels Control Management

Summary of “Introductory Concepts”
and “Cryptographic Systems”
Security
Concepts Systems
Cryptographic
Security Policy and Types of
hash Protocols
threats Mechanisms systems
functions
Symmetric Public-key
DES RSA Hybrid
systems systems

Summary of “Secure Channels”
Security
Secure Channels
Message Integrity
Secure Group
Authentication and
Communication
Confidentiality
Authentication
Shared Secret Key Authentication
using a Key
based using Public-key
Distribution
Authentication Cryptography
Center

Summary of Security Chapter
Security
Security
Access Control
Management
Controlling
General Access Key
outsider
Control Issues attacks Management
Access Control
Access Control Protection Controlling DoS Key
List and Firewalls Key Generation
Matrix Domains Attacks Distribution
Capabilities


Distributed System (CACS 352) : Compiled by

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Distributed System (CACS 352) : Compiled by

Uploaded by

Copyright:

Available Formats

Course Title:

VIII. Performance Transparency

IX. Scaling Transparency

 A distributed system can be classified

o A server host runs one or more server programs,

o In a sense, middleware is the same to a distributed

1. Advantages/ Merits/ Pros of Distributed System.

Compiled by Ujjwal Rijal

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 1

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 2

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 3

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 4

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 5

Fig: Layered Architecture of Distributed System

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 6

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 7

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 8

 Object Based Architecture

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 9

Fig: Object Based Architecture of Distributed System

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 10

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 11

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 12

Fig: Data Centred Architecture of Distributed System

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 13

 Event Based Architecture

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 14

Fig: Event Based Architecture of Distributed System

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 15

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 16

Fig: Middleware in Distributed System

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 17

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 18

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 19

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 20

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 21

Compiled by Ujjwal Rijal

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 1

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 2

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 3

Fig: Layout of a process inside main memory

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 4

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 5

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 6

Fig: Process state diagram

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 8

IV. Waiting or Blocked

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 9

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 10

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 11

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 12

Fig: Process Hierarchy

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 13

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 14

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 15

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 16

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 17

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 18

• Thread can be implemented in the following two ways:

Now, they are discussed below:

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 19

Compiled by Ujjwal Rijal || rijalujjwal09@gmail.com 20