CHAPTER 2

COMMUNICATION IN DISTRIBUTED SYSTEM

COMMUNICATION IN DISTRIBUTED SYSTEMS

The most important difference between a distributed system and a uniprocessor system
is the interprocess communication.

Interprocess communication (IPC) is a set of programming that allows a programmer

to coordinate activities among different program s that can run concurrently in an
operating system.

 In a uniprocessor system, interprocess communication assumes the existence of

shared memory whereas in a distributed system, there‟s no shared memory, so the
entire nature of interprocess communication must be completely reframed from
scratch.
 All communication in distributed system is based on message passing.
 The processes run on different machines and they exchange information through
message passing.
 Successful distributed systems depend on communication models that hide or
simplify message passing.

SYSTEM MODELS
System models describe common properties and design choices for distributed system
in a single descriptive model. The system models of distributed systems are classified into the
following types:
27
 Distrubuted Systems 2.2

 Physical models: It is the most explicit way in which to describe a system in terms
of hardware composition.
 Architectural models: They describe a system in terms of the computational and
communication tasks performed by its computational elements.
 Fundamental models: They examine individual aspects of a distributed system.
They are again classified based on some parameters as follows:
 Interaction models: This deals with the structure and sequencing of the
communication between the elements of the system
 Failure models: This deals with the ways in which a system may fail to
operate correctly
 Security models: This deals with the security measures implemented in the
system against attempts to interfere with its correct operation or to steal its
data.

Physical Models

A physical model is a representation of the underlying hardware elements of a distributed system hide

There are many physical models available from the primitive baseline model to the
complex models that could handle cloud environments.
 Baseline physical model:
 This is a primitive model that describes the hardware or software components
located at networked computers.
 The communication and coordination of their activities is done by passing
messages.

 This is a minimal physical model of a distributed system.

 This model could be extended to a set of computer nodes interconnected by a

computer network for the required passing of messages.

 This model helps us to categorize the three generations of distributed systems.

 Early distributed systems:

 The period is in the late 1970s and early 1980s.

 This was developed after the emergence LAN.

27
 Distrubuted Systems 2.3

 These systems could support 10 to 100 nodes interconnected by a LAN.

 It has very limited internet connectivity and can support a small range of
services such as shared local printers and file servers.

 Individual systems were homogeneous, with poor quality of service.

 Internet-scale distributed systems:

 The period is from the 1990s after the growth of internet.

 The physical set up of distributed system is described as an extensible set of

nodes interconnected by a network of networks (the Internet).

 They incorporate large numbers of nodes and provide distributed system

services.

 The systems were heterogeneous which could adopt open standards.

 They had good QOS.

 Contemporary distributed systems:

 The nodes were desktop computers and therefore relatively static, discrete and
independent.

 Mobile computing has led to physical models with movable nodes. Service
discovery is of primary concern in these systems.

 The cloud computing and cluster architectures hassled to pools of nodes that
collectively provide a given service. This resulted in enormous number of
systems given the service.

 Distributed systems of systems:

The ultra large scale (ULS) distributed systems is defined as a complex system
consisting of a series of subsystems that are systems in their own right and that come
together to perform a particular task or tasks. Some important characteristics of these
systems include their
 very large size
 global geographical distribution

 operational and managerial independence of their member systems.

The main function of these systems arises from the interoperability between their
components.
27
 Distrubuted Systems 2.4

Example: Flood monitoring systems.

Parameter Early Systems Internet Scale ULS System

Scale Small Large Ultra Large
Heterogeneity Homogeneous Platform independent Supports many types
software and technologies. of architectures
Openness Systems are mostly Many open standards are The already existing
closed available standards are not able
to cope with complex
systems.
QOS Poor Significant QOS could still be
improved

The architecture abstracts the functions of the individual components of the distributed system.

Architectural Models

This describes the components and their interrelationships to ensure the system is
reliable, manageable, adaptable and cost-effective. The different models are evaluated based
on the following criteria:
 architectural elements
 architectural patterns
 middleware platforms

Architectural elements
The following must be decided to build a distributed system:
 Communicating entities (objects, components and web services);
 Communication paradigms (inter process communication, remote invocation
and indirect communication);
 Roles responsibilities and placement
