1. Processes After today’s lecture, you are asked to know The basic concept of thread and process. What are the advantages of using multi-threaded client and server? How the client deal with access transparency and replication transparency? What is stateless server and what is stateful server? What is iterative and concurrency server? What are the reasons for Migrating Code? Tells the three segments of a process. What are the weak mobility model and strong mobility model?

2. Process A Process is often defined as a program in execution. To execute a program, an operating system creates a number of virtual processors, each one for running a different program. To keep track of these virtual processors, the operating system has a process table, containing entries to store CPU register values, memory maps, open files, accounting information, privileges, etc Processes in a modern OS have: –Management information –Resources –Unique process identifier or PID

3. Process Management information covers –allocated resources –event handling –permissions –scheduling information –utilisation of resources Resources include –memory allocated - address space –open files, I/O channels, devices –secondary storage allocations - swap space, memory mapping Address space is protected so only process may read/write to it. Memory protection stops process –writing to address space of other processes or kernel –crashing OS or other processes if it goes wrong

4. Process For creating a process, the OS must create a complete independent address. The price is high. Even for the switching of the CPU between two processes, because the OS will have to modify registers of the memory management unit (MMU) and invalidate address translation caches such as in the translation lookaside buffer (TLB) Requirements: Changing the memory map in the MMU Flashing the TLB (Translation lookaside buffer)

5. Process Creation in Java Class Run.java uses getRuntime() obtain context for spawning external process exec() get OS command interpreter to run command getInputStream() get input stream to read output from process

6. Thread A thread is very similar to a process in the sense that it can also be seen as the execution of a (part of a) program on a virtual processor. A thread context often consists of nothing more than the CPU context, along with some other information for thread management. Threads are sometimes called lightweight subcomputations running a in a process that –Have their own flow of control and execution state –Share their resource context – address space, open files

7. Thread Compared to processes, threads – are quick to create – are quick to context switch – can readily share memory, files and sockets Threads are useful where – many concurrent computation units are needed – computation units need to share address space easily

8. Thread Usage in Non-distributed Systems For a single-threaded process, whenever a blocking system call is executed, the process as a whole is blocked. Using the multithread process, a program can process more than two tasks at same time, for example the spreadsheet program. Multithreading also makes it possible to exploit parallelism when executing the program on a multiprocessor system. Thread switching can sometimes be done entirely in user space.

9. Java Thread Wire.java creates 2 threads that compete to print their IDs

10. Threads in Distributed Systems Multithreaded Clients Example: Web browser is doing a number of tasks simultaneously. It is designed as a multithreaded client program. Each thread sets up a separate connection to the server and pulls in the data. Advantages: –Hiding communication latencies as much as possible by delivering text contents first, then image and other data. –Several connections can be opened simultaneously. Web server can be replicated across multiple machines with multithreaded client. Connections maybe set up to different replicas, allowing data to be transferred in parallel.

11. Multithreaded Servers (1) A multithreaded server organized in a dispatcher/worker model.

12. Multithreaded Servers (2) Three ways to construct a server. ModelCharacteristics ThreadsParallelism, blocking system calls Single-threaded processNo parallelism, blocking system calls Finite-state machineParallelism, nonblocking system calls

13. Clients (1) 2.1 User Interfaces A major task of most clients is to interact with a human user and a remote server. The X window system is an example of traditional graphical user interface. It is important to realize that user-interface systems such as X essentially provide no more than a graphical interface to applications. The only information that applications can expect from such systems are events identifying basic user actions that are directly related to the devices attached to the terminal. Examples of such events are those regarding keystrokes, mouse position, button operations, etc.

14. The X-Window System The basic organization of the X Window System

15. Clients (2) 2.2 Client-Side Software for Distribution Transparency Besides the user interface and other application-related software, client software comprises components for achieving distribution transparency. Access transparency is generally handled through the generation of a client stub from an interface definition of what the server has to offer. Replication transparency in many distributed systems is handled by means of client-side solution. One way is forward invocation request to each replica and client proxy collects all responses transparently and passes a single return value to the client application.

16. Client-Side Software for Distribution Transparency A possible approach to transparent replication of a remote object using a client-side solution.

