Dr. Christian VecchiolaPostdoctoral Research Fellow

csve@unimelb.edu.au

Cloud Computing and Distributed Systems (CLOUDS) Lab

Dept. of Computer Science and Software Engineering

The University of Melbourne

Distributed System Models

Most concepts aredrawn from Chapter 2© Pearson Education

Most concepts aredrawn from Chapter 1© Pearson Education

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Outline Introduction Architectural Models– Characterization– Software Layers– System Architectures – Design Challenges/Requirements

Fundamental Models– Interaction– Failure– Security

Summary

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Introduction

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Introduction

Overview– Distributed system models helps in…

• ..classifying and understanding different implementations• ..identifying their weaknesses and their strengths• ..crafting new systems outs of pre-validated building blocks

–We will study distributed system models from different perspectives• Structure, organization, and placement of components• Interactions• Fundamental properties of systems

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Characterization– The structure and the organization of systems and

the relationship among their components should be designed with the following goals in mind:• To cover the widest possible range of circumstances.• To face the possible difficulties and threats.• To meet the current and possibly the future demands.

– Architectural models provide both:• a pragmatic starting point• a conceptual view

to address these challenges.

In terms of implementation models and basic blocks

In terms of logical view of the system, interaction flow, and components

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Characterization– Challenges (more…)• Widely varying models of use

– High variation of workload, partial disconnection of components, or poor connection.

• Wide range of system environments– Heterogeneous hardware, operating systems, network, and

performance.

• Internal problems– Non synchronized clocks, conflicting updates, various hardware

and software failures.

• External threats– Attacks on data integrity, secrecy, and denial of service.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Characterization– Observations• Widely varying models of use

– The structure and the organization of systems allow for distribution of workloads, redundant services, and high availability.

• Wide range of system environments– A flexible and modular structure allows for implementing different

solutions for different hardware, OS, and networks.

• Internal problems– The relationship between components and the patterns of

interaction can resolve concurrency issues, while structure and organization of component can support failover mechanisms.

• External threats– Security has to be built into the infrastructure and it is fundamental

for shaping the relationship between components.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Characterization–What is an architectural model?

An architectural model of a distributed system is concerned with the placement of its parts and the

relationship between them.

It defines the way in which the components of systems interact with one another and the way in which they

are mapped onto an underlying network of computers.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Characterization– A Distributed System is ultimately composed by

processes communicating over a network.– A first (rough) classification can be done by

discriminating the process types:• Server processes• Client processes• Peer processes• (Possible variations and compositions)

– Such classification leads to a first categorization of architectural models.

Client-Server Systems

Peer-to-Peer Systems

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Characterization– Some Examples:• Client Server Model

– Placement: two distinct roles (1 server, multiple clients)– Relationship: the server provide services, the clients consume

them– Communication: asymmetric

• Peer-to-Peer Model– Placement: one single role, the peer– Relationship: all the peer have the same responsibilities– Communication: symmetric

client server

peer

peer

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Model

Characterization– Other models• Mobile Code based Systems

– Code is dynamically moved among hosts» Web applets (Java, Flash)» Mobile agents

– Security is a concern

• Ad-hoc Systems (based on proximity networks)– High dynamism and volatility of system components– More heterogeneity in the devices connected to the system– Limited capabilities (often)

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Software Layers– Despite the specific model used for

describing/implementing a system a reference software architecture can be defined.

– A software architecture..• ..identifies the organization of a software system

(single or multi-computer)• ..can be expressed in terms of cooperating

– layers (very general, applicable to all the systems)– modules (for component-based systems)– services (more appropriate for DS and SOA)

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Software Layers–Why layers?• Breaking up complexity• Decomposition of

– functions– responsibilities

• Different levels of abstraction• Well proven model

– TCP/IP Stack– ISO/OSI Architecture

Layer N

Layer 1

Layer 0

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Software Layers– Layers in Distributed Systems

Application & Services

Middleware

Operating System

Computer and Network Hardware

Platform- Comprises mostly hardware and OS- Provides basic services to upper level: - Process communication - Process coordination and management - Resource management- Examples: - Intel x86/Windows - Intel x86/Solaris - PowerPC/Mac OS X, Intel x86/MAC OS X - Intel x86/Unix(Linux)….

