Distributed Operating System

1. Distributed Operating System Dr. Rahila Sheikh, PhD(CSE) Associate Professor, CSE Dept ACET, Sadar, Nagpur Email : rahila.patel@gmail.com

2. Definition of Distributed System • Autonomous processors communicating over a communication network • Some characteristics • No common physical clock • No shared memory • Geographical separation • Autonomy and heterogeneity Dr.Rahila Sheikh

3. Definition of a Distributed System Figure 1-1. A distributed system organized as middleware. The middleware layer runs on all machines, and offers a uniform interface to the system Dr.Rahila Sheikh

4. Middleware Examples • CORBA (Common Object Request Broker Architecture) • DCOM (Distributed Component Object Management) – being replaced by .net • Sun’s ONC RPC (Remote Procedure Call) • RMI (Remote Method Invocation) • SOAP (Simple Object Access Protocol) Dr.Rahila Sheikh

5. Relation between Software Components Dr.Rahila Sheikh

6. Distributed System Overview Dr.Rahila Sheikh

7. Example of Distributed System Dr.Rahila Sheikh

8. Examples of distributed systems • Intranets, Internet, WWW, email, ... • DNS (Domain Name Server) - Hierarchical distributed database • Distributed supercomputers, Grid/Cloud computing • Electronic banking • Airline reservation systems • Peer-to-peer networks • Sensor networks • Mobile and Pervasive Computing Dr.Rahila Sheikh

9. Motivation for Distributed System • Inherently distributed computation • Resource sharing • Access to remote resources • Increased performance/cost ratio • Reliability • - Availability, integrity, fault-tolerance • Scalability • Modularity and incremental expandability Dr.Rahila Sheikh

10. Classification of Distributed system • Minicomputer Model • Workstation Model • Processor Pool Model Dr.Rahila Sheikh

11. Distributed Operating System • A distributed operating system appears to user a centralized operating system for a single machine, but it runs on multiple –independent computers • An identical copy of OS ( or a different OS) may run at every computer • The key concept is transparency- use of multiprocessors and accessing remote data should be invisible to user. • User view should be a virtual uniprocessor • Distributed operating systems differ from network operating systems in supporting a transparent view of the entire network, in which users normally do not distinguish local resources from remote resources. Dr.Rahila Sheikh

12. List of Distributed Operating Systems AEGISOS for the Apollo DOMAIN Distributed system. Early 1980s. AMOEBAA distributed OS based partly on UNIX. Based on passive data objects protected by encrypted capabilities. 1980s [Tanenbaum & Mullender 1981, Mullender & Tanenbaum 1986]. Arachne A distributed operating system developed at the U. of Wisconsin. Late 1970s [Finkel 1980]. Charlotte Distributed OS for the Crystal Multicomputer project at the U. of Wisconsin. Explores coarse-grained parallelism without shared memory for computationally intensive tasks. 1980s [Finkel et al 1989]. CHOICES Distributed, object-oriented OS featuring a high degree of customization. U. of Idaho, 1990s [Campbell et al 1993]. Clouds A distributed object-based operating system developed at Georgia Institute of Technology. Early 1990s. [DasGupta 1991]CMDSThe Cambridge Model Distributed System. U. of Cambridge (England). Late 1970s [Wilkes & Needham 1980]. CONDORA distributed OS described as a "hunter of idle workstations," which distributes large computationally intensive jobs among available processors in a workstation pool. U. Wisconsin at Madison, 1980s [Litzkow 1988]. Cronus Object-oriented distributed computing system for heterogenous environments. BBN Systems, 1980s [Schantz et al 1986]. DEMOS/MPA distributed version of the DEMOS operating system. Message-based, featuring process migration. U.C. Berkeley, early 1980s [Miller et al 1984]. Dr.Rahila Sheikh

