ICS362 Distributed Systems

1. ICS362 Distributed Systems Dr. Ken Cosh Week 3

2. Review • Architectural Styles • Layered Architectures • Object-Based • Data-Centred • Event-Based • System Architectures • Centralised / Decentralised / Hybrid

3. This Week • Processes • Threads • Virtualisation • Clients • Servers • Code Migration

4. What is a Process? • OS • A program in execution • Key Issue • Managing and Scheduling Processes • Both in terms of OS and in terms of Distributed Systems

5. Processes • The OS creates virtual processors • Each for running different programs • OS has a process table • To keep track of the virtual processors • CPU register values, memory maps, open files, privileges, etc. • OS manage these independent processes • One process can not affect another • i.e. concurrency transparency

6. Achieving Concurrency Transparency • Computationally Expensive • Allocation • Create complete independent address space • Initialising memory segments • Potentially moving existing data • Switching • Saving CPU context • Modify Memory Management Unit (MMU) • Potentially swapping processes between main memory and hard disk • If more processes than main memory

7. Threads • Threads are like processes • Executing code independently from other threads • But with no attempt at concurrency transparency • Threads can share the same address space • Computationally less expensive • But programming requires more intellectual effort

8. Multithreading • Consider a spreadsheet program • Editing one cell can cause updates to formulae throughout multiple sheets. • How do we allow user input concurrently with calculations? • And perhaps autosaving

9. Thread Implementation • Normally in the form of a thread package • Containing operations to create and destroy threads & synchronisation variables such as mutexes. • Implementation can be done in different ways • Executed entirely in user mode • Kernel responsible for scheduling • Hybrid

10. User Level thread library • All thread administration is kept in user’s address space; • Cheap to create & destroy threads • Switching between threads is also cheap • However, a blocking system call will block the process – and hence any other threads in the process. • E.g. when waiting for input

11. Kernel level threads • That problem is avoided by implementing threads in the OS kernel. • Then, every thread operation is carried out by the kernel, through system calls • Creation, deletion, synchronisation etc. • Switching threads becomes as expensive as switching processes

12. Hybrid Implementation • Light Weight Processes (LWP) • LWPs run in user space in the context of a single process, but several LWPs can run per process with a shared address space. • Creation, deletion operations etc. run in user space without intervention by the kernel.

13. Threads in DS • A convenient way of allowing blocking system calls without blocking an entire process. • In DS, threads can be separated to different processors (clients or servers)

14. Multithreaded Clients • Example: A Web Browser • Setting up connection • Read incoming data • Pass to display component • Potentially connecting to multiple load balanced replicated servers to transfer data in parallel streams

15. Multithreaded Servers • Suppose a request comes into a single threaded server. • The request needs to be completed before any more requests can come • With multithreads, a dispatcher thread can assign a worker thread to read data from a file system • Normally a blocking operation • Meanwhile the dispatcher thread can deal with more reads, or responses from other worker threads.

16. Multithreaded Servers Worker Thread Dispatcher Thread Operating System Request from network

17. Virtualisation • Of course, we are still referring to a single processor, but giving the illusion of simultaneous execution. • ‘Resource Virtualisation’ • Renewed interest in virtualisation as distributed systems become popular • Extending (or replacing) an existing interface to mimic the behaviour of another system • E.g. to allow software to run on a different platform.

18. Applications of virtualisation • Hardware & Low level systems software evolves quicker than application software. • Virtualisation allows older, more stable, software to run on newer platforms • Networking is pervasive across heterogeneous computers • Virtualisation helps by letting each application run on its own virtual machine.

19. Virtual Machine Implementation • Virtualisation mimics the behaviour of various interfaces: • Interface between Hardware and Software, which can be invoked by any program. • Interface between Hardware and Software, which can be invoked by privileged programs such as the OS. • Interface of system calls offered by an OS • Interface of library calls offered by an API (essentially hiding the OS system calls).

20. Computer Systems Interfaces Application Library Functions Library General Instructions System Calls Operating System Privileged Instructions Hardware

21. Process Virtual Machine Application Runtime System Operating System Hardware Virtualisation is for single processes

22. Virtual Machine Monitor Application Operating System Virtual Machine Monitor Hardware Multiple different Operating Systems running concurrently on the same platform

23. Clients • Provide means for users to interact with remote servers • 1) Fat Client • Application specific protocol • E.g. Agenda application running on a PDA, synchronising with a remote (possibly shared) agenda. • 2) Thin Client • Application neutral protocol • Client is a terminal with no need for local storage • Example – X Window

24. X Window • Oldest, still widely used networked user interface. • The heart is the ‘X-kernel’ OS running on the client • Containing terminal specific device drivers for monitor, keyboard & mouse. • Captures keyboard / mouse events and made available through Xlib library, running elsewhere and communicating through X protocol.

25. X Window System Window Manager Application Xlib Xlib Local OS Local OS X Kernel Device Drivers