Communicating entities
The components that are communicating and how those entities communicate together
are dealt here. The following are some of the problem oriented entities:
27
 Distrubuted Systems 2.5
 Objects: They are used to implement object oriented approaches in distributed
systems. Objects are accessed through interfaces.
 Components: Components resemble objects and they offer problem-oriented
abstractions for building distributed systems. They are also accessed through
interfaces. The key difference between component and object is that a components
holds all the assumptions specified to other components and their interfaces in the
system. Components and objects are used to develop tightly coupled applications.
 Web services: Web services are closely related to objects and components. Web
services are integrated into the World Wide Web. They are partially defined by the
web-based technologies they adopt. Web services are generally viewed as
complete services that can be combined to achieve value-added services across
organizational boundaries.

Object Components Web services

Object oriented solution Problem oriented solution Problem oriented solution
The dependencies and The dependencies and They are integrated into the
assumptions of the interfaces assumptions of the all WWW.
holds only on the objects that interfaces holds on all the
act upon them. components in the system.
Tightly coupled services Tightly coupled services Complete service that could
also be made as a value added
service

Communication paradigms
There are three major modes of communication in distributed systems:
 Interprocess communication:
This is a low-level support for communication between processes in distributed
systems, including message-passing primitives. They have direct access to the API
offered by Internet protocols and support multicast communication.
 Remote invocation:
It is used in a distributed system and it is the calling of a remote operation,
procedure or method.
a) Request-reply protocols:
This is a message exchange pattern in which a requestor sends a request message
to a replier system which receives and processes the request, ultimately returning a
message in response. This is a simple, but powerful messaging pattern which
allows two applications to have a two-way conversation with one another over a
channel. This pattern is especially common in client–server architectures.
27
 Distrubuted Systems 2.6

b) Remote procedure calls: Remote Procedure Call (RPC) is a protocol that one
program can use to request a service from a program located in another computer
in a network without having to understand network details.
c) Remote method invocation: RMI (Remote Method Invocation) is a way that a
programmer can write object-oriented programming in which objects on different
computers can interact in a distributed network. This has the following two key
features:
 Space uncoupling: Senders do not need to know who they are sending to
 Time uncoupling: Senders and receivers do not need to exist at the same time
 Indirect communication
Key techniques for indirect communication include:
a) Group communication: Group communication is concerned with the delivery
of messages to a set of recipients and hence is a multiparty communication
paradigm supporting one-to-many communication. A group identifier uniquely
identifies the group. The recipients join the group and receive the messages.
Senders send messages to the group based on the group identifier and hence do
not need to know the recipients of the message.
b) Publish-subscribe systems: This is a messaging pattern where senders
of messages, called publishers, do not program the messages to be sent directly
to specific receivers, called subscribers. Instead, published messages are
characterized into classes, without knowledge of what, subscribers there may
be. Similarly, subscribers express interest in one or more classes, and only
receive messages that are of interest, without knowledge of what, if any,
publishers there are. They offer one-to-many style of communication.
c) Message queues: They offer a point-to-point service whereby producer
processes can send messages to a specified queue and consumer processes can
receive messages from the queue or be notified of the arrival of new messages
in the queue. Queues therefore offer an indirection between the producer and
consumer processes.
d) Tuple spaces: The processes can place arbitrary items of structured data,
called tuples, in a persistent tuple space and other processes can either read or
remove such tuples from the tuple space by specifying patterns of interest. This
style of programming is known as generative communication.
e) Distributed shared memory: In computer architecture, distributed shared
memory (DSM) is a form of memory architecture where the (physically
separate) memories can be addressed as one (logically shared) address space.
Here, the term shared does not mean that there is a single centralized memory
but shared essentially means that the address space is shared (same physical
address on two processors refers to the same location in memory
27
 Distrubuted Systems 2.7

Roles and responsibilities

There are two types of architectures based on roles and responsibilities:

1) Client-server:
 The system is structured as a set of processes, called servers, that offer services
to the users, called clients.
 The client-server model is usually based on a simple request/reply protocol,