13. Issues In Distributed Operating System • Global Knowledge • Naming • Scalability • Compatibility • Process Synchronization • Resource Management • Data Migration • Computation Migration • Distributed scheduling • Security • Structuring • Monolithic Kernel • The collective Kernel Structure • Object Oriented Operating System • Client –Server Computing Model Dr.Rahila Sheikh

14. Global Knowledge Due to unavailability of a global memory and a global clock and due to unpredictable message delay, it is practically impossible to for a computer to collect Up-to-date information about the global state of the distributed computing system. Absence of global clock leads to problem of ordering of events that occur at different times at different computers present in the system Dr.Rahila Sheikh

15. Naming Names are used to refer to objects (like computers,printersservices,files….) An example of service is name service Name service maps a logical name onto physical address by making use of a table lookup In distributed system directories may be replicated and stored at many different locations to overcome a single point of failure as well as to increase the availability of name service. Two main drawbacks of replication are It require more storage capacity Synchronization requirement need to be met when directories are updated as the directories at each location would need an updated copy Directories can be portioned to overcome the drawback Naming method should be capable of locating an object irrespective of its logical name Dr.Rahila Sheikh

16. Scalability As number of user increase and the system gets larger , the number of location queries will increase and the overhead will grow larger as well hurting the performance of every computer Compatibility It refers to the notion of interoperability. Three levels of compatibility Binary level All the processor execute the same binary instruction set even though the processor may differ in performance and I/O Execution level same source code can be complied and executed properly on any computer in the system Protocol level Least restrictive form of compatibility All system component support a common set of protocols Dr.Rahila Sheikh

17. Process synchronization Difficult because of unavailability of shared memory Problem occurs when processes concurrently try to access shared resources Mutual Exclusion can be used to solve the problem Resource sharing also leads to problem of deadlock Resource Management Both local and remote resources should be available to user in effective manner Data Migration Computation Migration Distributed scheduling Dr.Rahila Sheikh

18. Security Two issues for design of security are Authentication Authorization Structuring Monolithic Kernel The collective Kernel Structure Object Oriented Operating System Client-Server Computing Model Processes are categorized as server and clients Servers are the process that provide services Clients are the process that need services Dr.Rahila Sheikh

19. Communication Networks • WAN • Packet Switching Vs Circuit Switching • The ISO OSI Reference Model • LAN • Communication Primitives • The Message Passing Model • Blocking Vs Non-Blocking Primitives • Synchronous Vs Asynchronous Primitives • Remote Procedure Calls Dr.Rahila Sheikh

20. Message passing § Communication primitives • send(destination-process, message) • receive(source-process, message) § blocking vs. non-blocking primitives • a message is copied at least three times: sender (user buffer -1-> kernel buffer) -2->receiver(kernel buffer -3-> user buffer) • non-blocking - faster, harder to code, riskier, requires additional OS support send - return as soon as message copied to kernel buffer receive - provide a (user) buffer for message to be copied to and return • blocking - safer, easier to think about, slower unreliable - block until message is sent/received reliable - receipt is confirmed by acknowledgement, block until ack is sent/received Dr.Rahila Sheikh

21. Message passing (cont.) § synchronous vs. asynchronous primitives • synchronous (also called randezvous) – send blocks until receive executes on receiving computer - safer, easier, less concurrent • asynchronous -multiple sends can be executed before receives (messages buffered) - more dangerous (what to do with messages to crashed receiver?), complex concurrent Dr.Rahila Sheikh

22. Why is message-passing not ideal? § Disadvantages of client-server communication via message passing: • Message passing is I/O oriented, rather than request/result oriented • Programmer has to explicitly code all synchronization • Programmer may have to code format conversion, flow control, and error control § Goal — heterogeneity — support different machines, different OSs • Portability — applications should be trivially portable to machines of other vendors • Interoperability — clients will always get same service, regardless of how vendor has implemented that service • OS should handle data conversion between different types Dr.Rahila Sheikh

