Areas for Discussion System Models 2 Joseph Spring School of Computer Science MCOM0083 - Distributed Systems and Security Lecture - System Models 2 1 Architectural Models Software Layers System Architecture Variations on the Client-Server Model Interfaces and Objects Design requirements (Handout) Fundamental Models Failure Model (Hand Out) Security Model (Hand Out) Lecture - System Models 2 2 Introduction Each of the models we have discussed share some fundamental properties, they all: Consist of processes that communicate with each other by sending messages over a computer network Share the design requirements as outlined in the handout, concerning in particular: Performance and reliability characteristics of processes and networks Security of the resources in the system Lecture - System Models 2 3 Introduction We now consider models based on these fundamental properties that allow us to be more specific regarding their: Characteristics Failures Security risks Lecture - System Models 2 4 The Modelling Process - General 1. Brainstorm (Real World) 2. Simplifying assumptions ( Real World) 3. Define the problem ( Real World) 4. Analyse the problem (Abstraction) 5. Solve the problem (Abstraction) 6. Interpret the result (in Real World) 7. Accept or return to model and modify assumptions Lecture - System Models 2 5 System Models In general system models contain The essential ingredients (2. Simplifying Assumptions) Those that we require in order to Understand Reason about some aspect of a systems behaviour System models need to address: What are the main entities in the system? How do these entities interact? What are the characteristics that affect their Individual behaviour Collective behaviour Lecture - System Models 2 6 Lecture - System Models 2 1
System Models Purpose of a model To make explicit the assumptions made regarding the system being modelled Given the assumptions to generalise concerning what is and is not possible These generalisations may take the form of General purpose algorithms Desirable properties that are guaranteed Guarantees will depend upon:» logical analysis and (if appropriate) mathematical proof System Models The models we wish to look assist in discussing and reasoning about: Interaction Failure Security We consider aspects of the interaction model: Lecture - System Models 2 7 Lecture - System Models 2 8 Interaction Computation occurs within processes Processes interact by passing messages, which result in: Communication between processes information flow Coordination between processes synchronisation ordering of activities Lecture - System Models 2 9 Lecture - System Models 2 10 Model must take into account: Communication takes place with delays Delays are often considerable Accuracy for coordination of independent processes limited by: Delays Notion of time Difficulty in maintaining same notion of time across all computers in a distributed system (See Chapter 10) Lecture - System Models 2 11 We consider two significant factors affecting interacting processes in a distributed system: Communication performance Often a limiting characteristic Time Impossible to maintain a single global notion of time Lecture - System Models 2 12 Lecture - System Models 2 2
Performance of communication channels Realised in model over a network in various ways For example: Implementation of streams Message passing Performance Characteristics Latency Bandwidth Jitter Lecture - System Models 2 13 Computer Clocks and Timing Events Each computer has its own internal clock Local processes (same machine) can therefore obtain a value for the current time Hence two processes on different machines can associate timestamps with their events However Clock drift different time values Clock drift rate differ on different machines Corrections are required on distributed systems E.g. Use GPS: accuracy approx 1 microsecond? Lecture - System Models 2 14 Variants of the Synchronous Distributed Systems Strong assumptions regarding time Asynchronous Distributed Systems No assumptions regarding time Synchronous DS Hadzilacos and Toueg (1994) Strong assumptions regarding time Define synchronous distributed system to be one such that: Time to execute each step of a process has known upper and lower bounds Each message transmitted over a channel is received within a known bounded time Each process has a local clock whose drift rate from real time has a known bound Lecture - System Models 2 15 Lecture - System Models 2 16 Asynchronous DS No assumptions regarding time Define an asynchronous distributed system to be one such that there are no bounds on: Process execution speeds One process step may take a picosecond, another a cenury; all that can be said is that each step may take an arbitrary length of time Message transmission delays One message from process A to Process B may take a picosecond, another a cenury; so as with the above, a message may be received after an arbitrarily long time Clock drift rates Again clock drift rates are arbitrary Lecture - System Models 2 17 Event Ordering We are often interested in knowing whether an event (e.g. sending or receiving a message) at a process occurred before, after or concurrently with another event at another process The execution of a system can be described in terms of events and their ordering despite the lack of accurate clocks Lecture - System Models 2 18 Lecture - System Models 2 3
Event Ordering - Example Consider following set of exchanges between a group of users X, Y, Z and A on mailing list X Y Z A send m 1 receive m 1 send m 2 receive m 1 Physical send m 3 Time t 1 t 2 t 3 receive m 1 Lecture - System Models 2 19 Event Ordering - Example We note the order, in particular, for the arrival of messages at A Message Subject re:meeting arrives from Z who has read the two messages from X and Y and references these Message Subject Meeting arrives from X Message Subject re:meeting arrives from Y who has read the message from X and references it Lecture - System Models 2 20 Event Ordering - Logical Ordering Messages are received after they have been sent! X sends m 1 before Y receives m 1 Y sends m 2 before Y receives m 2 Replies are sent after messages are received! Y receives m 1 before Y sends m 2 Event Ordering - Clocks If clocks could be synchronised then Each message could carry the time on the local computers clock at instant sent Messages m 1, m 2 and m 3 would have times t 1, t 2 and t 3 respectively, with t 1 < t 2 < t 3 Messages received could be displayed to users according to their time ordering If the clocks are roughly synchronised then these timestamps are often in the correct order Lecture - System Models 2 21 Lecture - System Models 2 22 Event Ordering Logical Time Lamport (1978) Clocks cannot be synchronised perfectly across a distributed system Lamport proposed a model of Logical Time To be used to provide an ordering among the events at processes running in different computers in a distributed system Allows order to be inferred without recourse to clocks Logical time takes the idea of logical ordering further by assigning a number to each event Event Ordering Logical Time The numbers are assigned to each event according to its logical ordering Higher numbers are associated with later events X Y 1 4 send m 1 receive m 1 send m 2 2 3 Lecture - System Models 2 23 Lecture - System Models 2 24 Lecture - System Models 2 4
Summary Architectural Models Software Layers System Architecture Variations on the Client-Server Model Interfaces and Objects Design requirements (Handout) Fundamental Models Failure Model Security Model Lecture - System Models 2 25 References Coulouris, Dollimore & Kindberg: Distributed Systems Concepts and Design, Addison Wesley, 2001, ISBN 0201-61918-0 Hadzilacos, V. and Toueg, S. (1994). A Modular Approach to Fault-tolerant Broadcasts and Related Problems, Technical Report, Department of Computer Science, University of Toronto Lamport, L. (1978). Time, clocks and the ordering of events in a distributed system. Comms. ACM, Vol. 21, No. 7, pp.558-565 Lecture - System Models 2 26 Lecture - System Models 2 5