Distributed

Computing
Module 1

System Models

EJ 1
System Models
- Architecture Models
- Fundamental Models

EJ 2
Specific Objectives
To provide models for helping to
perceive different distributed system
designs
To bring out the common properties and
design issues for distributed systems in
the form of descriptive models.
To understand the characteristics of the
most common architectural models of
distributed systems
To know some of the factors that
produce variety to these models
To reveal key problems for the designers
of distributed system. EJ 3
Classification
Architectural models
Client-server model
Peer-to-peer model

Fundamental models
Interaction model
Failure model
Security model

EJ 4
Architectural Model
An Architectural model is concerned with
the placements of its parts and the
relationship between them.
Client-Server architecture is a common
way of designing distributed systems.
Eg: Client Server model, Peer process
model, Services provided by multiple
servers, Proxy servers and caches
Alternative Client-Sever models driven
by:
Mobile code, mobile agents, network
computers, thin clients, mobile devices and
spontaneous networking EJ 5
Fundamental Model
Fundamental Models are concerned with a
formal description of the properties that are
common in all of the architectural 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
Security Model discusses possible threats
to processes and communication channels.
EJ 6
Architectural
Models

EJ 7
Architectural Models
The architecture of a system is its structure
in terms of separately specified components.
Its goal is to meet present and likely future
demands.
Major concerns are to make the system
reliable, manageable, adaptable, and cost-
effective.

Simplifies and abstracts the functions of

individual components
The placement of the components across a
network of computers define patterns for the
distribution of data and workloads
The interrelationship between the components
ie., functional roles and the patterns of
communication between them.
EJ 8
Architectural Models
ArchitecturalModel defined around
the concepts of process and object
An initial simplification is achieved by
classifying processes as:
Server processes
Client processes
Peer processes
Classification identifies the responsibilities
of each and hence assess their workloads
to determine the impact of failures
Result of this analysis is used to specify
the placement of processes to meet
performance and reliability EJ goals 9
 Software Architecture and
Layers
The term software architecture referred:
Originally to the structure of software as layers or
modules in a single computer.
More recently in terms of services offered and
requested between processes in the same or
different computers.
Breaking up the complexity of systems by designing
them through layers and services
Layer: a group of related functional components
Service: functionality provided to the next layer.
Layer N

Layer 2
(services offered to above layer)
Layer 1
EJ 10
Software and hardware service
layers in distributed systems

Applications, services

Middleware

Operating system
Platform

Computer and network hardware

EJ 11
Platform
The lowest hardware and software layers are
often referred to as a platform for distributed
systems and applications.
These low-level layers provide services to
the layers above them, which are
implemented independently in each
computer.
Facilitates communication and co-ordination
between processes
Major Examples
Intel x86/Windows
Intel x86/Linux
Intel x86/Solaris
SPARC/SunOS
PowerPC/MacOS EJ 12
 Middleware
A layer of software whose purpose is to mask
heterogeneity present in distributed systems
and to provide a convenient programming
model to application developers.
Major Examples:
Sun RPC (Remote Procedure Calls)
OMG CORBA (Common Request Broker
Architecture)
Microsoft D-COM (Distributed Components Object
Model)
Sun Java RMI
Modern Middleware:
Melbourne Gridbus for Grid computing
ANL Globus a Grid toolkit
IBM WebSphere
Microsoft .NET
Sun J2EE EJ 13
Middleware contd
Helps creating building blocks for
constructing software components that can
work with one another in a distributed system
Allows communication between group of
processes
Notification of events
Replication of shared data
Provide services for use by application
programs
Eg: CORBA-Naming, security, transaction and
persistent storage
Limitations:
Many DS rely completely on services on available
middleware for communication and data sharing
Eg: client server model can rely on middleware that provides
only RMI EJ 14
System Architecture
The most evident aspect of DS design
is the
Division of responsibilities between
system components (applications,
servers, and other processes) and
The placement of the components
on computers in the network.
It has major implication for:
Performance, reliability, and security
of the resulting system.
EJ 15
Servers
Process the accept request from other
processes
Process the request and provide
output to the requesting process
Distributed Service: More than one
server process interact with each
other and with clients
Eg: Network Time Services-> implemented
on Internet using NTP (network time
protocol) by server processes running
through out the Internet that supply the
current time to any client on request
EJ 16
Client Server (Basic)
Model
Widely used model
Process acting as a client sends request
to a server.
Examples:
Webserver: Client (Web browser) sends a
request for a webpage the webserver then
returns the requested server.
SQL server: client processes send
request for data or requests to modify data.
Servers can become clients to other
services: For example the webserver might simply
be a web proxy and pass requests on to other
servers. EJ 17
Clients and Servers
General interaction between a client and
a server.