23. Remote Procedure Call (RPC) § RPC mechanism: • Hides message-passing I/O from the programmer • Looks (almost) like a procedure call — but client invokes a procedure on a server § RPC invocation (high-level view): • Calling process (client) is suspended • Parameters of procedure are passed across network to called process (server) • Server executes procedure • Return parameters are sent back across network • Calling process resumes § Invented by Birrell & Nelson at Xerox PARC, described in February 1984 ACM Transactions on Computer Systems Dr.Rahila Sheikh

24. Each RPC invocation by a client process calls a client stub, which builds a message and sends it to a server stub § The server stub uses the message to generate a local procedure call to the server § If the local procedure call returns a value, the server stub builds a message and sends it to the client stub, which receives it and returns the result(s) to the client Dr.Rahila Sheikh

25. RPC Invocation (more detailed) 1. Client app. procedure calls the client stub 2. Client stub packs parameters into message and traps to the kernel 3. Kernel sends message(s) to remote kernel 4. Remote kernel passes message(s) to server stub 5. Server stub unpacks parameters and calls server app. procedure 6. Server app. executes procedure and returns results to server stub 7. Server stub packs result(s) in message(s) and traps to kernel 8. Remote kernel sends message(s) to local kernel 9. Local kernel passes message(s) to client stub 10. Client stub unpacks result(s) and returns them to client app. Dr.Rahila Sheikh

26. Binding § Binding = determining the server and remote procedure to call § Static binding — addresses of servers are hardwired (e.g., Ethernet number) • Inflexible if a server changes location • Poor if there are multiple copies of a server § Dynamic binding —dynamically assign server names • Broadcast a “where is the server?” message, wait for response from server • Use a binding server (binder) o Servers register / deregister their services with the binding server o When a client calls a remote procedure for the first time, it queries the binding server for a registered server to call Dr.Rahila Sheikh

27. Dr.Rahila Sheikh

28. Parameter passing (cont.) § Handle different internal representations • ASCII vs. EBCDIC vs. … • 1’s comp. vs. 2’s comp. vs. floating-point • Little endian vs. big endian • Establish a canonical (standard) form? § What types of passing are supported? • Remote procedure can’t access global variables must pass all necessary data • Call-by-value (procedure gets a copy of data) — pass parameters in message • Call-by-reference (procedure gets a pointer to data) Can’t do call-by-reference Do call-by-copy / restore instead – Instead of pointer, pass item pointed to – Procedure modifies it, then pass it back Inconsistency if client doesn’t block Dr.Rahila Sheikh

