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- of-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

This lecture ● Basic aspects afgectjng design ● Distributed systems architectures and models

Why is it hard to get it right? ● Variatjons in workload, connectjvity, mobility, requirements ● Heterogeneity in systems environment, hardware, operatjng systems, and networks ● Consequences of tjming and failure issues ● Security threats, and distributed atuacks

Overview ● Architectural models ● Interactjon models ● Faults and failures

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 ● Placement of processes and data across a network of computers ● Patuerns of communicatjon to achieve functjonal and extra(non)-functjonal propertjes What are these? ● Challenges: Scalability, interoperability

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 ● 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 16

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 1-31 An example of horizontal distributjon of a Web service. 21

A taxonomy of architectural models Distributed systems Hybrid Peer-to-peer Client-server ... Decentralised & horizontally Centralised Decentralised distributed Vertically distributed Vertically Horizontally Horiz. & vert. distributed distributed distributed

Interaction models Interactjon

What affects timing in a distributed system?

Latency

Clock drift C’(t) > 1 (fast clock) C’(t)=1 (Perfect clock) Timestamp of clock C ) k c o l c w o l s ( 1 < ) t ( ’ C reference time t 28 2011-02-17 Baspresentation LiU

Clock drift Real clock C’(t) > 1 (fast clock) C’(t)=1 (Perfect clock) Timestamp of clock C ) k c o l c w o l s ( 1 < ) t ( ’ C reference time t 29 2011-02-17 Baspresentation LiU

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

Implicatjons ● 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?

Why do we need ordering?

When order matuers

Another problem: global state Time P1 m3 m1 P2 m2 P3

Another problem: global state Time P1 m3 m1 P2 m2 P3

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 occurred before e2 according to the local tjme – Transitjve closure

Consistent cuts (using partjal order) If e2 is afuer the cut and e1 before the cut, then e2 → e1 Time P1 m3 m1 P2 m2 P3

Consistent cuts (using partjal order) If e2 is afuer the cut and e1 before the cut, then e2 → e1 Time P1 m3 m1 P2 m2 P3

Consistent cuts (using partjal order) If e2 is afuer the cut and e1 before the cut, then e2 → e1 Time P1 m3 m1 P2 m2 P3 Consistent!

Consistent cuts (using partjal order) If e2 is afuer the cut and e1 before the cut, then e2 → e1 Time P1 m3 m1 P2 m2 P3 Consistent!

Consistent cuts (using partjal order) If e2 is afuer the cut and e1 before the cut, then e2 → e1 Time P1 m3 m1 P2 m2 P3 Inconsistent! Consistent!

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

Faults and failures Failure

Failure models ● 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)