1 / 91

Outline

Outline Announcement Midterm Review Distributed File Systems – continued If we have time Announcements Please turn in your homework #3 at the beginning of class The midterm will be on March 20 This coming Thursday It will be an open-book, open-note exam Operating System

Faraday
Download Presentation

Outline

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Outline • Announcement • Midterm Review • Distributed File Systems – continued • If we have time COP5611

  2. Announcements • Please turn in your homework #3 at the beginning of class • The midterm will be on March 20 • This coming Thursday • It will be an open-book, open-note exam COP5611

  3. Operating System • An operating system is a layer of software on a bare machine that performs two basic functions • Resource management • To manage resources so that they are used in an efficient and fair manner • User friendliness COP5611

  4. Distributed Systems • A distributed system is a collection of independent computers that appears to its users as a single coherent system • Independent computers mean that they do not share memory or clock • The computers communicate with each other by exchanging messages over a communication network COP5611

  5. Distributed Systems – cont. COP5611

  6. Distributed Systems – cont. • Advantages • The computing power of a group of cheap workstations can be enormous • Decisive price/performance advantage over traditional time-sharing systems • Resource sharing • Enhanced performance • Improved reliability and availability • Modular expandability COP5611

  7. Distributed System Architecture – cont. • Distributed systems are often classified based on the hardware • Multiprocessor systems • Homogenous multi-computer systems • Heterogeneous multi-computer systems COP5611

  8. Distributed Operating Systems • Hardware for distributed systems is important, but the software largely determines what a distributed system looks like to a user • Distributed operating systems are much like the traditional operating systems • Resource management • User friendliness • The key concept is transparency COP5611

  9. Distributed Operating Systems – cont. • In a truly distributed operating system, the user views the system as a virtual uniprocessor system even though physically it consists of multiple computers • In other words, the use of multiple computers and accessing remote data and resources should be invisible to the user COP5611

  10. Overview of Different Kinds of Distributed Systems COP5611

  11. Multicomputer Operating Systems • General structure of a multicomputer operating system COP5611

  12. Network Operating System 1-19 COP5611

  13. Middleware and Openness • In an open middleware-based distributed system, the protocols used by each middleware layer should be the same, as well as the interfaces they offer to applications. 1.23 COP5611

  14. Comparison Between Systems COP5611

  15. Issues in Distributed Operating Systems • Absence of global knowledge • In a distributed system, due to the unavailability of a global memory and a global clock and due to unpredictable message delays, it is practically impossible to for a computer to collect up-to-date information about the global state of the distributed system • Therefore a fundamental problem is to develop efficient techniques to implement a decentralized system wide control • Another problem is how to order all the events COP5611

  16. Issues in Distributed Operating Systems – cont. • Naming • Plays an important role in achieving location transparency • A name service maps a logical name into a physical address by making use of a table lookup, an algorithm, or a combination of both • In distributed systems, the tables may be replicated and stored at many places • Consider naming in a distributed file system COP5611

  17. Issues in Distributed Operating Systems – cont. • Scalability • Systems generally grow with time, especially distributed systems • Scalability requires that the growth should not result in system unavailability or degraded performance • This puts additional constraints on design approaches COP5611

  18. Issues in Distributed Operating Systems – cont. • Compatibility • Refers to the interoperability among the resources in a system • Three different levels • Binary level • All processors execute the same binary instruction repertoire • Virtual binary level • Execution level • Same source code can be compiled and executed properly • Protocol level • A common set of protocols COP5611

  19. Issues in Distributed Operating Systems – cont. • Process synchronization • The synchronization of processes in distributed systems is difficult because of the unavailability of shared memory • It needs to synchronize processes running on different computers when they try to concurrently access a shared resource • This is the mutual exclusion problem as in classical operating systems COP5611

  20. Issues in Distributed Operating Systems – cont. • Resource management • Resource management needs to make both local and remote resources available to uses in an effective manner • Data migration • Distributed file system • Distributed shared memory • Computation migration • Remote procedure call • Distributed scheduling COP5611

  21. Issues in Distributed Operating Systems – cont. • Structuring • The distributed operating system requires some additional constraints on the structure of the underlying operating system • The collective kernel structure • An operating system is structured as a collection of processes that are largely independent of each other • Object-oriented operating system • The operating system’s services are implemented as objects COP5611

  22. Clients and Servers • General interaction between a client and a server. COP5611

  23. Layered Protocols • Layers, interfaces, and protocols in the OSI model. COP5611

  24. Network Layer • The primary task of a network layer is routing • The most widely used network protocol is the connection-less IP (Internet Protocol) • Each IP packet is routed to its destination independent of all others • A connection-oriented protocol is gaining popularity • Virtual channel in ATM networks COP5611

  25. Transport Layer • This layer is the last part of a basic network protocol stack • In other words, this layer can be used by application developers • An important aspect of this layer is to provide end-to-end communication • The Internet transport protocol is called TCP (Transmission Control Protocol) • The Internet protocol also supports a connectionless transport protocol called UDP (Universal Datagram Protocol) COP5611

  26. Sockets • Socket primitives for TCP/IP. COP5611

  27. Sockets – cont. • Connection-oriented communication pattern using sockets. COP5611

  28. Socket Programming • Review • IP • TCP • UDP • Port • Server Design Issues • Iterative vs. concurrent server • Stateless vs. stateful server • Multithreaded server COP5611

  29. A Multithreaded Server COP5611

  30. The Message Passing Model • The message passing model provides two basic communication primitives • Send and receive • Send has two logical parameters, a message and its destination • Receive has two logical parameters, the source and a buffer for storing the message COP5611

  31. Semantics of Send and Receive Primitives • There are several design issues regarding send and receive primitives • Buffered or un-buffered • Blocking vs. non-blocking primitives • With blocking primitives, the send does not return control until the message has been sent or received and the receive does not return control until a message is copied to the buffer • With non-blocking primitives, the send returns control as the message is copied and the receive signals its intention to receive a message and provide a buffer for it COP5611

  32. Semantics of Send and Receive Primitives – cont. • Synchronous vs. asynchronous primitives • With synchronous primitives, a SEND primitive is blocked until a corresponding RECEIVE primitive is executed • With asynchronous primitives, a SEND primitive does not block if there is no corresponding execution of a RECEIVE primitive • The messages are buffered COP5611

  33. Remote Procedure Call • RPC is designed to hide all the details from programmers • Overcome the difficulties with message-passing model • It extends the conventional local procedure calls to calling procedures on remote computers COP5611

  34. Steps of a Remote Procedure Call – cont. COP5611

  35. Remote Procedure Call – cont. • Design issues • Structure • Mostly based on stub procedures • Binding • Through a binding server • The client specifies the machine and service required • Parameter and result passing • Representation issues • By value and by reference COP5611

  36. Remote Object Invocation • Extend RPC principles to objects • The key feature of an object is that it encapsulates data (called state) and the operations on those data (called methods) • Methods are made available through an interface • The separation between interfaces and the objects implementing these interfaces allows us to place an interface at one machine, while the object itself resides on another machine COP5611

  37. Distributed Objects • Common organization of a remote object with client-side proxy. COP5611

  38. Inherent Limitations of a Distributed System • Absence of a global clock • In a centralized system, time is unambiguous • In a distributed system, there exists no system wide common clock • In other words, the notion of global time does not exist • Impact of the absence of global time • Difficult to reason about temporal order of events • Makes it harder to collect up-to-date information on the state of the entire system COP5611

  39. Inherent Limitations of a Distributed System • Absence of shared memory • An up-to-date state of the entire system is not available to any individual process • This information, however, is necessary to reason about the system’s behavior, debugging, recovering from failures COP5611

  40. Lamport’s Logical Clocks • Logical clocks • For a wide of algorithms, what matters is the internal consistency of clocks, not whether they are close to the real time • For these algorithms, the clocks are often called logical locks • Lamport proposed a scheme to order events in a distributed system using logical clocks COP5611

  41. Lamport’s Logical Clocks – cont. • Definitions • Happened before relation • Happened before relation () captures the causal dependencies between events • It is defined as follows • a  b, if a and b are events in the same process and a occurred before b. • a  b, if a is the event of sending a message m in a process and b is the event of receipt of the same message m by another process • If a  b and b  c, then a  c, i.e., “” is transitive COP5611

  42. Lamport’s Logical Clocks – cont. • Definitions – continued • Causally related events • Event a causally affects event b if a  b • Concurrent events • Two distinct events a and b are said to be concurrent (denoted by a || b) if a  b and b  a • For any two events, either a  b, b  a, or a || b COP5611

  43. Lamport’s Logical Clocks – cont. • Implementation rules • [IR1] Clock Ci is incremented between any two successive events in process Pi Ci := Ci + d ( d > 0) • [IR2] If event a is the sending of message m by process Pi, then message m is assigned a timestamp tm = Ci(a). On receiving the same message m by process Pj, Cj is set to Cj := max(Cj, tm + d) COP5611

  44. An Example COP5611

  45. Total Ordering Using Lamport’s Clocks • If a is any event at process Pi and b is any event at process Pj, then a => b if and only if either • Where is any arbitrary relation that totally orders the processes to break ties COP5611

  46. A Limitation of Lamport’s Clocks • In Lamport’s system of logical clocks • If a  b, then C(a) < C(b) • The reverse if not necessarily true if the events have occurred on different processes COP5611

  47. A Limitation of Lamport’s Clocks COP5611

  48. Vector Clocks • Implementation rules • [IR1] Clock Ci is incremented between any two successive events in process Pi Ci[i] := Ci[i] + d ( d > 0) • [IR2] If event a is the sending of message m by process Pi, then message m is assigned a timestamp tm = Ci(a). On receiving the same message m by process Pj, Cj is set to Cj[k] := max(Cj[k], tm[k]) COP5611

  49. Vector Clocks – cont. COP5611

  50. Vector Clocks – cont. • Assertion • At any instant, • Events a and b are casually related if ta < tb or tb < ta. Otherwise, these events are concurrent • In a system of vector clocks, COP5611

More Related