implemented with send/receive primitives or using remote procedure calls
(RPC) or remote method invocation (RMI).

 The client sends a request (invocation) message to the server for some
asking service; - the server does the work and returns a result (e.g. requested)
the data or an error code if the work could not be performed.
 A server can itself request services from other servers; thus, in this new
relation, the server itself acts like a client.

 Some problems with client-server are centralization of service ng in poor

resulti scaling, limited capacity of server bandwidth of network he server.

Figure 2.1: Client server style

2) Peer-peer
 All processes (objects) play similar role.
 Processes (objects) interact without particular distinction between clients and
servers.
 The pattern of communication depends on the particular application.
 A large number of data objects are shared; any individual computer holds only
a small part of the application database. 27
Distrubuted Systems 2.8

27
 Distrubuted Systems 2.9

2.8 Communication ni Distrubuted Sytem

Processin across man
This is the g and communication loads for access to ts are distributed
objec y computers and access links.
most general and flexible model.

Figure 2.2: Peer-peer style

 Peer-to-Peer model distributes shared resources widely share computing and
communication loads.
 Problems with peer-to-peer are high complexity due to cleverly place
individual objects and there are large number of replicas.

Placement
Mapping of objects or services to the underlying physical distributed infrastructure is
considered here. The following points must be taken care while placing the objects: reliability,
communication pattern, load, QOS etc. The following are the placement strategies:
 Mapping of services to multiple servers
 The servers may partition the set of objects on which the service is based and
distribute those objects between themselves, or they may maintain replicated
copies of them on several hosts.
 The Web provides a common example of partitioned data in which each web
server manages its own set of resources. A user can employ a browser to access
a resource at any one of the servers.
 Caching
 A cache is a local store of recently used data objects that is closer to one client
or a particular set of clients than the objects themselves.
 When a new object is received from a server it is added to the local cache store,
replacing some existing objects if necessary.
27
 Distrubuted Systems 2.9

 When an object is needed by a client process, the caching service first checks
the cache and supplies the object from there if an up-to-date copy is available.
If not, an up-to-date copy is fetched.
 Caches may be co-located with each client or they may be located in a proxy
server that can be shared by several clients.
 Mobile code:
 Applets are a well-known and widely used example of mobile code.
 The user running a browser selects a link to an applet whose code is stored on a
web server; the code is downloaded to the browser and runs.
 They provide interactive response.

 Mobile agents:
 A mobile agent is a running program (including both code and data) that
travels from one computer to another in a network carrying out a task on
someone‟s behalf, such as collecting information, and eventually returning
with the results.
 A mobile agent is a complete program, code + data, that can work (relatively)
independently.
 The mobile agent can invoke local resources/data.
 A mobile agent may make many invocations to local resources at each site it
visit.
 Typical tasks of mobile agent includes: collect information , install/maintain
software on computers, compare prices from various vendors bay visiting their
sites etc.
 Mobile agents (like mobile code) are a potential security threat to the resources
in computers that they visit.

Architectural patterns
Architectural patterns are reusable solution to a commonly occurring problem
in software architecture within a given context. They are not complete solutions but rather
offer partial insights. The following are some of the common architectural patterns:

 Layering:
 In a layered approach, a complex system is partitioned into a number of
layers, with a given layer making use of the services offered by the layer
below.
27
 Distrubuted Systems 2.1
0

Figure 2.3: Layered Architecture

 A given layer is unaware of the implementation details, of other layers
beneath them.
 In terms of distributed systems, this equates to a vertical organization of
services into service layers.
 A distributed service can be provided by one or more server processes,
interacting with each other and with client processes in order to maintain a
consistent system-wide view of the service‟s resources.

 Tiered architecture
 Tiering is a technique to organize functionality of a given layer and place
this functionality into appropriate servers and, as a secondary
consideration, on to physical nodes.
 The two tiered architecture refers to client/server architectures in which the
user interface (presentation layer) runs on the client and the database
(data layer) is stored on the server. The actual application logic can run on
either the client or the server.
27
 Distrubuted Systems 2.1
1

Fig 2.4: Two and three tiered architectures

 The three tiered architecture has:
