Unit 2(oss) (1)
Download as PPT, PDF3 likes724 views
The document discusses operating system support for middleware, including how middleware relies on operating system functions for processes, threads, communication, and memory management. It also examines different operating system architectures like monolithic kernels and microkernels, and how microkernels implement operating system services through dynamically loaded servers to improve extensibility and modularity. Finally, it analyzes how middleware and operating systems work together to provide distributed services through functions like remote procedure calls while managing performance, security, and other issues.
Unit 2(oss) (1)
- 1. • Introduction • The operating system layer • Protection • Communication and invocation • Operating system architecture Operating System Support
- 2. Middleware and the Operating System What is a distributed OS? • Presents users (and applications) with an integrated computing platform that hides the individual computers. • Has control over all of the nodes (computers) in the network and allocates their resources to tasks without user involvement. • In a distributed OS, the user doesn't know (or care) where his programs are running. • Examples: • Cluster computer systems • V system, Sprite
- 3. • No distributed OS in general use – Users have much invested in their application software – Users tend to prefer to have a degree of autonomy for their machines • Network OS provides autonomy • Middleware provides network-transparent access resource Combination of middleware and network OS
- 4. • Introduction • The operating system layer • Protection • Communication and invocation • Operating system architecture Operating System Support
- 5. • Operating System – Tasks: processing, storage and communication – Components: kernel, library, user-level services • Middleware – runs on a variety of OS-hardware combinations – remote invocations • Architecture The relationship between OS and Middleware
- 6. System layers Applications, services Computer & Platf orm Middleware OS: kernel, libraries & servers network hardware OS1 Computer & network hardware Node 1 Node 2 Processes, threads, communication, ... OS2 Processes, threads, communication, ... Figure 2.1 Software and hardware service layers in distributed systems Applications, serv ices Computer and network hardware Platf orm Operating system Middleware
- 7. • Encapsulation – provide a set of operations that meet their clients’ needs • Protection – protect resource from illegitimate access • Concurrent processing – support clients access resource concurrently • Invocation mechanism: a means of accessing an encapsulated resource – Communication • Pass operation parameters and results between resource managers – Scheduling • Schedule the processing of the invoked operation Functions that OS should provide for middleware
- 8. • Process manager – Handles the creation of and operations upon processes. • Thread manager – Thread creation, synchronization and scheduling • Communication manager – Communication between threads attached to different processes on the same computer • Memory manager – Management of physical and virtual memory • Supervisor – Dispatching of interrupts, system call traps and other exceptions – control of memory management unit and hardware caches – processor and floating point unit register manipulations The core OS components
- 9. Positioning Middleware • Network OS’s are not transparent. • Distributed OS’s are not independent of computers. • Middleware can help.
- 10. Middleware • What is middleware? • What is its function? • Where is it located? • Why does it exist?
- 11. Positioning Middleware • General structure of a distributed system as middleware.
- 12. Software and hardware service layers in distributed systems Applications, serv ices Computer and network hardware Platf orm Operating system Middleware
- 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. • Why should they be open? Why should they not be open? 1.23
- 14. Typical Middleware Services • Communication • Naming • Persistence • Distributed transactions • Security
- 15. Middleware Models • Distributed files – Examples? • Remote procedure call – Examples? • Distributed objects – Examples? • Distributed documents – Examples? • Others? – Message-oriented middleware (MOM) – Service oriented architecture (SOA) – Document-oriented
- 16. Middleware and the Operating System • Middleware implements abstractions that support network- wide programming. Examples: • RPC and RMI (Sun RPC, Corba, Java RMI) • event distribution and filtering (Corba Event Notification, Elvin) • resource discovery for mobile and ubiquitous computing • support for multimedia streaming • Traditional OS's (e.g. early Unix, Windows 3.0) – simplify, protect and optimize the use of local resources • Network OS's (e.g. Mach, modern UNIX, Windows NT) – do the same but they also support a wide range of communication standards and enable remote processes to access (some) local resources (e.g. files).
- 17. DOS vs. NOS vs. Middleware Discussion • What is good/bad about DOS? – Transparency – Other issues have reduced success. – Problems are often socio-technological. • What is good/bad about NOS? – Simple. – Decoupled, easy to add/remove. – Lack of transparency. • What is good/bad about middleware? – Easy to make multiplatform. – Easy to start something new. • But this can also be bad.
- 18. Types of Distributed OSs System Description Main Goal DOS Tightly-coupled operating system for multi- processors and homogeneous multicomputers Hide and manage hardware resources NOS Loosely-coupled operating system for heterogeneous multicomputers (LAN and WAN) Offer local services to remote clients Middleware Additional layer atop of NOS implementing general-purpose services Provide distribution transparency
- 19. • Introduction • The operating system layer • Protection • Communication and invocation • Operating system architecture Operating System Support
- 20. • Maliciously contrived code • Benign code – contains a bug – have unanticipated behavior • Example: read and write in File System – Illegal user vs. access right control – Access the file pointer variable directly (setFilePointerRandomly) vs. type-safe language • Type–safe language, e.g. Java or Modula-3 • Non-type-safe language, e.g. C or C++ Illegitimate access
- 21. • Kernel – always runs – complete access privileges for the physical resources • Different execution mode – An address space: a collection of ranges of virtual memory locations, in each of which a specified combination of memory access rights applies, e.g.: read only or read-write – supervisor mode (kernel process) / user mode (user process) – Interface between kernel and user processes: system call trap • The price for protection – switching between different processes take many processor cycles – a system call trap is a more expensive operation than a simple method call Kernel and Protection
- 22. The System Clock system clock frequency clock period(One full period is also called a clock cycle ) "Hertz" (Hz) meaning one cycle per second 10 MHz : 100 nanoseconds 1GHz: 1 nanoseconds
- 23. • Introduction • The operating system layer • Protection • Communication and invocation • Operating system architecture Operating System Support
- 24. • Communication primitives – TCP(UDP) Socket in Unix and Windows – DoOperation, getRequest, sendReply in Amoeba – Group communication primitives in V system • Protocols and openness – provide standard protocols that enable internetworking between middleware – integrate novel low-level protocols without upgrading their application – Static stack • new layer to be integrated permanently as a “driver” – Dynamic stack • protocol stack be composed on the fly • E.g. web browser utilize wide-area wireless link on the road and faster Ethernet connection in the office Communication primitives & protocols
- 25. • Invocation costs – Different invocations – The factors that matter • synchronous/asynchronous, domain transition, communication across a network, thread scheduling and switching • Invocation over the network – Delay: the total RPC call time experienced by a client – Latency: the fixed overhead of an RPC, measured by null RPC – Throughput: the rate of data transfer between computers in a single RPC – An example • Threshold: one extra packet to be sent, might be an extra acknowledge packet is needed Invocation performance
- 26. • The performance of RPC and RMI mechanisms is critical for effective distributed systems. – Typical times for 'null procedure call': – Local procedure call < 1 microseconds – Remote procedure call ~ 10 milliseconds – 'network time' (involving about 100 bytes transferred, at 100 megabits/sec.) accounts for only .01 millisecond; the remaining delays must be in OS and middleware - latency, not communication time. • Factors affecting RPC/RMI performance – marshalling/unmarshalling + operation despatch at the server – data copying:- application -> kernel space -> communication buffers – thread scheduling and context switching:- including kernel entry – protocol processing:- for each protocol layer – network access delays:- connection setup, network latency 10,000 times slower! Support for communication and invocation
- 27. Invocations between address spaces Control transfer via trap instruction User Kernel Thread User 1 User 2 Control transfer via privileged instructions Thread 1 Thread 2 Protection domain boundary (a) System call (b) R PC/RMI (within one computer) Kernel (c) RPC/RMI (between computers) User 1 User 2 Thread 1 Network Thread 2 Kernel 2Kernel 1
- 28. Delay of an RPC operation when returned data size varies 1000 2000 RPC delay Requested data size (bytes) Packet size 0
- 29. A lightweight remote procedure call 1. Copy args 2. Trap to Kernel 4. Execute procedure and copy results Client User stub Serv er Kernel stub 3. Upcall 5. Return (trap) A A stack
- 30. Times for serialized and concurrent invocations Client Serv er execute request Send Receiv e unmarshal marshal Receiv e unmarshal process results marshal Send process args marshal Send process args transmission Receiv e unmarshal process results execute request Send Receiv e unmarshal marshal marshal Send process args marshal Send process args execute request Send Receiv e unmarshal marshal execute request Send Receiv e unmarshal marshal Receiv e unmarshal process results Receiv e unmarshal process results tim e Client Serv er Serialised inv ocations Concurrent inv ocations
- 31. • Memory sharing – rapid communication between processes in the same computer • Choice of protocol – TCP/UDP • E.g. Persistent connections: several invocations during one – OS’s buffer collect several small messages and send them together • Invocation within a computer – Most cross-address-space invocation take place within a computer – LRPC (lightweight RPC) Improve the performance of RPC
- 32. • Performance characteristics of the Internet – High latencies, low bandwidths and high server loads – Network disconnection and reconnection. – outweigh any benefits that the OS can provide • Asynchronous operation – Concurrent invocations • E.g., the browser fetches multiple images in a home page by concurrent GET requests – Asynchronous invocation: non-blocking call • E.g., CORBA oneway invocation: maybe semantics, or collect result by a separate call Asynchronous operation
- 33. • Persistent asynchronous invocations – Designed for disconnected operation – Try indefinitely to perform the invocation, until it is known to have succeeded or failed, or until the application cancels the invocation – QRPC (Queued RPC) • Client queues outgoing invocation requests in a stable log • Server queues invocation results • The issues to programmers – How user can continue while the results of invocations are still not known? Asynchronous operation … continued
- 34. • Introduction • The operating system layer • Protection • Communication and invocation • Operating system architecture Operating System Support
- 35. • Monolithic kernel – Kernel is massive: perform all basic operating system functions, megabytes of code and data – Kernel is undifferentiated: coded in a non-modular way – E.g. Unix – Pros: efficiency – Cons: lack of structure • Microkernel – Kernel provides only the most basic abstractions: address spaces, threads and local interprocess communication – All other system services are provided by servers that are dynamically loaded – E.g., VM of IBM 370 – Pros: extensibility, modularity, free of bugs – Cons: relatively inefficiency • Hybrid approaches Monolithic kernels and microkernels
- 36. Monolithic kernel and Microkernel Monolithic Kernel Microkernel Serv er: Dy namically loaded server program:Kernel code and data: ....... ....... Key: S4 S1 ....... S1 S2 S3 S2 S3 S4 Middleware Language support subsystem Language support subsystem OS emulation subsystem .... Microkernel Hardware The microkernel supports middleware via subsystems
- 37. Core OS functionality Communication manager Thread m anager Memory manager Superv isor Process manager