EJ 18
Client Server (Basic)
Model

EJ 19
Client Server Model
contd
Client process interact with individual
server processes in different host
computers in order to access data or
resource.
The server in turn may use services
of other servers.
Example:
A Web Server is often a client of file
server.
Browser search engine
crawlers other web servers.

EJ 20
A service provided by
multiple servers

Example:Cluster based Web servers and apps

such as Google, parallel databases
EJ Oracle 21
 Multiple Servers. contd
Services may be implemented as several
server processes in separate host computers.
They interact with each other to provide
services to clients
2 ways:
1. The object on which the service is based on
may be distributed
Eg: Web: multiple web servers co ordinate
together to provide the service
2.
The copies/replica of services may be
provided to increase performance, availability
and improve fault tolerance
Eg: multiple consistent copies in different
computers, Altavista- DB replica, Sun Network
Info Service-password file replica
EJ 22
Proxy Servers and Caches
Variants
Proxy servers: render replication/
distributedness and transparency
Caching
Proxy server maintains cache store
of recently requested resources
Frequently used in search-engines:
Used extensively in web browsers to
maintain cache of recently visited web
pages/ other web resources
Check updates using http request before
displaying results EJ 23
Cache
Cache is a store of recently used data
objects located closer than the actual
objects
When the client needs an object, it is first
searched in cache and is supplied from
cache if an up-to-date copy is available
If not, an up-to-date copy is fetched from
the server and is replaced in cache
Cache may be in a client or on a proxy
server
Cache may be shared by several clients

EJ 24
 Proxy Servers and Caches
contd
Web proxy servers can operate at client level,
at ISP level and at edge/gateway levels to
improve performance and reduce
communication costs for frequently accessed
data.
Caching can even be used for dynamic data
(such as a google search).
This reduces the load on the web servers and
improves the performance for end users by
reducing the time taken for a dynamic
request.
Google uses this technique extensively!
When serving 100M requests/day this saves
resources. EJ 25
Google Search Example
Without cache: Time taken is 0.10 secon

After caching: Time taken is 0.5 seconds

EJ 26
Web proxy server

Web proxy server provides shared

cache of web resources for client
machines at a site or across several
sites
Increases availability & performance
of the service by reducing load on the
EJ 27
Peer Processes Model
All ofthe processes play similar roles
They interact cooperatively as peers to perform
a distributed activities or computations
No distinction between clients and servers.
Code in peer processes maintain consistency of
application level resources and synchronizes
application level activities
Elimination of server process reduces the inter-
process communication delays to access local
objects
Better response to users than in a server based
environment
E.g., music sharing systems Gnutella, Napster,
etc.
Distributed white board users on several
computers to view and interactively modify a
picture between them. EJ 28
Peer process model: 3 way
instance

No central point of failure (gives reliability)

No central point of control (difficult to deny
service for adversaries) EJ 29
 A distributed application based on
Peer 2
peer processes
Peer 1
Applic ation

Applic ation

S harable Peer 3
objec ts
Applic ation

Peer 4

Applic ation

Peers 5 .... N

EJ 30
Variations of the client-
server model
CS can be modified by:
The partitioning of data/replication at
cooperative servers
The caching of data by proxy servers or
clients
The use of mobile code and mobile agents
The requirements to add or remove mobile
devices.
Eg: Mobile code and Mobile Agents,
Thin clients, Network computers
Performance and reliability can be
increased EJ 31
1. Mobile code and Web
applets

EJ 32
Mobile code and Web applets
Eg: Applets - Working
User running a browser selects a link to
applet whose code is stored on a web
server
Code is downloaded to the browser and
run there
Running code locally by downloading to
clients give good interactive response( no
network delay)

Mobile codes such as Applets are

potential security threat, so the
browser gives applets limited access
to local resources (e.g. NO access to
local/user file system). EJ 33
Push Model
Server initiates the interactions
instead of the client

To keep users up-to-date with

changes occurring at an information
source in the server

Eg: Stock broker notify customers

regarding the changes in prices of
shares