Middleware- Masks heterogeneity- Provides convenient programming model- Composed of distributed processes or objects- Communication support & resource sharing - RPC / RMI - Event notification - Shared data placement/retrieval/replication-Examples - CORBA / Microsoft DCOM - Java RMI / .NET Remoting - Web Services - ISO/ITU-T RM-ODP

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Software Layers–Middleware• Common stratus for developing application services• Infrastructure component that ties together the

different parts of the distributed system• Modern examples

– Sun J2EE– Microsof .NET– IBM WebSphere – IBM BlueCloud– Manjrasoft Aneka – Google AppEngine

Cloud Computing Platforms (PaaS)

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures–Middleware is the layer where most of the

architectural model realizations take place.– A layered architecture allows for a partition of

responsibilities among the different layers of the system.

– At the middleware level a further distribution of responsibilities and functions between components takes place.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures– Different architectural models partition such

responsibilities in different ways.– This partitioning has an impact on:

• Performance• Reliability• Security

– In deciding how to make this partitioning several trade-offs apply.

– We will investigate the different advantages/disadvantages of the most common models.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Software Architectures– Client Server Model• Mostly cited in the case of distributed systems.• Most widely employed.• Based on:

– Two roles: server and client– Communication pattern:

» asymmetric» request (client) – response (server)

• Examples– HTTP, SMTP, DNS, NNTP

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Software Architectures– Client Server Model

Time

Server

Client

t2

t3t1

t4

t1: request timet2: server process timet3: response timet4: roundtrip time

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms System Architectures

– Client-Server• Two-tier model (classic)

• Three-tier (when the server, becomes a client)

• Multi-tier (cascade model)

Architectural Models

client server

client Server/client server

client Server/clientserver

Server/client

server

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures– Peer-to-Peer Model• All the processes play a similar role.• No distinction between server and client that are

played by each component.• Cooperative interaction.• Avoids centralization and potential SPOF• More difficult to manage• Provides a better scalable infrastructure (1000s hosts)• Examples

– P2P File sharing (OpenNAP, eMule, etc..)– Distributed Hash tables

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Model

System Architectures– Peer-to-Peer model

peer

peer

peer

peer

peer

peer

peer

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architecture– Variations of the previous two models• Multiple Server (kind of multi-tiers)• Cache and Proxy architectures• Mobile Code• Mobile Agents• Network Computers• Thin Clients• Mobile devices and ad-hoc networking

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures– Services provided by multiple servers• Extension of the Client-Server Model• A server response can be the result of

– a cascade request-response (multi-tier model)– the collaboration of several processes which might be

» partitioned in several nodes» replicated in several nodes

• Examples:– Web page content as composition of…

» Database queries» Static content embedding» Web Service calls

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures– Proxy Servers and Caches• A cache is a store of recently used data object that is

closer than the object themselves.• Proxy servers uses caches to maintain a copy of the

content that is frequently accessed, in order to– increase availability of content– increase the performance of requests serving– reduce the traffic load on a wider scale– make accessible content, not accessible otherwise (e.g.

firewalls)

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures– Proxy Servers and Caches• Examples

– Web Browser cache» The web browser maintains copies of the recently

visited pages on a local store» This version of the pages is returned to the use r when

he or she looks for the same page» Specific HTML tags can control the validity of the

cached web pages– Web Proxy Server

» The caching mechanism is similar..

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures– Proxy Servers and Caches• Caching in action!

1st Request

2nd Request

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures–Mobile Code• Mobile code generally refers to an application,

component, or a program that can migrate during its life cycle.• To certain extent, it is also considered mobile code, a

software component that is dynamically downloaded and integrated to an existing application.– Example:

» Applet or Flash in a browser.» Dynamic plug-ins.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms System Architectures

–Mobile Code – Applet model

Architectural Models

Server

Client

Browser process space

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures–Mobile Agents• Mobile Agents incarnate a better example of mobile

code.• They are programs that can migrate among different

hosts, during their life cycle and carry their computation along the way.• Main problem with mobility:

– reconstruction of state

• Two main models:– Strong mobility full state persistence (stack frame)– Weak mobility partial state persistence (checkpointing)

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures–Mobile Agents• Possible uses of mobile agents:

– Information collection– Computation locality

» Mobile agents can move computation in situ» This approach is useful when the data size is huge

• Disadvantages– Security threats (host and guest)– Compatibility of the hosting environment

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures– Network Computer and Thin Clients• Network computers provide terminals

– whit the minimum required software installed locally– that download operating systems and application software

from a remote file server

• In this model:– Applications are run locally– Files (and data in general) are managed remotely– A minimal computational capacity (memory and CPU) is