a) Presentation tier: This is the topmost level of the application. is
concerned with handling user interaction and updating the view of the
application as presented to the user;
b) Application tier (business logic, logic tier, or middle tier): The
logical tier is pulled out from the presentation tier and, as its own layer,
it controls an application‟s functionality by performing detailed
processing.
c) Data tier: The data tier includes the data persistence mechanisms
(database servers, file shares, etc.) and the data access layer that
encapsulates the persistence mechanisms and exposes the data.
 Thin clients
 In a thin-client model, all of the application processing and data
management is carried out on the server.
 The client is simply responsible for running the responsible for running the
presentation software.
 This is used when legacy systems are migrated to client server
architectures.
27
 Distrubuted Systems 2.1
2
 The legacy system acts as a server in its own right with a graphical
interface implemented on a client.
 The major disadvantages of thin clients is that it places a heavy processing
load on both the server and the network and the delay due to operating
system latencies.
 The virtual network computing(VNC) has emerged to overcome the
disadvantages og thin clients.
 VNC is a type of remote-control software that makes it possible to control
another computer over a network connection.
 Keystrokes and mouseclicks are transmitted from one computer to another,
allowing technical support staff to manage a desktop, server, or other
networked device without being in the same physical location.
 Since all the application data and code is stored by a file server, the users
may migrate from one network computer to another. So VNC is of big use
in distributed systems.
 Other patterns
a) Proxy:
 This facilitates location transparency in remote procedure calls or remote
method invocation.
 A proxy is created in the local address space to represent the remote object
with same interface as the remote object.
 The programmer makes calls on this proxy object and he need not be aware
of the distributed nature of the interaction.
b) Brokerage:
 It is used to bring interoperability in potentially complex distributed
infrastructures.
 The service broker is meant to be a registry of services, and stores
information about what services are available and who may use them.

Fig 2.5: Web service with brokers

27
 Distrubuted Systems 2.1
3
c) Reflection:
 The Reflection architectural pattern provides a mechanism for changing
structure and behavior of software systems dynamically.
 It supports the modification of fundamental aspects, such as type structures
and function call mechanisms.
 In this pattern, an application is split into two parts:
1) Meta Level: This provides information about selected system
properties and makes the software self-aware.
2) Base level: This includes the application logic. Its implementation
builds on the meta level. Changes to information kept in the meta level

Middleware is a general term for software that serves to "glue together" separate, often complex and

affect subsequent base-level behavior.

2 2.2.3 Associated middleware solutions

Middleware provides a higher-level programming abstraction for the development of
distributed systems. Middleware makes it easier for software developers to perform
communication and input/output, so they can focus on the specific purpose of their
application. Middleware is the software that connects software components or enterprise
applications and it lies between the operating system and the applications on each side of a
distributed computer network. Middleware includes Web servers, application servers, content
management systems, and similar tools that support application development and delivery.

Categories of middleware
The following are some of the categories of middleware:
 Distributed Objects
The term distributed objects usually refers to software modules that are designed to
work together, but reside either in multiple computers connected via a network or
in different processes inside the same computer. One object sends a message to
another object in a remote machine or process to perform some task. The results
are sent back to the calling object.
 Distributed Components
A component is a reusable program building block that can be combined with
other components in the same or other computers in a distributed network to form
an application. Examples: a single button in a graphical user interface, a small
interest calculator, an interface to a database manager. Components can be
27
 Distrubuted Systems 2.1
4
deployed on different servers in a network and communicate with each other for
needed services. A component runs within a context called a container .
Examples: pages on a Web site, Web browsers, and word processors.
 Publish subscriber model
Publish–subscribe is a messaging pattern where senders of messages, called
publishers, do not program the messages to be sent directly to specific receivers,
called subscribers. Instead, published messages are characterized into classes,
without knowledge of what, if any, subscribers there may be. Similarly,
subscribers express interest in one or more classes, and only receive messages that
are of interest, without knowledge of what publishers are there.
 Message Queues
Message queues provide an asynchronous communications protocol, meaning that
the sender and receiver of the message do not need to interact with the message
queue at the same time. Messages placed onto the queue are stored until the
recipient retrieves them. Message queues have implicit or explicit limits on the size
of data that may be transmitted in a single message and the number of messages
that may remain outstanding on the queue.
 Web services
