Chapter 2: System Models

Objectives To provide students with conceptual models to support their study of distributed systems. To motivate the study of many of the design problems and solutions.

Introduction 2 types which are: ~ Architectural models ~ Fundamental models

 P rovide a high-level view of the distribution of functionality between components and the relationships between them.  Models determine the distribution of data and computational tasks among the physical nodes of the system.  Helpful when evaluating the performance, reliability, scalability and other properties of distributed systems. Architectural Models

Architectural models (cont.) Architectural model consider: placement of the components across a network of computers - define useful pattern for distribution data or workload interrelationship between components – functional pattern of communication between them.

Architectural models (cont.) Software Layers What is “Software architecture” ? - structuring of software as layers or modules in a single computer - services offered & requested between process located in same or different computer

Fig. 2.1: Software & hardware service layers in DS Applications, services Computer and network hardware Platform Operating system Middleware

 2 main types of architecture model: ~ Client-server model ~ Peer-to-peer model  Client-server model can be modified by: ~ Partitioning of data or replication at cooperating servers ~ Caching of data by proxy servers & clients ~ Use of mobile code & agents ~ Requirement to add & remove mobile devices in a convenient manner Architectural models (cont.)

Fig. 2.2: Clients invoke individual servers Server Client invocation result Server invocation result Process: Key: Computer:

Peer-to-peer model ~ Process involved in task/activity play similar roles ~ interactively cooperating as peers without any distinction between client and server process ~ exploit resources in a large number of participating computers for fulfillment of a given task Architectural models (cont.)

Fig. 2.3: A distributed application based on peer processes

Variation derived based on factor: ~ use multiple servers and caches to ↑ performance & resilience ~ use mobile code & mobile agent ~ user need for ↓ cost computers with limited hardware resources that are simple to manage ~ requirement to add & remove mobile devices in a convenient manner Architectural models (cont.)

Fig. 2.4: A service provided by multiple servers

Proxy servers & caches: Cache ~ Store of recent used data object that is closer than object themselves. ~ When a new object is received at a computer, cache store, replacing some object necessarily. ~ Caches may be allocated with each they may be allocated at proxy server. Proxy server ~ ↑ availability & performance of services by reduced load of WAN and web servers ~ May be used to access remote web servers through a firewall Architectural models (cont.)

Fig. 2.5: Web proxy server Client Proxy Web server Web server Client

Fig. 2.6: Web applets a) Client request results in the downloading of applet code Web server Client Web server Applet Applet code Client b) Client interacts with the applet Applet are well-known and widely used example of mobile code.

Fig. 2.7: Thin clients & compute servers Thin Client Application Process Network computer or PC Compute server network Thin client ~ software layer that supports a window based user interface on a computer ~ local to the user while execution application programs on a remote computer.

 Issues that addressed in the design of DS.  3 fundamental models: ~ Interaction Model ~ Failure Model ~ Security Model Fundamental Models

Interaction Model ~ Synchronous DS by Hadzilacos & Touge[1994] - time to execute each step of process has known lower & upper 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 bounded time Fundamental Models (cont.)

Interaction Model ~ Asynchronous DS has no bounds on: - process execution speed: -> a process step may take only a picoseconds and another a century. - message transmission delays -> a message from process A to B may be delivered in negligible time & another make take several years - clock drift rate Fundamental Models (cont.)

Interaction Model ~ Event Ordering - Event (sending or receiving message) at one process occurred before, after or concurrently with another event at another process - Execution of a system can be in terms of events & ordering despite the lack of accurate clock Fundamental Models (cont.)

Fig. 2.8: Real-time ordering of events

Failure Model ~ Hadzilacos & Touge [1994] provide a taxonomy distinguish between failure of process & communication channel: - Omission failure - Arbitrary failure - Timing failure Fundamental Models (cont.)

Fig.2.9: Processes and channels process p q Communication channel send Outgoing message buffer Incoming message buffer receivem

Fig. 2.10: Omission & arbitrary failures Class of failureAffectsDescription Fail-stopProcessProcess halts and remains halted. Other processes may detect this state. CrashProcessProcess halts and remains halted. Other processes may not be able to detect this state. OmissionChannelA message inserted in an outgoing message buffer never arrives at the other end’s incoming message buffer. Send-omissionProcessA process completes asend, but the message is not put in its outgoing message buffer. Receive-omissionProcessA message is put in a process’s incoming message buffer, but that process does not receive it. Arbitrary (Byzantine) Process or channel Process/channel exhibits arbitrary behaviour: it may send/transmit arbitrary messages at arbitrary times, commit omissions; a process may stop or take an incorrect step.

Fig. 2.11: Timing failures Class of FailureAffectsDescription ClockProcessProcess’s local clock exceeds the bounds on its rate of drift from real time. PerformanceProcessProcess exceeds the bounds on the interval between two steps. PerformanceChannelA message’s transmission takes longer than the stated bound.

Security Model ~ Securing the processes & the channels used for their interaction ~ Protecting objects that they encapsulated against unauthorized access Fundamental Models (cont.)

Fig. 2.12: Objects & principals

Fig. 2.13: The enemy Communication channel Copy of m Process p q m The enemy m’

Fig. 2.14: Secure channels Principal A Secure channel Process p q Principal B