1. 1 Lecture 2: System Models Haibin Zhu, PhD. Assistant Professor Department of Computer Science Nipissing University © 2003

2. 2 Why have system models? zMake assumptions clear zOrganize and classify different approaches zMake generalizations

3. 3 Architectural model zDefines 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. yStructure in terms of separately specified components. yPlacement of components across a network of computers yInterrelationships between components yDivision of responsibilities among components

4. 4 Terminology zserver yprocess that accepts requests from other process. zservice yWhat provided by one or more servers zplatform yhardware and underlying operating system zmiddleware ysoftware layer that masks heterogeneity and provides a programming model

5. 5 Figure 2.1 Software and hardware service layers in distributed systems RPC, CORBA, DCOM, RMI

6. 6 Client/Server zServer: A subsystem that provides a particular type of service to a priori unknown clients. zControl functionally distributed among the various servers in the system. zControl of individual resources is centralized in a server(localized?) zProblems: y Reliability/Availability y Scalability y Replication?

7. 7 Figure 2.2 Clients invoke individual servers

8. 8 Figure 2.3 A service provided by multiple servers

9. 9 Figure 2.4 Web proxy server cache

10. 10 Peer processes zAll of the processes play similar roles, interacting cooperatively as peers to perform a distributed activity or computation without any distinction between clients and servers.

11. 11 Figure 2.5 A distributed application based on peer processes

12. 12 Variations on the client-server model zMobile code zMobile agents zNetwork computers zThin clients

13. 13 Figure 2.6 Web applets

14. 14 Mobile Agent zA 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. zIt is a potential security threat to the resources in computers that they visit.

15. 15 Network Computers zIt downloads its operating system and any application software needed by the user from a remote file server. zIts 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. zLow cost on hardware and management.

16. 16 Figure 2.7 Thin clients and compute servers Thin Client Application Process Network computer or PC Compute server network 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.

17. 17 Design requirements for distributed architecture zPerformance yResponsiveness & Throughput zQoS (Quality of Services) yReliability, Security, Performance, & Adaptability zCaching and replication zDependability yCorrectness, security, & fault tolerance

18. 18 Fundamental Models zA model includes: yMain entities yInteractions yIndividual and collective characteristics zInteraction: yHow do components interact and coordinate to solve a problem? zFailure: yWhat are the potential failures and how do they affect the results? zSecurity: yWhat are the system’s vulnerabilities and how should they be handled?

19. 19 Interaction models zProcesses interact through message-passing to solve a problem. zInteraction is influenced by: yPerformance of the communication channels ySynchronization of the clocks

20. 20 Communication performance: zLatency yThe delay between the sending of a message by one process and its receipt by another xData, network, and OS zBandwidth yThe total amount of information that can be transmitted over a (network) in a given time. zJitter yVariation in time taken to deliver a series of messages.

21. 21 Clocks and event ordering: zMessages are often time-stamped to indicate ordering. zEach computer has at least one local clock. zTime-stamps are often based on local clock values. zLocal clocks aren’t synchronized.

22. 22 Synchronous & Asynchronous distributed system: zSynchronous yCan bound: xTime for each processing step xTime to transmit each message xClock drift for each process. zAsynchronous yNo bounds on: xTime for each processing step xTime to transmit each message xClock drift for each process.

23. 23 Event ordering: zWhen does an event (sending or receiving a message) from one process occur relative to an event from another process? zA mailing list contains users X, Y, Z and A yX sends an email to the list with subject Meeting: (m1) yY and Z reply by sending each a message to the list with subject Re: Meeting (m2 and m3 respectively) zExample: What are the possible orderings of messages in the following scenario?

24. 24 Figure 2.9 Real-time ordering of events

25. 25 Logical time zProvide proper ordering of events without reference to physical clocks (Lamport, 1978). yExample: In the email scenario: xX sends m1 before Y sends m2 xY sends m2 before X receives m2 xY receives m1 before Y sends m2

26. 26 Failure models zCDK: z“…(define) the ways in which failure may occur in order to provide and understanding of the effects of failures.” yOmission failures - process or channel fails to do something xProcess and communication yArbitrary failures - usually refer to sabotage xNot only do not good, but also do bad yTiming failures - required time bounds are exceeded

27. 27 Figure 2.10 Processes and channels

28. 28 Figure 2.11 Omission and 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.

29. 29 Figure 2.12 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.

30. 30 Reliable one-to-one communication zValidity - any message in the outgoing message buffer is eventually delivered to the incoming message buffer zIntegrity - the received message is identical to the sent message and is delivered exactly once. zThe threats to integrity: yRetransmission ySpurious message

31. 31 Security model zProtect processes and channels from corruption. zProtect resources (encapsulated by objects) from unauthorized access.

32. 32 Figure 2.13 Objects and principals

33. 33 Figure 2.14 The enemy Communication channel Copy of m Process p q m The enemy m’ Threats to processes; Threats to communication channels and Denial of services

34. 34 Figure 2.15 Secure channels Principal A Secure channel Process p q Principal B 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.

35. 35 Basic terminology zCryptography - science of keeping information secure zEncryption - scrambling a message to hide its contents zAuthentication - method for assuring the true identity of an entity

36. 36 Summary zArchitectural Model ySoftware layers ySystem architectures xClient/server xProxy server xPeer server xMobile code and mobile agent xNetwork computers and thin clients xSpontaneous networking zFundamental models yInteraction model yFailure model ySecurity model