TDDD82 Secure Mobile Systems Lecture 1: Introductjon and - - PowerPoint PPT Presentation

TDDD82 Secure Mobile Systems Lecture 1: Introductjon and Distributed Systems Models

Mikael Asplund Real-tjme Systems Laboratory Department of Computer and Informatjon Science Linköping University

Based on slides by Simin Nadjm-Tehrani

Module overview

• 3hp
• Some parts that strongly relate to your projects
• Distributed systems, dependability, quality-
• f-service
• General CS knowledge: concurrent

programming

• Processes, resource sharing, deadlocks

Lecture organisation

• Lecture 1: Distributed systems (intro)
• Lecture 2-4:Processes

– All concurrency related topics, including synchronisation, mutual exclusion, deadlocks

• Lecture 5: Dependability
• Lecture 6: Quality of Service

Distributed systems

Reading

• Chapter 2 of Coulouris, Dollimore, and

Kindberg

Examples

Common in all these?

Distributed model of computjng:

• Multjple processes
• Disjoint address spaces
• Inter-process communicatjon
• Collectjve goal

Distributed Systems

A collectjon of independent computers that appears to its users as a single coherent system

Networking vs. Distributed systems

• “Networking” treats the internal mechanisms for

inter-process communicatjon:

–

Routjng

–

Error control (reliable transmission)

–

Flow control (low level treatment of overloads)

• “Distributed computjng” treats the applicatjon view of

the architecture for communicatjon and cooperatjon

• Basic aspects afgectjng design
• Distributed systems architectures and models

This lecture

Why is it hard to get it right?

• Variatjons in workload, connectjvity, mobility,

requirements

• Heterogeneity in systems environment, hardware,
• peratjng systems, and networks
• Consequences of tjming and failure issues
• Security threats, and distributed atuacks

Overview

• Architectural models
• Interactjon models
• Faults and failures

• Placement of processes and data across a network of

computers

• Patuerns of communicatjon to achieve functjonal and

extra(non)-functjonal propertjes

• Challenges: Scalability, interoperability

Architectural models

• Placement of processes and data across a network of

computers

• Patuerns of communicatjon to achieve functjonal and

extra(non)-functjonal propertjes

• Challenges: Scalability, interoperability

Architectural models

What are these?

System requirements

• Functjonal requirements

–

Describe the main objectjves of the system, also referred to as “correct service”

• Extra-functjonal requirements

–

Also called non-functjonal propertjes

–

Cover other requirements than those relatjng to main functjon, for example expressing the frequency and severity of acceptable service failures

• Example non-functjonal requirements

–

Timeliness, availability, energy effjciency

Scalability

16

• Allow the system to become bigger without

negatjvely afgectjng performance

• Multjple dimensions:

– Size: Adding more resources and users – Geographic: Dispersed across locatjons – Administratjve: Spanning multjple administratjve

domains

Architectural roles

• Client-server

– Client implements the user interface – Server(s) has most of the functjonality

• Computatjon, data
• E.g.: Web
• Peer-to-peer (P2P)

– Each component is symmetric in functjonality – Peer: Combinatjon of server-client – No “well-known” centralized server

• Hybrid

– Combinatjon of the two

System organisatjon

• Centralised

– Most functjonality is in a single unit

• Decentralised

– Functjonality is spread across multjple units

Types of distributjon

• Vertjcal distributjon

– Logically difgerent components on difgerent machines – e.g., multjtjered architectures

• Horizonal distributjon

– Multjple logically equivalent parts – Potentjally operatjng on difgerent data

Physical two-tjred architectures

Alternatjve client-server organizatjons (a) – (e). 1-29

20

Exaple of horizontal distributjon

An example of horizontal distributjon of a Web service. 1-31

21

A taxonomy of architectural models

Distributed systems Peer-to-peer Client-server Decentralised & horizontally distributed Centralised Decentralised Horizontally distributed Vertically distributed Vertically distributed

Hybrid

...

• Horiz. & vert.

distributed

Interactjon

Interaction models

What affects timing in a distributed system?

Latency

Baspresentation LiU 2011-02-17

28

reference time t Timestamp of clock C C’(t)=1 (Perfect clock) C ’ ( t ) < 1 ( s l

• w

c l

• c

k ) C’(t) > 1 (fast clock)

Clock drift

Baspresentation LiU 2011-02-17

29

reference time t Timestamp of clock C C’(t)=1 (Perfect clock) C ’ ( t ) < 1 ( s l

• w

c l

• c

k ) C’(t) > 1 (fast clock)

Clock drift

Real clock

Two interactjon models

• Asynchronous

– No relatjon between computatjon rate at difgerent

nodes, No bound on message exchange delay, Clock drifu rates are arbitrary

• Synchronous

– Bounded message exchange delay, Related processing

rates at difgerent nodes, Clock drifu rates bounded

• Synchronous:

– Local clocks can be used to implement tjmeouts – Lack of response from another node can be interpreted as

detectjon of failure

– Hard to guarantee!

• Asynchronous:

– In the absence of global (synchronised) tjme one cannot

relate clocks at difgerent nodes

– How can events be ordered?

Implicatjons

Why do we need ordering?

When order matuers

Another problem: global state

P1 P2 P3 Time m2 m3 m1

Another problem: global state

P1 P2 P3 Time m1 m2 m3

Causal ordering

• A strict partjal order

– Antjsymmetrical – Transitjve – Irrefmexive

• Also known as: ”the happened-before relatjon”
• Rules:

– send(m) → receive(m) – e1 → e2 if e1 and e2 are local events on the same machine and e1

• ccurred before e2 according to the local tjme

– Transitjve closure

Consistent cuts (using partjal order)

P1 P2 P3 Time m1 m2 m3 If e2 is afuer the cut and e1 before the cut, then e2 → e1

Consistent cuts (using partjal order)

P1 P2 P3 Time m1 m2 m3 If e2 is afuer the cut and e1 before the cut, then e2 → e1

Consistent cuts (using partjal order)

P1 P2 P3 Time m1 m2 m3 Consistent! If e2 is afuer the cut and e1 before the cut, then e2 → e1

Consistent cuts (using partjal order)

P1 P2 P3 Time m1 m2 m3 If e2 is afuer the cut and e1 before the cut, then e2 → e1 Consistent!

Consistent cuts (using partjal order)

P1 P2 P3 Time m1 m2 m3 If e2 is afuer the cut and e1 before the cut, then e2 → e1 Consistent! Inconsistent!

Lamport tjmestamps

• Timestamps should follow the partjal event ordering
• A → B => C(A) < C(B)
• Not vice versa!
• 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

Faults and failures

• We will look into more detail into failure and related

notjons in lecture 5

• For now...
• Distributed systems can fail in nodes or channels
• Node/channel failures:

– Crash – Omission – tjming – Byzantjne (arbitrary)

Failure models