required.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures– Network Computer and Thin Clients• Thin Client constitute a software layer that provide a

GUI access to a remote machine where application are executed.• Comparison with Network Computers

– Same management costs– No download of OS and software locally

• Disadvantage:– Low performance for highly demanding graphical

applications.

• Example:– X-11, VNC, Remote Desktop..

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

System Architectures–Mobile devices and spontaneous interoperation• Mobile devices involve mobile hardware and not

mobile software.• Mobile devices

– migrate among different computing environments– adapt themselves/ integrate with existing environment

• Main problems– Variable connectivity– Relocation of services– Transition between different networks– Discoverability of services

Mobnility Trasparency

Context Awareness &Spontaneous Interaction

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Interfaces and Objects– A distributed systems is a set of cooperating

processes.– Processes communicate among each others• At low level

– Message passing– Raw communication with sockets

• At high level– By using specific and well defined interfaces– Remote Objects

This patterns provides a more flexible and dynamic partitioning of the responsibilities if compared to the static Client-Server model.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Distributed Architectures Challenges–Main goal of DS: Sharing Resources– History:

• 1960 – First Timesharing systems• 60s – Multiuser operating systems (UNIX)• 70s – 80s First Distributed Systems (devices sharing)• 80s Clusters• 90s Grids• …. Clouds

– Still today…

Sharing data & resources on a large scale is still a challenge!

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Distributed Architecture Challenges– In particular the following aspects have to be

considered:• Performance• Quality of Service• Data and Replica management (caching)• Dependability

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Performance Issues– They arise from the limited processing and

communicating capacities of computers and networks.– What to consider:

• Responsiveness– Interactive application need to be responsive– Bottlenecks can be at each level of the communication stack

• Throughput– This is a common measure for DS– Heterogeneity in a DS may affect throughput

• Load-balancing– DS allow for concurrent execution without competition– Lack of competition can be obtained by

» decentralizing processing » data & services replication

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Quality of Service– QoS concerns non-functional properties of the

system.– By non-functional we mean that:

• A QoS evaluation is not intended to verify whether a operates correctly from a logical point of view.

• A QoS evaluation provides insights on the behavior of the system from the point of view of parameters that characterize how a service operating correctly performs its task.

– Example - File Server: • a functional parameter might be the capability of retrieving a file• QoS parameters are: guaranteed bandwidth, reliability

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Quality of Service– Parameters of interest for Distributed Systems• Reliability & Security:

– How much the system is robust?– What are the security measures put in place (protocols,

standards, encryption level)?

• Performance– Throughput, load balancing, responsiveness.

• Adaptability– How much the system is able to meet the changing

requirements?

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Data Replication and Caching– Performance is the major issue in DS deployment– How can we address performance loss?• Data replication and load balancing

– We can increase the throughput

• Data caching– We can reduce the service time

Data caching poses the problem of obsolete information and different strategies can be implied to avoid the use of content

not anymore valid.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Data Replication and Caching– Obsolete content detection and management• The web caching protocol uses two strategies

– Cache validation– Expiration time on cache content

• How they work– Each content maintained in the cache has an expiry date.– The expiry date of a cached item can be checked against the

server, which will return a fresh copy in case of expiration.– The browser or the proxy do not need to check every time:

» Server sends current time and expiry time for response» Browser (proxy) can estimate whether to request a

fresh copy or not.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Dependability–What is dependability?

“The value showing the reliability of a person to others because of his/her integrity, truthfulness, and trustfulness, traits that can encourage someone to depend on him/her.”

– In systems engineering… “..the trustworthiness of a computing system which allows reliance to be

justifiably placed on the service it delivers ..”

[IFIP 10.4 Working Group on Dependable Computing]

“ dependability (is) the collective term used to describe the availability performance and its influencing factors : reliability performance, maintainability performance and maintenance support performance”

[Technical Committee 56 Dependability – IEC]

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Dependability– In other words…

– How can we measure dependability?• Attributes: Availability, Reliability, Safety, Integrity, Confidentiality,

Maintainability.

–What tampers dependability?• Threats: Faults, Errors, Failures.

–What can we do to ensure dependability?• Means: Prevention, Fault-tolerance, Forecasting.

How much we can trust, rely on a system?

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Design Requirements

Dependability– In particular…• Fault tolerance:

– Dependable application in order to be reliable should keep operating in the presence of hardware, software, and network faults.