A web service is a collection of open protocols and standards used for exchanging
data between applications or systems. Software applications written in various
programming languages and running on various platforms can use web services to
exchange data over computer networks like the Internet in a manner similar to
inter-process communication on a single computer. This interoperability (e.g.,
between Java and Python, or Windows and Linux applications) is due to the use of
open standards.
 Peer to peer
Peer-to-peer (P2P) computing or networking is a distributed application
architecture that partitions tasks or work load between peers. Peers are equally
privileged, equipotent participants in the application. They are said to form a peer-
to-peer network of nodes.
Advantages of middleware
 Real time information access among systems.
 Streamlines business processes and helps raise organizational efficiency.
 Maintains information integrity across multiple systems.
 It covers a wide range of software systems, including distributed Objects and
components, message-oriented communication, and mobile application support.
 Middleware is anything that helps developers create networked applications.
27
 Distrubuted Systems 2.1
5
Disadvantages of middleware
 Prohibitively high development costs.
 There are only few people with experience in the market place to develop and use
a middleware.

 There are only few satisfying standards.

 The tools are not good enough.
 Too many platforms to be covered.
 Middleware often threatens the real-time performance of a system.

Fundamental Models are concerned with a formal description of the properties that are common in a

 Middleware products are not very mature.

Fundamental Models
Models addressing time synchronization, message delays, failures, security issues are
addressed as:

 Interaction Model – deals with performance and the difficulty of setting of

time limits in a distributed system.

 Failure Model – specification of the faults that can be exhibited by processes

 Secure Model – discusses possible threats to processes and communication

channels.

The purpose of the fundamental model is to:

 make explicit all the relevant assumptions about the systems we are modelling.

 make generalizations (general purpose algorithms) concerning what is possible

or impossible with given assumptions.

Interaction model

 In this model the computations occurs within processes.

 The processes interact by passing messages to achieve communication

(information flow) and coordination (synchronization and ordering of activities)
between processes.
27
 Distrubuted Systems 2.1
6
 The two significant factors affecting interacting processes in a distributed system
are:

1) Communication performance
2) Global notion of time.

Communication Performance
 The communication channel in can be implemented in a variety of ways in
distributed systems: Streams or through simple message passing over a network.
 The performance characteristics of a network are:
a) Latency: A delay between the start of a message‟s transmission from one
process to the beginning of reception by another.
b) Bandwidth: The total amount of information that can be transmitted over in a
given time. The communication channels using the same network, have to
share the available bandwidth.
c) Jitter: The variation in the time taken to deliver a series of messages. It is very
relevant to multimedia data.

Global Notion of time

 Each computer in a distributed system has its own internal clock, which can be
used by local processes to obtain the value of the current time.
 Any two processes running on different computers can associate timestamp with
their events.
 However, even if two processes read their clocks at the same time, their local
clocks may supply different time because the computer clock drifts from perfect
time and their drift rates differ from one another.
 Even if the clocks on all the computers in a distributed system are set to the same
time initially, their clocks would eventually vary quite significantly unless
corrections are applied.
 There are several techniques to correct time on computer clocks.
 One technique is to use radio receivers to get readings from GPS (Global
Positioning System) with accuracy about 1 microsecond.

Variants of Interaction model

 In a DS it is hard to set time limits on the time taken for process execution,
message delivery or clock drift. There are two models based on time stamp:
27
 Distrubuted Systems 2.1
7
 Synchronous DS
 This is practically hard to achieve in real life.
 In synchronous DS the time taken to execute a step of a process has known
lower and upper bounds.
 Each message transmitted over a channel is received within a known
bounded time.
 Each process has a local clock whose drift rate from real time has known
bound.
 Asynchronous DS
 There are no bounds on: process execution speeds, message transmission
delays and clock drift rates.

Event Modeling
 Event ordering is of major concern in DS.
 The concept of one event happening before another in a distributed system is
examined, and is shown to define a partial ordering of the events.
 The execution of a system can be described in terms of events and their ordering
