340 likes | 538 Views
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.
E N D
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
Architectural Models • Provide 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 (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
Applications, services Middleware Operating system Platform Computer and network hardware Fig. 2.1: Software & hardware service layers in DS
Architectural models (cont.) • 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
Client Server invocation invocation result result Server Client Key: Process: Computer: Fig. 2.2: Clients invoke individual servers
Architectural models (cont.) 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
Peer 2 Peer 1 Application Application Sharable objects Peer 3 Application Peer 4 Application Peers 5 .... N Fig. 2.3: A distributed application based on peer processes
Architectural models (cont.) 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.) 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 client @ 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
Web server Client Proxy server Web Client server Fig. 2.5: Web proxy server
a) Client request results in the downloading of applet code Web Client server Applet code b) Client interacts with the applet Web Applet Client server Fig. 2.6: Web applets Applet are well-known and widely used example of mobile code.
Compute server Network computer or PC Application network Thin Process Client Fig. 2.7: Thin clients & compute servers 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.
Fundamental Models • Issues that addressed in the design of DS. • 3 fundamental models: ~ Interaction Model ~ Failure Model ~ Security Model
Fundamental Models (cont.) 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.) Failure Model ~ Hadzilacos & Touge [1994] provide a taxonomy distinguish between failure of process & communication channel: - Omission failure - Arbitrary failure - Timing failure
process p process q send m receive Communication channel Outgoing message buffer Incoming message buffer Fig.2.9: Processes and channels
Class of failure Affects Description Fail-stop Process Process halts and remains halted. Other processes may detect this state. Crash Process Process halts and remains halted. Other processes may not be able to detect this state. Omission Channel A message inserted in an outgoing message buffer never arrives at the other end’s incoming message buffer. Send-omission Process A process completes a send, but the message is not put in its outgoing message buffer. Receive-omission Process A message is put in a process’s incoming message buffer, but that process does not receive it. Arbitrary Process or Process/channel exhibits arbitrary behaviour: it may (Byzantine) channel send/transmit arbitrary messages at arbitrary times, commit omissions; a process may stop or take an incorrect step. Fig. 2.10: Omission & arbitrary failures
Class of Failure Affects Description Clock Process Process’s local clock exceeds the bounds on its rate of drift from real time. Performance Process Process exceeds the bounds on the interval between two steps. Performance Channel A message’s transmission takes longer than the stated bound. Fig. 2.11: Timing failures
Fundamental Models (cont.) Security Model ~ Securing the processes & the channels used for their interaction ~ Protecting objects that they encapsulated against unauthorized access
Fig. 2.13: The enemy Copy of m The enemy m’ Process Process m p q Communication channel
PrincipalB Principal A Process Process Secure channel p q Fig. 2.14: Secure channels