– In order to achieve reliability, redundancy (i.e. data & services replication, message retransmission) is applied.

• Security:– Sensitive data must be placed only on hosts that can actively

respond to attacks, and safely protect information.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

A different perspective…– Architectural Models

• Internal organization, placement of components, and interaction patterns

– Design Requirements• Thoughts on performance and reliability characteristics of

distributed systems

– Fundamental Models• Based on the fundamental properties that can give insights on

– characteristics of the system– associated failure an security risks it might exhibit

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

What is a model?– It provides only essential elements to consider for

reasoning and understanding the system behavior. – Addresses the following questions:

• What are the main entities in the system?• How do they interact?• What are the characteristic that affect their individual and collective

behavior?

– We use a model for…• Making relevant assumptions about the system modeled.• Making generalizations concerning what is possible or not possible.

These generalization assume the form of algorithms or properties that are guaranteed (i.e. dependent on logical analysis or mathematical proof)

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Aspect to consider for DS– Interaction

• DS are constituted by interacting processes • Interaction can be:

– Communication (message passing)

– Coordination (information flow)

– Failure• Faults occurs usually in distributed environment• A classification of them helps understanding the weakness of the

systems and the possible counter-actions.

– Security• Modularity and openness expose the system to threats• It is necessary to classify the attacks and devises potential

resistance measures.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Interaction Model– Facts:• Communication takes place with delays (often of

considerable duration)• Delays and the absence of global time limit the

accuracy with which we can coordinate processes.

–What are the element of interest?• Performance Communication Channels• Computer Clocks and Timing Events• Synchronous vs Asynchronous models• Event Ordering

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Interaction Model– Performance Communication Channels• Various implementations• In general the following elements are important:

– Latency» Time taken for transmitting the first bit of a string of bytes» Delay in accessing the network (varies according to load)» Time taken by communication service and OS for processing

– Bandwidth» Total amount of information transmissible in the unit of time

– Jitter » Variation in the time taken to deliver a message

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Interaction Model– Computer Clocks and Timing Events• Each computer has its own internal clock.• Two processes running on different computers will

end up to have a different clock (and timestamps for events)• Computer clocks drift from the perfect time at

different rates.• Without corrections such clocks will vary

considerably over a long period of time.• Possible solutions:

– GPS (ok for open spaces) – Timing protocols (variable to message delays)

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Interaction Model– Synchronous vs Asynchronous Models• Synchronous Systems (Assumptions)

– Process step execution time has known lower and upper bounds.– Each message transmission over a channel has a bounded time.– Local clock drift rate from real time has a known bound.

• Asynchronous Systems – None of the previous assumptions are valid.– Heterogeneity in all of the three aspects.

• Observations:– It is possible to suggest likely upper and lower bound.– It is very difficult to provide accurate realistic values.– The use of synchronous system models is not realistic but might be

helpful in designing initial versions of the system.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Interaction Model– Event Ordering• Sequence of events is important• The execution of a system can be described in terms

of the sequence of events that occur in it• Clocks cannot be synchronized perfectly across a

distributed system.• It is possible to order events in the absence of global

clock?

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Interaction Model– Event Ordering – The meeting problem

m1X

t2 t3t1

Y

Z

A

m2

m3

send send send

receive

receive receive

receive receive

receive

receivereceivereceive

Inbox of A:…23 Z Re: Meeting24 X Meeting25 Y Re: Meeting….

Can A reconstruct the proper sequence?

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Interaction Model– Event Ordering• Logical Time (Lamport 1978) can help reconstruct the

sequence ordering of events in absence of global clock.• A number is assigned to each event.• This number represents the logical order of the event

in the sequence.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Failure Model–What is failure?

• Process and communication may depart from what is the expected behavior.

–What is a failure model?• Defines the ways in which failure may occur in order to provide

understanding of the effects it can cause.

– Observations• Different kinds of failures can be addressed differently• Different kinds of failures denote different (major or minor)

problems• Classification of failures is then important.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Failure Model– Taxonomy of Failures• Applies to Processes and Communication• [Hadzilacos and Tueg, 1994]

– Categorization:• Omission Failures• Arbitrary or Byzantine Failures• Timing Failures

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Failure Model– Omission Failures• Characterization

– A process or a communication channel fails in performing what it is supposed to do.

• Possible Types:– Process omission Failures

» Process crashes (fail-stop if can be detected, complete crash or abnormal residual behavior?)