despite the lack of accurate clocks.
 Consider a mailing list with users X, Y, Z, and A.
 Due to independent delivery in message delivery, message may be delivered in
different order.
 If messages m1, m2, m3 carry their time t1, t2, t3, then they can be displayed to
users accordingly to their time ordering.
 The mail box is:

Item From Subject

23 Z Re: Meeting

24 X Meeting

26 Y Re: Meeting
27
 Distrubuted Systems 2.18
send receive receive
X
1 m1 4
m2
send
2 3 receive
Y Physical
receive time

send
Z
receivereceive

m3m1m2
A receive receivereceive t3

t1 t2

Fig 2.6: Ordering of events

Failure Model
In a DS, both processes and communication channels may fail – i.e., they may depart
from what is considered to be correct or desirable behavior. The following are the common
types of failures:
 Omission Failure

 Arbitrary Failure
 Timing Failure

a) Omission failure
Omission failures occur due to communication link failures. They are detected through
timeouts. They are classified as:

 Process omission failures

 Omission failures that occur due to process crash (i.e.) the execution of
the process could not continue.
 This is detected using timeouts.

 A fixed period of time is fixed for all the methods to complete its
execution. If the method takes time longer than the allowed time, a time
out has occurred.
 In an asynchronous system a timeout can indicate only that a process is
not responding.
 A process crash is called fail-stopif other processes can detect certainly
that the process has crashed.
27
 Distrubuted Systems 2.19

 Fail-stop behavior can be produced in a synchronous system if the

processes use timeouts to detect when other processes fail to respond and
messages are guaranteed to be delivered.

 Communication omission failures

 This occurs when the messages are dropped between sender and the
receiver.
 The message can be lost in sender buffer, receiver buffer or even in the
communication channel.
 The loss of messages between the sending process and the outgoing
message buffer is known as send omission failures.
 The loss of messages between the incoming message buffer and the
receiving process as receive-omission failures.

process p process q
send m receive

Communication channel

 The loss of messages in a channel is channel omission failure.

Outgoing message buffer Incoming message buffer

Fig 2.7: Communication between processes in a channel

b) Arbitrary failures (Byzantine failure):
 This includes all possible errors that could cause failure.
 Communication channels often suffer from arbitrary failures
 The following table gives an overview of the different failures and its
categories:

Class Affects Comments

Fail stop Process Process halts and remains halted. Other
processes may detect that this process has
halted.
Crash Process Process halts and remains halted. Other
processes may not detect that this process has
halted.
27
 Distrubuted Systems 2.20

Omission Channel A message inserted in an outgoing message

buffer never arrives at the other end‟s
incoming messagebuffer.
Send-omission Process A process completes a send operation but the
message is not put in its outgoing message
buffer.
Receiveomission Process A message is put in a process‟s incoming
messagebuffer, but that process does not
receive it.
Arbitrary Process Process/channel exhibits arbitrary behaviour:
or it may send/transmit arbitrary messages at
channel arbitrary times or commit omissions; a
process may stop or take an incorrect step.
c) Timing failures
 Timing failures refer to a situation where the environment in which a system
operates does not behave as expected regarding the timing assumptions, that is,
the timing constraints are not met.
 Timing failures are applicable in synchronous distributed system where time
limits are set on process execution time, message delivery time and clock drift
rate.
 The following are the common failures withnrespect to timings:

Class Affects Comments

Clock Process Process‟s local clock exceeds the bounds on its rate of drift
from real time

Performance Process Process exceeds the bounds on the interval between two steps

Performance Channel A message‟s transmission takes longer than the stated bound.

Masking failures
 Each component in a distributed system is generally constructed from a collection
of other components. It is always possible to construct reliable services from
components that exhibit failures.
 A knowledge of failure characteristics of a component can enable a new service to
be designed to mask the failure of the components on which it depends.
27
 Distrubuted Systems 2.21

Reliability of one-to-one communication

The term reliable communication is defined in terms of validity and integrity.
 Validity: Any message in the outgoing message buffer is eventually delivered
to the incoming message buffer.
 Integrity: The message received is identical to one sent, and no messages are
delivered twice.
The threats to integrity come from two independent sources:
 Any protocol that retransmits messages but does not reject a message that