EJ 34
2. Mobile Agents
A running program (code and data) that
travels from one computer to another in a network
carrying out of an autonomous task, usually on
behalf of some other process
Eg: Collecting information
May invoke local resources at systems they visit
(local invocation)
Local invocation reduces communication cost and
time when compared to remote invocation in
client server model
Advantages: flexibility, savings in
communications cost
Eg: virtual markets, used to install and maintain
software on the computers within an organisation,
compare prices of products from different vendors
by visiting their site and doing DB operations
EJ 35
Mobile Agents contd
Security Threats:
Potential security threat to the resources
in computers they visit.
The environment receiving agent should
decide which of the local resource to allow.
(e.g., crawlers and web servers).
Restrict based on the identity of the user
on whose behalf the agent is acting. So
users identity must be included in a
secure way with the code and data of
agents
Agents themselves can be vulnerable
they may not be able to complete task if
they are refused access. EJ 36
3. Network Computers
Desktop- OS and application software require
active code and data to be located on a local
disk and this needs more technical effort to
manage the application files and local network
Network Computer is a response to this
problem
NC Downloads the OS and application software
needed by the user from a remote file server
Applications run locally but files are managed
in a remote server
Users can migrate from one network computer
to another as the application data and code is
stored by file server
Processor and memory capacities can be
constrained to reduce its cost
Cache can be used
EJ 37
4. Thin Clients
A thin client refers to software layer
that supports a window-based user
interface on a computer that is local to
the user while executing application
programs on a remote computer.
Low management and hardware costs
Instead of downloading the code to
users computer, it runs them on the
compute server (Powerful computer
that has the capacity to run large
number of applications simultaneously
EJ 38
Thin Client Model

EJ 39
Thin Clients contd
Drawback: In highly interactive graphical
activities like CAD/Image processing
Delay is increased by the need to transfer
image and vector information between the
thin client and the application process
Thin Client Implementations:- X11
window system in unix - is a process that
manages the display and interactive
input devices of the system on which it
runs
Examples include:
Sun Rays, remote X clients, VNC,
Microsoft remote desktop. EJ 40
5. Mobile devices and
Spontaneous networking
Small and portable computing devices
laptop, PDA, mobile phones, digicam,
wearable computers, smart watches etc
Capable of wireless networking for
different ranges
These devices provide support for
mobile computing by integrating into
distributed systems
Users can carry these devices and take
advantage of local and remote
resources (spontaneous networking)
EJ 41
Mobile devices and
Spontaneous networking contd
Eg: In a hotel, the users devices can
be connected using infra red
(wireless networking)
Eg: Embedded devices in appliances
provide services to users and to other
nearby devices.
PDAs give the user access to the local
services in their current location and also
web

EJ 42
Spontaneous networking in a
hotel

EJ 43
 Key features of spontaneous
networks
1. Easy connection to local network
No need of pre-installed cabling, plugs and
sockets
Communication links can be maintained while
on the move in train, car etc
In a new network the device will be
transparently reconfigured without any user
interaction
2.Easy integration with local
services
Devices that find themselves inserted into
existing networ discover automatically what
services are provided there
No special configuration actions
EJ by the user 44
Issues in spontaneous networks
Challenge of supporting convenient
connection and integration (eg: IP change
when system moves from one network to
another)
1. Limited Connectivity
Not always connected on the move
Intermittently disconnected tunnels etc
Totally disconnected places where there is
no range at all
2. Security and Privacy
Vulnerable to security attacks
Some systems track physical locations of
users as they move around
Exposure to secure data EJ 45
Discovery Services
Spontaneous networking requires client
processes running on portable devices and
other applications to access services on the
network to which they are connected
There should be a means for clients to
discover what services are available in the
network to which they are connected and
to investigate their properties
Discovery service accept and store details
of services that are available on the
network and to respond to queries from
clients about them

EJ 46
 Discovery Services
Discovery services offers two interfaces
(1) Registration Service
Accept registration requests from servers and
records the details in database
Enable servers to publish their services
(2) Look up Service
Allow clients to discover services that meet their
requirements
Accept queries concerning available services and
searches its database for registered services that
match the queries
Result returned includes sufficient details to enable
clients to select between several similar services
based on their attributes and to make a connection
to one or more of them EJ 47
Fundamental
Models

EJ 48
Fundamental Models
Fundamental Models are concerned
with a formal description of the
properties that are common in all of
the architectural models.
All architectural models composed of
processes that communicate with
each other by sending messages
over a computer networks.
Different models share some
fundamental properties
Eg: characteristics, failures and
security risks that exist
EJ 49
Model
Contains the necessary ingredients
that are to be considered to
understand and reason about some
aspects of system behaviour
System model addresses the
following
Who are the main entities in the system?
How do they interact?
What are their characteristics that affect
their individual and collective behaviour?
What are the link characteristics?
EJ 50
Purpose of a Model
To make explicit all the relevant
assumptions about the system we
are modeling
Make generalizations concerning
what is possible or impossible by
logical analysis and mathematical
proof

EJ 51
Fundamental/Abstract
Models
Interaction model
Reflects the assumptions about the
processes and the communication
channels in the distributed system
Failure model
Distinguish between the types of failures
of the processes and the communication
channels
Security Model
Discusses possible threats to processes
and communication channels.

EJ 52
Interaction Model
Computation occurs within processes;
The processes interact by passing
messages, resulting in:
Communication (information flow)
Coordination (synchronization and
ordering of activities) between processes.
Examples of interaction in distributed
system
DNS, NIS: multiple server processes
cooperate with one another
P2P voice conference system: set of peer
processes cooperating with one another
with strict real-time constraints
EJ 53
Interaction Model
Distributed Algorithm: a definition
of the steps to be taken by each of the
processes of which the system is
composed, including the transmission
of messages between them
Difficult to describe all the states, because of
failures of processes and message transmissions
Two significant factors affecting
interacting processes in a distributed
system are:
Communication performance is often a
limiting characteristic.
It is impossible to maintain a single
global notion of time. EJ 54
Interaction Model
Performance of communication channels
The communication channel in our model are
realised in a variety of ways in DSs. E.g., by
implementation of:
Streams
Simple message passing over a network.
Communicationover a computer network has
performance characteristics:
Latency:
A delay between the start of a messages transmission
from one process to the beginning of receipt by another.
Bandwidth:
the total amount of information that can be transmitted
over in a given time.
Communication channels using the same network, have
to share the available bandwidth.
Jitter
The variation in the time taken to deliver a series of
messages. It is vary relevant to
multimedia
EJ data. 55
 Interaction Model
Computer clocks and timing events
Each computer in a DS has its own internal clock,
which can be used by local processes to obtain the
value of the current time.
Therefore, two processes running on different
computers cam associate timestamp with their events.
However, even if two processes read their clock at the
same time, their local clocks may supply different time.
This is because computer clock drift from perfect
time and their drift rates differ from one another.
Even if the clocks on all the computers in a DS are set
to the same time initially, their clocks would eventually
vary quite significantly unless corrections are applied.
There are several techniques to correcting time on
computer clocks. For example, computers may use
radio receivers to get readings from GPS (Global
Positioning System) with an accuracy about 1
microsecond.
Clock drift rate the relative amount that a
computer clock differs from a perfect
EJ
reference clock 56
Two variants of the Interaction
Model
Synchronous Distributed System:
following bounds are defined
The time to execute each step of a process
has an upper and lower bound
Each message transmitted over a channel is
received within a known bounded delay
Each process has a local clock whose drift
rate from real time has a known bound
Asynchronous Distributed System: no
bounds on
Process execution speeds: e.g. each step
may take an arbitrarily long time
Message transmission delays: e.g. a
message may be received after an arbitrarily
long time EJ 57
Two variants of the Interaction
Model
Examples of synchronous DS and
asynchronous DS
Asynchronous DS: email, ftp
Synchronous DS: VOD, voice
conference system
Some implications
In a synchronous system, timeouts
can be used to detect failures
Impossible to detect failures or
reach agreement in an
asynchronous system
EJ 58
Event Ordering
In many DS applications we are
interested in knowing whether an
event occurred before, after, or
concurrently with another event at
another processes.
The execution of a system can be
described in terms of events and their
ordering despite the lack of accurate
clocks.
In a distributed system it is impossible
for any process to have a view on the
current global state of the system
Possible to record timing information
locally, and abstract from
EJ real time 59
 Event Ordering
Consider a mailing list with users X, Y, Z,
and
send A. receive receive
X
1 m1 4
m2
send
2 3 receive Physical
Y
receive time

send
Z
receive receive

m3 m1 m2
A
receive receive receive
t1 t2 t3

X sees m1, m2, m3 Y sees m1, m2, m3 Z sees

m1, m2, m3 EJ 60
 Inbox of User A looks like:
Item From Subject
23 Z Re: Meeting
24 X Meeting
26 Y Re: Meeting

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.
EJ 61
 Event Ordering
Logical time [Lamport 1978]
Provide an ordering among the
events at processes running in
different computers in a distributed
system
Allows the order in which the
messages are presented to be
inferred without recourse to clocks
Logically a message is received
after it was sent. So, logically
X sends m1 before Y receives m1
Y sends m2 before X receives
EJ m2 62
 Agreement in
pepperland
The pepperland divisions need to agree on
which of them will lead the charge against the
Blue Meanies, and when the charge will take
place.
In asynchronous pepperland, the messengers
are very variable in their speed.
The divisions know some useful constraints:
every message takes at least min. Minutes
and at most max minutes to arive.
The leading division sends a message
charge!, then waits for min minutes, then it
charges.
The other divisions charge is guaranteed to
be after the leading divisions, but no more
than (max-min) after it. EJ 63
Failure Model
Omission failures
Arbitrary failures
Failure detection
Impossibility of reaching
agreement in the presence of
failure
Masking failure
Reliability of one to one
communication
EJ 64
 Failure Model
Ina DS, both processes and communication channels
may fail i.e., they may depart from what is
considered to be correct or desirable behavior.
Types of failures:
Omission Failure
process or communication channel fails to
perform a requested action
Arbitrary Failure
most tricky to deal with, where any type of error
can occur. Corrupt data, unexpected responses
Timing Failure
related to synchronous messages, where a set
bound [clock drift, message ack, process
execution time] exceeds defined bounds
EJ 65
 Processes and Channels
process p process q

send m receive

Communication channel
Outgoing message buffer Incoming message buffer

Communication channel produces an

omission failure if it does not transport a
message from ps outgoing message
buffer to qs incoming message buffer.
This is known as dropping messages and
is generally caused by lack of buffer space
at the receiver or at gateway or by a
network transmission error.
EJ 66
 Failure Model Omission
Failure
A process or communication channel fails to
perform actions that it is supposed to do
Process omission failure: Crash
Fail-stop: Crash that can be detected
by other processes certainly, e.g., by
timeouts in synchronous DS
Communication omission failures:
dropping messages
Send omission (loss of msg between
sending process and outgoing buffer),
receive omission (loss of msg between
incoming msg buffer and receiving
process),
channel omission (loss EJof messages in 67
 Omission and Arbitrary
Failures
Classoffailure
Failstop
Affects Description
Process Processhaltsandremainshalted.Otherprocessesmay
detectthisstate.
Crash Process Processhaltsandremainshalted.Otherprocessesmay
notbeabletodetectthisstate.
Omission Channel Amessageinsertedinanoutgoingmessagebuffernever
arrivesattheotherendsincomingmessagebuffer.
Sendomission Process Aprocesscompletesa send,butthemessageisnotput
initsoutgoingmessagebuffer.
ReceiveomissionProcess Amessageisputinaprocesssincomingmessage
buffer,butthatprocessdoesnotreceiveit.
Arbitrary Processor Process/channelexhibitsarbitrarybehaviour:itmay
(Byzantine) channel send/transmitarbitrarymessagesatarbitrarytimes,
commitomissions;aprocessmaystoportakean
incorrectstep.

Fail-stop can be detected by the absence of the process on the server

(e.g do a ps -A, task manager on windows)
Crash may be difficult to detect as process may still be running
(zombie) but performing no useful function, ignoring messages
EJ 68
 Failure Model Arbitrary
Failure(Byzantine) failures
Arbitrary
the worst possible failure semantics
Arbitrarily omit intended processing
steps or take unintended processing
steps. E.g., return a wrong value in
response to an invocation
Non delivery, corruption, duplication
Arbitrary failures in process is hard
to be detected
Arbitrary failures in communication
channel exist but rare, by recognize
and reject the faulty messages
EJ 69
 Timing Failures
ClassofFailure Affects Description
Clock Process Processslocalclockexceedstheboundsonits
rateofdriftfromrealtime.
Performance Process Processexceedstheboundsontheinterval
betweentwosteps.
Performance Channel Amessagestransmissiontakeslongerthanthe
statedbound.

Timing failures are most prevalent with synchronous

systems with defined hard bounds on timing,
performance and network characteristics
Bounds could be obtained by measuring actual
system (e.g. measure 1000 runs so you know what
normal behaviour is)
EJ 70
Does time matter?

Sender
failed?

Lost
message?

Slow
channel?

EJ 71
 Masking Failures
Itis possible to construct reliable services from
components that exhibit failures.
For example, multiple servers that hold replicas of data can
continue to provide a service when one of them crashes.
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:
Checksums are used to mask corrupted messages.
We can add reliability through redundancy. Once system
by itself may be unreliable but if we replicate it there is
a very low probability of them all failing simultaneously
When dealing with unreliable networks we can mask the
failures that can occur. E.g use TCP instead of UDP.
Use checksums and error-correcting codes to ensure
data integrity. Add reliability at the application level.
EJ 72
Masking Failures
Hide, e.g., replicated servers
convert, e.g., Checksum: arbitrary
failure -> omission failure
Reliability of one-to-one communication
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, against retransmit
protocols and malicious messages
Reliable communication is defined in terms
of validity and integrity
EJ 73
Security Model
Protecting objects
Securing processes and their
interactions
The enemy
Defeating security threats
Other possible threats from the
enemy
The uses of security models

EJ 74
Security Model
The security of a DS can be
achieved by securing the processes
and the channels used in their
interactions and by protecting the
objects that they encapsulate
against unauthorized access.
Two components: secure channel
and secure process

EJ 75
Security Model
Protecting the objects
Access rights: who is allowed to perform
the operations of an object
Principal: the authority who has some
rights on the object

Use access rights that define who is allowed

to perform operation on a object.
The sever 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.
EJ 76
 Security Model

Access rights Object

invocation

Client
result Server

Principal (user) Network Principal (server)

To model security threats, we postulate an enemy

that is capable of sending any process or
reading/copying message between a pair of
processes
Threats form a potential enemy: threats to
processes, threats to communication channels, and
denial of service. EJ 77
Security Model
Protecting access to objects
access rights in client server systems: involves
authentication of clients
Protecting processes and interactions
threats to processes: problem of unauthenticated
requests / replies
e.g., "man in the middle
threats to communication channels: enemy may
copy, alter or inject messages as they travel across
network
use of secure channels, based on cryptographic
methods
Denial of service
e.g., pings to selected web sites generating
debilitating network or server load so that network
services become de facto unavailable
EJ 78
 Securing processes and their
interactions
The enemy
Threats to processes
To servers: invocate with a false identity, e.g. cheating a
mail server
To clients: receive false result, e.g. stealing account
password
Threats to communication channels
Copy, alter or inject messages
Save and replay, e.g., retransfer money from one account
to another
Denial of service: excessive and pointless invocation on
services or message transmissions in a network, resulting in
overloading ofCopy ofm resources (network bandwidth, server
physical
processing capacity)
Mobile code: malicious mobile program, e.g. Trojan horse
The enemy
attachment
m
Processp m Processq
Communication channel

EJ 79
 Securing processes and their
interactions
Defeating security threats Secure Channels
Cryptography and shared secrets
Identify each other by the shared secrets that are only
known by themselves. Cryptography is the base.
Authentication proving the identities supplied by their
senders
Secure channels
Each process knows reliably the identities of the principal
on whose behalf the other process is executing
Ensure the privacy and integrity of the data transmitted
across it
Each message includes physical or logical time stamp
Principal A Principal B

Process p Secure channel Process q

EJ 80
 Securing processes and their
interactions
Defeating security threats Secure Channels
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.
Secure channels are essential for many modern
distributed computing applications. We can use
the untrusted internet with confidence to do
shopping, online banking and share trading over
public networks by using secure channels.
Most approaches use a public/private key pair
system (e.g. SSH, HTTPS/SSL, VPN) where traffic is
encrypted by the sender with their private key
and decrypted and verified by EJthe receiver using81
Summary
Architecture models
Client / Server, e.g. Web, FTP, NEWS
Multiple Servers, e.g. DNS
Proxy and Cache, e.g. Web Cache
Peer process
Variations of C/S
Mobile code, mobile agent, network
computer, thin client, spontaneous
networks
Fundamental models
Interaction models synchronous DS and
asynchronous DS
Failure models omission failures, arbitrary
failures and timing failures
Security model - the enemy EJ
and the 82
 Thank
You
EJ 83