17. General Server Design Issues A server is a process implementing a specific service on behalf of a collection of clients. It is organized in this way: it waits for an incoming request from a client and subsequently ensures that the request is taken care of, after which it waits for the next incoming request. Issues: –Iterative server: the server itself handles the request and, if necessary, returns a response to the requesting client. –Concurrent server: it does not handle the request itself, but passes it to a separate thread or another process, after which it immediately waits for the next incoming request. E.g. Multithreaded server, or Unix way: fork a new process for each new incoming request. –Discuss the endpoint (port) and how to manage it. –Whether or not the server is stateless: A stateless server does not keep information on the sate of its clients, and can change its own state without having to inform any client, e.g. A Web Server. A stateful server does maintain information on its clients, e.g. a file server that allows a client to keep a local copy of a file.

18. Servers: General Design Issues a)Client-to-server binding using a daemon as in DCE b)Client-to-server binding using a superserver as in UNIX (e.x. inetd 3.7

19. object server (1) An object server is a server tailored to support distributed objects. Compare with other servers, it does not really provide a specific service. Specific services are implemented by the objects that reside in the server. The server only provides the means to invoke local objects. Alternatives for Invoking Objects For an object to be invoked, the object server needs to know which code to execute, on which data it should operate, whether it should start a separate thread to take care of the invocation, and so on. Approaches: –Assume all objects look alike and that there is only one way to invoke an object. –Support different policies: for transient object A. create it at the first invocation request and destroy it as soon as no client bond to it. B. create all transient object at the time the server is initialized. –A server could follow the policy that each of its objects is place in a memory segment of its own. Other approach is to let the object at least share their code.

20. Object Adapter (2) An Object adapter can be best thought of as software implementing a specific activation policy. The only issue that is important to an object adapter is that it can extract an object reference from an invocation request, and subsequently dispatch the request to the referenced object, but now following a specific activation policy. Rather than passing the request directly to the object, an adapter hands an invocation request to the server-side stub of that object.

21. CODE MIGRATION Reasons for Migrating Code Code migration in distributed systems took place in the form of process migration. That reason has always been performance: –The process should be close to where that data reside. A. Migrating parts of the client to server when doing the database operation. B. Migrating parts of the server to client in interactive database applications. –Code migration can be used to improve performance by exploiting parallelism.

22. Reasons for Migrating Code The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server.

23. Models for Code Migration As in process migration, the execution status of a program, pending signals and other parts of the environment must be moved as well. A process consists of three segments according to Fugetta’s framework: –Code segment is the part that contains the set of instructions that make up the program that is being executed. –Resource segment contains references to external resources needed by the process, such as file, printers, devices, other processes, and so on. –Execution segment is used to store the current execution state of a process, consisting of private data, the stack, and the program counter. Weak mobility model: In this model, it is possible to transfer only the code segment, along with perhaps some initialization data. Feature: a transferred program is always started from its initial state, e.g. Java applets. Strong mobility model: Besides the code segment being transferred, the execution segment can be transferred as well. Feature: A running process can be stopped, subsequently moved to another machine, and then resume execution where it left off.

24. Models for Code Migration Even for the upper two models, further distinction can be made between sender-initiated and receiver-initiated migration. In sender-initiated migration, migration is initiated at the machine where the code currently resides or is being executed. In receiver-initiated migration, the initiative for code migration is taken by the target machine In the case of weak mobility, it also makes a difference if the migrated code is executed by the target process, or whether a separate process is started, e.g. Java applets sere executed in the browser’s address space. For strong mobility model, instead of moving a running process, it can also be supported by remote cloning.

25. Models for Code Migration Alternatives for code migration.

26. Migration and Local Resources Three types of process-to-resource bindings: –Strongest binding – binding by identifier is when a process refers to a resource by its identifier. E.x. when a process uses a URL to refer to a specific Web site by means of that server’s IP address. –Weaker form binding is when only the value of a resource is needed. It is also called binding by value. The execution of the process wouldnot be affected if another resource would provide the same value. E.x. a program relies on standard libraries. –The weakest form of binding is when a process indicates it needs only a resource of a specific type. This binding by type is exemplified by references to local devices, such as monitors, printers, and so on.

27. Migration and Local Resources Actions to be taken with respect to the references to local resources when migrating code to another machine. GR: Establish a global system wide reference. MV: Move the resource. CP: Copy the value of the resource. RB: Rebind process to locally available resource. Three types of resource to machine bindings: –Unattached resources can be easily moved between different machines ( e.x. data) –Fastened resources. Moving or copying may be possible –Fixed resources. Often refer to local devices. UnattachedFastenedFixed By identifier By value By type MV (or GR) CP ( or MV, GR) RB (or GR, CP) GR (or MV) GR (or CP) RB (or GR, CP) GR RB (or GR) Resource-to machine binding Process-to- resource binding