arrives twice.
 Malicious users that may inject spurious messages, replay old messages or
tamper with messages.
Security model

The security of a DS can be achieved by securing the processes and the channels used in their interactio

Protection is described in terms of objects, although the concepts apply equally well to
resources of all types.

Protecting objects

Fig 2.8: Objects and Principals

 The server manages a collection of objects on behalf of some users.
 The users can run client programs that send invocations to the server to perform
operations on the objects.
 The server carries out the operation specified in each invocation and sends the
result to the client.
27
 Distrubuted Systems 2.22

 This uses use “access rights” that define who is allowed to perform operation on a
object.

 The server should verify the identity of the principal (user) behind each operation
and checking that they have sufficient access rights to perform the requested
operation on the particular object, rejecting those who do not.
 A principal is an authority that manages the access rights. The principal may be a
user or a process.

Securing processes and their interactions

 The messages send by the processes are exposed to attack because the network and
the co mmunication service that they use are open.
 To m odel security threats, we postulate an enemy that is capable of nding any
proce se ss or reading/copying message between a pair of processes
 Threa ts form a potential enemy includes threats to processes, t hreats to
com munication channels, and denial of service.

Fig: 2.9: Enemy

 Threats to processes:
 A process that is designed to handle incoming requests may receive a message
from any other process in the distributed system
 It cannot necessarily determine the identity of the sender.
 This lack of reliable knowledge of the source of a message is a threat to the
correct functioning of both servers and clients.
 Servers:
 Servers cannot necessarily determine the identity of the principal behind any
particular invocation.
 Without reliable knowledge of the sender‟s identity, a server cannot tell
whether to perform the operation or to reject it.
27
 Distrubuted Systems 2.23

 Clients:
 When a client receives the result of an invocation from a server, it cannot
necessarily tell whether the source of the result message is from the intended
server or from an enemy, perhaps „spoofing‟ the mail server.
 Thus the client could receive a result that was unrelated to the original
invocation, such as a false mail item (one that is not in the user‟s mailbox).
 Threats to communication channels:
 An enemy can copy, alter or inject messages as they travel across the network
and its intervening gateways.
 Such attacks present a threat to the privacy and integrity of information as it
travels over the network and to the integrity of the system.
 Defeating security threats
 Encryption and authentication are use to build secure channels.
 Each of the processes knows the identity of the principal on whose behalf the
other process is executing and can check their access rights before performing
an operation.
Other possible threats from an enemy
 Denial of service:
Denial of service (DoS) attack is an incident in which a user or organization is
deprived of the services of a resource they would normally expect to have. In a
distributed denial-of-service, large numbers of compromised systems (sometimes
called a botnet) attack a single target.
 Mobile code:
Mobile code is software transferred between systems, e.g. transferred across a
network, and executed on a local system without explicit installation by the
recipient. Mobile code raises new and interesting security problems for anyprocess
that receives and executes program code from elsewhere.
The uses of security models
The use of security techniques incurs processing and management costs. The
distributed systems faces threats from various points. The threat analysis demands the
construction of security models.
INTERPROCESS COMMUNICATION
Interprocess communication (IPC) is a set of programming that allow a programmer to coordinate a
27
 Distrubuted Systems 2.24

- IPC refers to exchange of data between two or more separate, independent

processes/threads.
- The operating systems provide facilities/resources for inter-process
communications (IPC), such as message queues, semaphores, and shared memory.
- Distributed computing systems make use of these facilities/resources to provide
application programming interface (API) which allows IPC to be programmed at a
higher level of abstraction. (e.g., send and receive)
- Distributed computing requires information to be exchanged among independent
processes.
The API’s for the Internet Protocols
Characteristics of IPC:

 Synchronous and asynchronous communication

 In the synchronous form of communication, the sending and receiving
processes synchronize at every message.
 In this case, both send and receive are blocking operations.
 In the asynchronous form of communication, the use of the send operation is
non blocking in that the sending process is allowed to proceed as soon as the
message has been copied to a local buffer, and the transmission of the message
proceeds in parallel with the sending process.
 The receive operation can have blocking and non-blocking variants.

 Message destinations
 The messages in the Internet protocols, messages are sent to (Internet address,
local port) pairs.
 A local port is a message destination with in a computer, specified as an
