TDDD82 Secure Mobile Systems
Lecture 4: Distributed Systems
Models
Mikael Asplund
Real-time Systems Laboratory
Department of Computer and Information Science
Linköping University
Based on slides by Simin Nadjm-Tehrani
In lecture 1...
●
●
We looked at Distributed systems as one
possible realisation of Concurrent processes
This time we look at some basic concepts
for modelling, and design principles for
distributed systems
Module overview
●
●
In this module (with 3 credit points) we scratch
the surface of these three important topics
We have placed the focus of the selected topics
on what you need for your project work
–
●
Distributed systems introduction and introduction to
dependability
We also take up what every CS educated person
needs to know on theory of concurrent
computational processes
–
Processes, resource sharing, deadlocks
Reading
●
Chapter 2 of Coulouris, Dollimore, and
Kindberg
Examples
Common in all these?
Distributed model of computing:
●
Multiple processes
●
Disjoint address spaces
●
Inter-process communication
●
Collective goal
Distributed Systems
A collection of independent computers that
appears to its users as a single coherent
system
Distributed Systems
A distributed system is one in which the failure of
a computer you did not even know existed can
render your own computer unusable.
Leslie Lamport
Networking vs. Distributed systems
●
●
“Networking” treats the internal mechanisms for
inter-process communication:
–
Routing
–
Error control (reliable transmission)
–
Flow control (low level treatment of overloads)
“Distributed computing” treats the application view of
the architecture for communication and cooperation
This lecture
●
Basic aspects affecting design
●
Distributed systems architectures and models
Overview
Why is it hard to get it right?
●
●
Variations in workload, connectivity, mobility,
requirements
Heterogeneity in systems environment, hardware,
operating systems, and networks
●
Consequences of timing and failure issues
●
Security threats, and distributed attacks
Architectural models
●
●
●
Placement of processes and data across a network of
computers
Patterns of communication to achieve functional and
extra(non)-functional properties
Challenges: Scalability, interoperability
Architectural models
●
●
Placement of processes and data across a network of
computers
Patterns of communication to achieve functional and
extra(non)-functional properties
What are these?
●
Challenges: Scalability, interoperability
System requirements
●
Functional requirements
–
●
●
Describe the main objectives of the system, also referred to as
“correct service”
Extra-functional requirements
–
Also called non-functional properties
–
Cover other requirements than those relating to main function, for
example expressing the frequency and severity of acceptable
service failures
Example non-functional requirements
–
Timeliness, availability, energy efficiency
Scalability
●
●
Allow the system to become bigger without
negatively affecting performance
Multiple dimensions:
–
Size: Adding more resources and users
–
Geographic: Dispersed across locations
–
Administrative: Spanning multiple administrative
domains
15
Architectural roles
●
Client-server
–
–
Client implements the user interface
Server(s) has most of the functionality
●
●
●
Peer-to-peer (P2P)
–
–
–
●
Computation, data
E.g.: Web
Each component is symmetric in functionality
Peer: Combination of server-client
No “well-known” centralized server
Hybrid
–
Combination of the two
System organisation
●
Centralised
–
●
Most functionality is in a single unit
Decentralised
–
Functionality is spread across multiple units
Types of distribution
●
●
Vertical distribution
–
Logically different components on different machines
–
e.g., multitiered architectures
Horizonal distribution
–
Multiple logically equivalent parts
–
Potentially operating on different data
Physical two-tired architectures
Alternative client-server organizations (a) – (e).
1-29
19
Exaple of horizontal distribution
1-31
An example of horizontal distribution of a Web service.
20
A taxonomy of architectural models
Distributed systems
Peer-to-peer
Client-server
Hybrid
...
Centralised
Decentralised
Decentralised &
horizontally
distributed
Vertically
distributed
Vertically
distributed
Horizontally
distributed
Horiz. & vert.
distributed
Interoperability through middleware
Application, Services
Middleware
Pl
atf
or
m
Operating System
Computer and Network
Hardware
Programmer’s interface
●
Middleware masks heterogeneity
applications
middleware
OS of
machine 1
OS of
machine 2
OS of
machine 3
NETWORK
OS of
machine 4
The role of middleware
●
●
Providing services that are common for a range
of applications
Least level of service provided
–
–
●
●
Interoperability
Location and communication transparency
Additionally: transaction services, fault tolerance
services, load balancing, …
But: Heavy middleware diminishes scalability
What else are models good for?
●
Relate requirements and design
●
Requirement types:
–
Sharing resources
●
–
Performance
●
●
–
Data: consistency & concurrent updates
Response time: consisting of service time, middleware service
overheads, operating system overheads, communication time
Throughput: measure of work done, function of load and
processing/transfer rate
Quality of service
●
Adapting performance and dependability
Models capture…
●
What do we know about a design?
–
–
●
Assumptions
Outcomes: what we can guarantee, and what we
cannot guarantee
Interaction/failure/security aspects
Interaction
Two interaction models
●
Asynchronous
–
●
No relation between computation rate at different
nodes, No bound on message exchange delay, Clock
drift rates are arbitrary
Synchronous
–
Bounded message exchange delay, Related processing
rates at different nodes, Clock drift rates bounded
Implications
●
Synchronous:
–
–
–
●
Local clocks can be used to implement timeouts
Lack of response from another node can be interpreted as
detection of failure
Hard to guarantee!
Asynchronous:
–
–
In the absence of global (synchronised) time one cannot
relate clocks at different nodes
How can events be ordered?
When order matters
Example: global state
a) A consistent cut
b) An inconsistent cut
Lamport timestamps
• Timestamps should follow the partial event ordering
• A → B => C(A) < C(B)
• Timestamps always increase
• Lamport’s Algorithm:
•
•
•
•
Each processor i maintains a logical clock Ci
Whenever an event occurs locally, Ci = Ci+1
When i sends message to j, piggyback Ci
When j receives message from i
• Cj = max(Ci, Cj)+1
Failure
Failure models
●
●
●
●
We will look into more detail into failure and related
notions in next lecture
For now...
Distributed systems can fail in nodes or channels
Node/channel failures:
–
–
–
–
Crash
Omission
timing
Byzantine (arbitrary)
Security
Security model
●
Security in a distributed system can be
achieved by securing
–
–
–
the nodes/processes
the channels used for interaction
the encapsulated objects against unauthorised use
Threat model
●
Identifying the adversary model helps to
identify
–
–
●
Threats to channels
Threats to processes and potential for denial of service
This helps to identify appropriate counter
measures
–
Secure channels, access control and monitoring activities
Extra reading
●
●
●
Check this out: There is no Getting around
it: You are building a distributed system”, by
Mark Cavage
Communications of ACM, Volume 56, no 6,
June 2013
DOI:10.1145/2461256.2461274