29. Generating stubs § C and C++ may not be descriptive enough to allow stubs to be generated automatically • Which are in, in-out, and out parameters? • Exactly what size are parameters (e.g., integers,arrays)? • What does it mean to pass a pointer? § Using OSF’s DCE Interface Definition Language (IDL) to specify procedure signatures for stub generation: typedefstruct { double item1; int item2; char *annotation; } tuple; char add(int key, tuple value); char remove(int key, tuple value); int query(int key, int number, tuple values[ ]); inerface db { typedefstruct { double item1; long item2; [string, ptr] ISO_LATIN_1 *annotation; } tuple; boolean add ( [in] long key, [in] tuple value ); boolean remove ( [in] long key, [in] tuple value ); long query ( [in] long key, [in] long number, [out, size_is(number)] tuple values[ ] Dr.Rahila Sheikh

30. Error handling, semantics § RPC call may fail due to computer or communications failure § what to do if RPC call fails? § three execution semantics • “at least once” if call succeeds – at least one execution of remote procedure happened if fails – none, partial, multiple executions • “exactly once” if succeeds – exactly once if fails – none, partial, one • “at most once”- if succeeds – exactly once if fails - none Dr.Rahila Sheikh

31. Stateful vs. stateless server § Stateful server — server maintains state information for each client for each file • Connection-oriented (open file, read / write file, close file) • Enables server optimizations like read-ahead (prefetching) and file locking • Difficult to recover state after a crash § Stateless server —server does not maintain state information for each client • Each request is self-contained (file, position, access) o Connectionless (open and close are implied) • If server crashes, client can simply keep retransmitting requests until it recovers • No server optimizations like above • File operations must be idempotent Dr.Rahila Sheikh

32. Dr.Rahila Sheikh

33. Dr.Rahila Sheikh

34. Dr.Rahila Sheikh

35. Dr.Rahila Sheikh

36. Dr.Rahila Sheikh

37. Dr.Rahila Sheikh

38. Dr.Rahila Sheikh

39. Direct vs. indirect communication § Direct communication — explicitly name the process you’re communicating with send(destination-process, message) receive(source-process, message) • Link is associated with exactly two processes Between any two processes, there exists at most one link The link may be unidirectional, but is usually bidirectional § Indirect communication — communicate using mailboxes (ports) (usually) owned by receiver send(mailbox, message) receive(mailbox, message) • Link is associated with two or more processes that share a Mailbox Between any two processes, there may be a number of links The link may be either unidirectional or bidirectional Dr.Rahila Sheikh

40. DISTOSA Distributed OS for a network of 68000s.DISTRIXMessage-based distributed version of Unix. Early 1980s.DUNIXA distributed version of UNIX developed at Bell Labs. late 1980s [xxx 1988].EdenA distributed object-oriented OS at the U. of Washington, based on an integrated distributed network of bit-mapped workstations. Capability-based. Early 1980s [Almes et al 1985].GalaxyA distributed UNIX-compatible system featuring multi-level IPC and variable-weight processes. Univ. of Tokyo, late 1980s [Sinha et al 1991].LOCUSDistributed OS based on UNIX. Mid 1980s. [Popek & Walker, 1985].MDXMICROSDistributed OS for MICRONET, a reconfigurable network computer. Late 1970s [Wittie & van Tilborg 1980].MOSAn early version of MOSIX. Controls four linked PDP-11s. Mid 1980s [Barak & Litman 1985].MOSIXA distributed version of UNIX supporting full transparency and dynamic process migration for load balancing. Developed at the Hebrew U. of Jersusalem. Mid 1980's to 1990's [Barak et al 1993].NewarkEarly version of Eden developed for the VAX environment. The name was chosen because it was "far from Eden."NSMOSA version of MOSIX for National Semiconductor VR32 systems. late 1980's [Barel 1987].Plan9Distributed UNIX-like system developed at Bell Labs by the originators of UNIX. Features per-process name-spaces, allowing each process a customized view of the resources in the system. 1990s [Pike et al 1995].REPOSOperating System for small PDP-11's attached to a host computer. Late 1970s [Maegaard & Andreasan 1979].RIGRochester Intelligent Gateway. Network OS developed at the University of Rochester. Influenced Accent and Mach. Early 1970s [Ball et al 1976]. Dr.Rahila Sheikh

41. RoscoeDistributed OS for multiple identical processors (LSI-11s). University of Wisconsin, Late 1970s [Solomon & Finkel 1979].SaguaroDistributed OS at the U. of Arizona, supporting varying degrees of transparency. Mid 1980s [Andrews et al 1987].SODAA Simplified OS for Distributed Applications. Mid 1980s [Kepecs & Solomon 1985].SODS/OSOS for a Distributed System developed on the IBM Series/1 at the U. of Delaware. Late 1970s [Sincoskie & Farber 1980].SpringDistributed multiplatform OS developed by Sun. Not related to the Spring Kernel, a real-time system. 1990s [Mitchell et al 1994].UniflexMultitasking, multiprocessing OS for the 68000 family. Technical Systems Consultants. Early 1980s [Mini-Micro 1986].VExperimental Distributed OS linking powerful bit-mapped workstations at Stanford U. Early 1980s [Cheriton 1984, Berglund 1986]. Dr.Rahila Sheikh