integer.
 A port has exactly one receiver but can have many senders.
 Processes may use multiple ports to receive messages.
 Any process that knows the number of a port can send a message to it.
 Client programs refer to services by name and use a name server or binder to
translate their names into server locations at runtime.
 This allows services to be relocated but not to migrate – that is, to be moved
while the system is running.
27
 Distrubuted Systems 2.25

 Reliability
 A point-to-point message service can be described as reliable if messages are
guaranteed to be delivered.
 A point-to-point message service can be described as unreliable if messages are
not guaranteed to be delivered in the face of even a single packet dropped or
lost.
 Ordering
 Some applications require that messages be delivered in the order in which
they were transmitted by the sender.
 The delivery of messages outof sender order is regarded as a failure by such
applications.
Sockets
A socket is one endpoint of a two-way communication link between two programs running on the n

Interprocess communication consists of transmitting a message between a socket in

one process and a socket in another process. The java API for interprocess communication in
the internet provides both datagram and stream communication. Both forms of
communication, UDP and TCP, use the socket abstraction, which provides and endpoint for
communication between processes. Interprocess communication consists of transmitting a
message between a socket in one process and a socket in another process. The two
communication patterns that are most commonly used in distributed programs:
 Client-Server communication
 The request and reply messages provide the basis for remote method
invocation (RMI) or remote procedure call (RPC).
 Group communication
 The same message is sent to several processes.

Fig 2.6: Sockets and ports

27
 Distrubuted Systems 2.26

For a process to receive messages, its socket must be bound to a local port and one of
the Internet addresses of the computer on which it runs. Messages sent to a particular Internet
address and port number can be received only by a process whose socket is associated with
that Internet address and port number.

Java API for Internet addresses

 Java provides a class, InetAddress, that represents Internetaddresses.

 Users of this class refer to computers by Domain Name System (DNS) hostnames.
InetAddressaComputer = InetAddress.getByName("abc.ac.in");

UDP Datagram Communication

 The application program interface to UDP provides a message passing abstraction.

 Message passing is the simplest form of interprocess communication.

 API enables a sending process to transmit a single message to a receiving process.

 The independent packets containing theses messages are called datagrams.

 In the Java and UNIX APIs, the sender specifies the destination using a socket.

 A datagram is transmitted between processes when one process sends it and

another receives it.

 The following are the steps in socket communication:

o Creating a socket

o Binding a socket to a port and local Internet address

 A client binds to any free local port

 A server binds to a server port

 Receive() returns Internet address and port of sender, along with the message.

Issues in datagram communication:

 Message size:
 The receiving process needs to specify an fixed size array to receive a message.
 If the message is too big for the array, it is truncated.

 Any application requiring messages larger than the maximum must fragment
them.
27
  Blocking:
Distrubuted Systems 2.27
 Sockets normally provide non-blocking sends and blocking receives for
datagram communication.

 The send() returns after delivering the message to theUDP and IP

protocols. These protocols are now responsible for transmitting the
message to its destination

 The message is placed in a queue for the socket that is bound to the
destination port.

 Messages are discarded atthe destination if no process has a socket bound

to the destination port.

 The receive()blocks until a datagram is received, unless a timeout has been

set on the socket.

 Timeouts:

 The receive() cannot wait indefinitely. This situation occurs when the
sending process may have crashed or the expected message may have been
lost.

 To avoid this timeouts can be set on sockets.

 The timeouts must be much larger than the time required to transmit a
message.

 Receive from any:

 The receive() does not specify an origin for messages. This can get
datagrams addressed to its socket from any origin.

 The receive() returns the Internet address and local port of the sender,
allowing the recipient to check where the message came from.

 It is possible to connect a datagram socket to a particular remote port and

Internet address, in which case the socket is only able to send messages to
and receive messages from that address.

Failure model for UDP datagrams

UDP datagrams suffer from following failures:

 Omission failure: Messages may be dropped occasionally

 Ordering: Messages can be delivered out of order.

27