– Communication channel Omission Failures» Dropping messages (channel omission)» Send-omission failures» Receive-omission failures

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Failure Model– Arbitrary Failures or Byzantine Failures• Characterization

– Worst possible failure semantics.– Any type of any error can occur.

• Types:– Process arbitrary failures

» Insertion of invalid data.» Invalid execution paths.

– Channel arbitrary failures» Message content corruption» Unintended messages delivered» Duplication

Easily detectable by the communication software.

Difficult to detect by simply checking whether the process responds to

the invocation..

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Failure Model– Timing Failures• Synchronous Systems

– An operation executes beyond its time limits.

• Asynchronous Systems– Difficult to characterize, since there are no bounds on the

time.

• Solutions:– Real-time operating systems

• Where to:– Multimedia computer with audio and video channels.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Failover Model–Masking Failures• It is possible to construct reliable services from

components that exhibit failures.• Failure detection is important to identify the wrong

behavior and then provide a counter-measure– Data replication– Checksums and error correction– Message retransmissions

• A failure can be …– … completely masked – … turned into an acceptable failure

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Security Model– The security of a distributed system can be

achieved by• Securing the processes composing the system.• Securing the channels they use to communicate.• Protecting the objects they encapsulate by

unauthorized access.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Security Model– Protecting objects• Avoiding unauthorized access• Identifying

– who is accessing what– what permission does he/she have on the object

• Each service request operating on sensitive objects has to occur under a specific authority– Concept of Security Principal– Concept of Access Rights.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Security Model– Protecting objects• Example

Sensitive Object

Internet <Untrusted Zone>

Security Service

User

Request + Credentials

Server

Principal + Access Rights

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Security Model– Securing Processes and their Interactions• Process interact through

– Message passing– Publicly available interfaces

• Assumptions– The communication channel is untrusted– Potential misuses of the services exposed by the process

• Observations– How can we protect processes from the enemy?– What are the potential threats?

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Security Model– Identifying the Enemy• Malicious entity (user or program) capable of

– sending message through the network to any process– reading or copying any message between a pair of processes– impersonating one end point of the communication

m1 m1’

m1

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Architectural Models

Security Model– Classification of Threats• Threats to Processes

– Impersonation (generation, alteration of network packets)– Threats to both servers (requests) and clients (responses)

• Threats to Communication Channels– Injection, alteration of messages– Message copy– Threats for privacy and integrity– Countermeasure: secure channels

• Denial of Service: generation of false request• Mobile Code: untrusted, unknown, potentially

harmful

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Security Model– Countermeasures• Cryptography and shared secrets

– Processes shared a secret helping them communicating safely– The shared secret can be used as key to encrypt messages over an

unsecure channel– Cryptography: science of keeping message secures– Encryption: process of altering a message so that its content cannot

be read by unintended receivers.

• Authentication– The knowledge of the secret ensures the identity of both endpoints– The secret can be used to identify the sender

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Security Model– Countermeasures• Secure Channels

– Encryption and Authentication can be used to build a secure channel.

– A secure channel can be considered as a service layer on top of existing communication services.

– It is a communication channel that connects a pair of processes, each of which acts on behalf of a principal.

• Channel properties.– Each end point knows who resides on the other end point.– The channel ensures privacy and integrity of messages.– Each message includes a physical and logical time-stamp to

prevent copies.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Security Model– Use of Security Models• The techniques discussed in this section constitute the

fundamental blocks to build a security infrastructure.• Additional issues arises in a real system

– Performance vs Security: security measure introduce processing costs.

– Other threats beyond the ones listed can be considered» Human factor» Geo-location

• A careful analysis of all the aspects of a DS (hardware, software, network, and human) allows to build a threat model.

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Fundamental Models

Security Model– Use of Security Models• The threat model lists all the potential attacks that the

systems might be exposed to.• Security costs have to be balanced against these

attacks• Bottom line:

– “how much your enemy is willing to pay to break your security?”

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Summary

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Summary

What do we have learnt?– Architectural Models

• An architectural model of a distributed system is concerned with the placement of its parts and the relationship between them.

• It defines the way in which the components of systems interact with one another and the way in which they are mapped onto an underlying network of computers.

– Design Requirements• Focus on performance, quality of service, dependability and security

– Fundamental models• What is a model and its characteristics• 3 Fundamental models

– Interaction model– Communication model– Security model

Dis

trib

uted

Sys

tem

Mod

els

Dis

trib

uted

Sys

tem

s P

rinc

iple

s an

d Pa

radi

gms

Questions?