Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Lecture 2: System Models Haibin Zhu, PhD. Assistant Professor Department of Computer Science Nipissing University © 2003 1 Why have system models? Make assumptions clear Organize and classify different approaches Make generalizations 2 Architectural model Defines the way in which the components of systems interact with one another and the way in which they are mapped onto an underlying network of computers. Structure in terms of separately specified components. Placement of components across a network of computers Interrelationships between components Division of responsibilities among components 3 Terminology server process that accepts requests from other process. service What provided by one or more servers platform hardware and underlying operating system middleware software layer that masks heterogeneity and provides a programming model 4 Figure 2.1 Software and hardware service layers in distributed systems Applic ations, services Middlew are RPC, CORBA, DCOM, RMI Operating sy stem Platform Computer and netw ork hardw are 5 Client/Server Server: A subsystem that provides a particular type of service to a priori unknown clients. Control functionally distributed among the various servers in the system. Control of individual resources is centralized in a server(localized?) Problems: Reliability/Availability Scalability Replication? 6 Figure 2.2 Clients invoke individual servers Client inv oc ation result inv oc ation Server Server result Client Key: Proc es s: Computer: 7 Figure 2.3 A service provided by multiple servers Service Server Client Server Client Server 8 Figure 2.4 Web proxy server Web s erv er Client Prox y s erv er Client cache Web s erv er 9 Peer processes All of the processes play similar roles, interacting cooperatively as peers to perform a distributed activity or computation without any distinction between clients and servers. 10 Figure 2.5 A distributed application based on peer processes Applic ation Applic ation Coordination c ode Coordination c ode Applic ation Coordination c ode 11 Variations on the client-server model Mobile code Mobile agents Network computers Thin clients 12 Figure 2.6 Web applets a) client request res ults in the dow nloading of applet c ode Client Applet code Web s erv er b) client interac ts w ith the applet Client Applet Web s erv er 13 Mobile Agent A running programming including both code and data that travels from one computer to another in a network carrying out a task on someone’s behalf, such as collecting information, eventually returning with the results. It is a potential security threat to the resources in computers that they visit. 14 Network Computers It downloads its operating system and any application software needed by the user from a remote file server. Its disk (if included) holds only a minimum of software. The extra space is used as a cache holding copies of software and data files that have recently loaded from servers. Low cost on hardware and management. 15 Figure 2.7 Thin clients and compute servers •A software layer that supports a window-based user interface on a computer that is local to the user while executing application programs on a remote computer. •Low cost on hardware and management. Compute server Network computer or PC Thin Client network Application Process 16 Design requirements for distributed architecture Performance Responsiveness & Throughput QoS (Quality of Services) Reliability, Security, Performance, & Adaptability Caching and replication Dependability Correctness, security, & fault tolerance 17 Fundamental Models A model includes: Main entities Interactions Individual and collective characteristics Interaction: How do components interact and coordinate to solve a problem? Failure: What are the potential failures and how do they affect the results? Security: What are the system’s vulnerabilities and how should they be handled? 18 Interaction models Processes interact through message-passing to solve a problem. Interaction is influenced by: Performance of the communication channels Synchronization of the clocks 19 Communication performance: Latency The delay between the sending of a message by one process and its receipt by another Data, network, and OS Bandwidth The total amount of information that can be transmitted over a (network) in a given time. Jitter Variation in time taken to deliver a series of messages. 20 Clocks and event ordering: Messages are often time-stamped to indicate ordering. Each computer has at least one local clock. Time-stamps are often based on local clock values. Local clocks aren’t synchronized. 21 Synchronous & Asynchronous distributed system: Synchronous Can bound: Time for each processing step Time to transmit each message Clock drift for each process. Asynchronous No bounds on: Time for each processing step Time to transmit each message Clock drift for each process. 22 Event ordering: When does an event (sending or receiving a message) from one process occur relative to an event from another process? A mailing list contains users X, Y, Z and A X sends an email to the list with subject Meeting: (m1) Y and Z reply by sending each a message to the list with subject Re: Meeting (m2 and m3 respectively) Example: What are the possible orderings of messages in the following scenario? 23 Figure 2.9 Real-time ordering of events s end X receiv e 1 m1 2 Y receiv e 4 s end 3 m2 receiv e Phy sical time receiv e s end Z receiv e receiv e m3 A t1 t2 m1 m2 receiv e receiv e receiv e t3 24 Logical time Provide proper ordering of events without reference to physical clocks (Lamport, 1978). Example: In the email scenario: X sends m1 before Y sends m2 Y sends m2 before X receives m2 Y receives m1 before Y sends m2 25 Failure models CDK: “…(define) the ways in which failure may occur in order to provide and understanding of the effects of failures.” Omission failures - process or channel fails to do something Process and communication Arbitrary failures - usually refer to sabotage Not only do not good, but also do bad Timing failures - required time bounds are exceeded 26 Figure 2.10 Processes and channels proc es sp proc es s q send m receiv e Communic ation c hannel Outgoing mes sage buffer Inc oming mes sage buffer 27 Figure 2.11 Omission and arbitrary failures Class of failure Fail-stop Affects Process Description 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. 28 Figure 2.12 Timing failures Class of Failure Clock Affects Process Performance Process Performance Channel Description Process’s local clock exceeds the bounds on its rate of drift from real time. Process exceeds the bounds on the interval between two steps. A message’s transmission takes longer than the stated bound. 29 Reliable one-to-one communication Validity - any message in the outgoing message buffer is eventually delivered to the incoming message buffer Integrity - the received message is identical to the sent message and is delivered exactly once. The threats to integrity: Retransmission Spurious message 30 Security model Protect processes and channels from corruption. Protect resources (encapsulated by objects) from unauthorized access. 31 Figure 2.13 Objects and principals Ac cess rights Object inv oc ation Client result Principal (user) Netw ork Server Principal (s erv er) 32 Figure 2.14 The enemy •Threats to processes; •Threats to communication channels and •Denial of services Copy of m The enemy Process p m’ m Process q Communication channel 33 Figure 2.15 Secure channels •Encryption and authorization are used to build secure channels as a service layer on top of existing communication services. •Both processes are the authorities of accessing rights. Principal B Principal A Process p Secure channel Process q 34 Basic terminology Cryptography - science of keeping information secure Encryption - scrambling a message to hide its contents Authentication - method for assuring the true identity of an entity 35 Summary Architectural Model Software layers System architectures Client/server Proxy server Peer server Mobile code and mobile agent Network computers and thin clients Spontaneous networking Fundamental models Interaction model Failure model Security model 36