26. X Window Manager • Application which dictates the “look and feel” of the display • How to display windows, what buttons etc. • Other applications adhere to these rules. • So.. Confusingly the X Kernel acts as a server where applications play the role of clients!

27. Communication Efficiency • This takes a lot of data communication! • Video stream 30 frames per second • 320x240 screen (PDA) • 24bits per pixel • = 53 Mbps! • Compression techniques are necessary

28. Increasing UI Complexity • Drag & Drop Functionality • Consider a document which contains text & images • Document contains multiple applications • Suppose we want to rotate an image • It needn’t reside on the client, but the client may require more processing power. • Or the Client needs to be fatter

29. Servers • A process implementing a specific service on behalf of a collection of clients • It waits for an incoming request • Then ensures the request is taken care of • Returns to wait for the next request

30. Iterative vs Concurrent • Iterative Server • Handles the request itself and returns response if necessary to the user. • Concurrent Server • Passes the request to a separate thread or another process. • The other process is responsible for responding to the requesting client.

31. Ports • Clients send requests to an endpoint (port) • Servers listen to a particular port • E.g. FTP on TCP port 21, HTTP on TCP port 80 • Or a Daemon can listen to a port and contact the specific server when requests arrive.

32. Stateless Servers • Does not keep information on the state of its clients. • Can change its state without informing clients • Once an HTTP server delivers the files it forgets about the client. • Technically the web server might log all client requests as useful information, but if the information is lost there is no damage to the service.

33. Soft State Servers • Server which promises to maintain state on behalf of the client – for a limited time • E.g. server promises to inform client about updates, but only for a limited time.

34. Stateful Server • Server maintains persistent information on its clients. • E.g. server allows a client to keep a local copy of a file (possibly for updating). Server then maintains a list of client/file entries. • This can improve performance, however if the server crashes it has to restore the list.

35. Session State vs Permanent State • Bear in mind that Permanent State is generally stored in a database, such as customer information, purchases etc. • Maintaining Session State is part of Stateful Server design.

36. Stateful vs Stateless • Should not affect services provided by the server. • If files have to be opened before they can be read from or written to, then either design should mimic this behaviour.

37. Server Clusters • A collection of machines connected through a network, where each machine runs one or more servers. • Logically organised into three tiers (layers) • Switch – through which requests are routed • Application – servers where programs run • File/Database – where the data is stored

38. Server Clusters Database / File Servers Application Servers Logical Switch Client Requests First Tier Second Tier Third Tier

39. Server Clusters • Some systems combine the data and application into a single server resulting in a two tiered system architecture • E.g. Streaming Media

40. Server Clusters • Often Offer Multiple Services, with different machines running different services • Switch needs to be able to distinguish requests and services. • Often caused by limitations on available software & hardware, and different administrators not wanting to interfere with each other. • Leads to some overloaded servers, while others are idle. • Possibility for code migration?

41. Code Migration • So far we have been concerned with passing data. • Sometimes it is useful to pass programs • Even while they are running • Sometimes overall system performance can be improved by moving processes from overloaded machines to lightly loaded machines. • Load in terms of CPU queue length or CPU utilisation

42. Examples • 1) A client application needs to perform many database operations • Why not move the operations closer to the data and then only return the results? • 2) A form needs to be filled in, processed and then translated into a series of database operations • Why not do the form processing on the client?

43. Code Migration • Benefits • Flexibility • Dynamically configured distributed systems • Software need not be pre-installed • Concerns • Security

44. Strong vs Weak Mobility • A process consists of 3 segments • Code Segment – set of instructions • Resource Segment – references to necessary external resources (files, devices, printers etc.) • Execution Segment – current execution state of the process

45. Weak Mobility • The code segment is sent • In this case the code must always begin from a predefined point (perhaps the start) • E.g. Java Applets • Only requires that the target machine is capable of running the code

46. Strong Mobility • The execution segment is transferred as well as the code segment. • Code can be stopped, moved to a new machine, and restarted from where it was. • More general than weak mobility, but harder to implement.

47. The Resource Segment • Consider; you’ve designed your website on localhost, and then upload it to a webserver • Absolute vs Relative URLs? • Changing IP addresses

48. The Resource Segment • Binding by Identifier • A precisely referenced resource, and nothing else! • Binding by Value • It doesn’t matter which resource is used, so long as the correct value is returned. • Does it matter if I use my C++ libraries or yours? • Binding by Type • What type of device are we referring to – a printer? A monitor?

49. Kinds of Resource • Unattached Resources • Easily moved – e.g. data files associated with the program • Fastened Resources • Possible, but relatively high cost – e.g. moving a database – not dependent on current machine, but infeasible to move to a new environment • Fixed Resources • Cannot be moved from environment or machine – e.g. local resources, or a local comunication end point.

50. Solutions? • With 3 kinds of process-to-resource bindings and 3 kinds of resource-to-machine bindings, there are 9 combinations to consider. • And 4 common solutions • Establish a Global System wide reference (GR) • Move the Resource (MV) • Copy the Value of the Resource (CP) • Rebind process to a locally available resource (RB)