Processes and Distributed Computing

1. Processes and Distributed Computing • Issues: • moving processes around • design of server and client processes • migration of processes/programs • agent programs • Processes without Threads are almost useless in • distributed processing

2. Process Communication • Usual Mechanisms are: • Pipes • Message Queues • Shared Segments • What do they all have in common?? • Context switching as the result of IPC

3. Threads as a Core Mechanism • A thread can be seen as a program in execution on a virtual processor • Thread context: CPU status + some more information on (needed for thread management). • For instance a thread may be currently blocked • on a mutex variable and this information can be used so • that it does not get scheduled for execution.

4. Why Threads are Useful in Distributed Systems?? • If a system is implemented as a single-threaded process that blocks on a system call, the whole process gets delayed.. • If a multiprocessor system is available, threads can be executed with different processors (real parallelism). • How are threads implemented?

5. Options for Implementation • Threads are provided in the form of a thread package. • Advantages (of a library implemented entirely in user-space): • Cheap to create/destroy threads • Switching among threads is inexpensive (a few instructions only- no need to change memory maps, deal with CPU, flushing the TLB etc. • Disadvantages (of the user-space library): • Invocation of a blocking system call will block the entire process.. (bad as no other thread can proceed..)

6. Other Options • Kernel-threads… • but this has disadvantages as it essentially suffers from the many possible thread-switch operations (which have the same cost as process context switches). • Approach in between: Lightweight Processes (LWP)

7. Light Weight Processes • A LWP runs in the context of a process • Multiple LWPs may exists per process • A user-thread package available for applications (to create/destroy threads) – implemented entirely on the user-space. • The package provides sync primitives (mutexes/condition variables) • Every LWP can run its own user-thread. • Assigning a thread to a LWP is implicit (hidden from the programmer).

8. LWPs & User Threads • LWP are created by system calls and is given its own stack. • When an LWP is created runs the sched to find a thread to run • If there are more than one LWP, then all of them run the sched. • The thread table is kept in user-space (protection is done by mutexes)-sync does NOT need kernel-support. • When a LWP find a runnable thread context switches to it. • If a thread needs to block on a mutex or cond variable, it does its own administration and then calls the sched. When another runnable thread is found, a context switch is made to that thread.. • End Result: the LWP need not be informed about the last context switch (which happens entirely in user-space).

9. Blocking Threads • When a thread makes a blocking system call: • Change from user-space to kernel • If the current LWP can continue (with another thread it does so) • Otherwise, the OS may decide to run LWP • Ultimately another context switch needs to be made back to kernel. • Similar approach: Scheduler Activations [Anderson 1991] • When a thread block (on a blocking system call) the kernel does a upcall to the thread package and calls the scheduler routine to pick one thread for execution.

10. Thread Implementation • Combining kernel-level lightweight processes and user-level threads.

11. Threads in Distributed Systems • Convenient mechanism to allow blocking calls without blocking entire processes/systems • Mechanism to hide network latencies and delays. • Example: a browser (client) program and the way it retrieves and displays information. • - multiple operations may happen concurrently.

12. Multithreaded Servers Threads are extremely useful when one writes server code • A multithreaded server organized in a dispatcher/worker model.

13. Multithreaded Servers • In Finite-state machine model, the only process in the server • services requests but also marks the state of each process. • Finite-State machine model: complicated to program • Three ways to construct a server.

14. Client Organization:X-Window System Example • It does provide functionality transparency for the Interface • The basic organization of the X Window System

15. Client-Side Organization for Data Distribution Transparency Failure transparency(at the client site)?? If a client cannot connect to a server after a number of attempts, it does try another one.. • A possible approach to transparent replication of a • remote object using a client-side solution.

16. Design Issues for Servers • Iterative server • The server itself handles the request and if possible returns a result • Concurrent server • The server passes the request to a different server (thread) • After that it waits for the next incoming request… • Endpoints/Ports: • How do clients know about them?? • Some are standard ie, ftp is at 21, http at 80 etc. • Some services do not require pre-assigned endpoint. • One solution is DCE style • Another use a superserver (ala Unix) – forks a new process to handle incoming requests (via the inetd)

17. Servers Design Issues • Client-to-server binding using a daemon as in DCE • Client-to-server binding using a superserver as in UNIX

18. Server Design Issues • How to interrupt a server? • Exit the application • Send out-of-band data (separate data and control streams) • Stateless servers • Does not keep any information about the state of clients • Stateful servers • A file server that allows a client to keep a local copy of a file and the client does updates on the file. • Plus: can improve performance (as far as the client is concerned) • Minus: in light of a crash the server have to re-acquire the “state-of-affairs” just before the crash… • Cookies • Why are they used? What is good/bad about them?

19. Object Servers • Developed to support distributed objects • An object server does not provide a specific service • Services are implemented by various objects resident in the server (or various servers). • Object • Data representing its state • Code (with the implementation of the methods). • Issue: how does a server invoke its objects? • In a multi-threaded server, each object may be assigned a thread. • Alternatively, a thread can be used for each invocation request.

20. (Activation) Policies for Invoking Objects • Policy I: An object is generated the first time it is invoked and if it is transient it has to go when no client binds to it.. • Policy II: An object is always alive waiting to be contacted. • Policy III: An object is generated for the first time it is invoked and remains alive until Greece becomes a rational place.

21. Object Adapter • Decisions on how to invoke an object are known as activation policies • Mechanism that groups objects together per activation policy is called • object adaptor/object wrapper. • Adaptors are unaware of the specific interfaces of the objects they control. • Organization of an object server supporting different activation policies.

22. Object Adapter /* Definitions needed by caller of adapter and adapter */#define TRUE#define MAX_DATA 65536 /* Definition of general message format */struct message { long source /* senders identity */ long object_id; /* identifier for the requested object */ long method_id; /* identifier for the requested method */ unsigned size; /* total bytes in list of parameters */ char **data; /* parameters as sequence of bytes */}; /* General definition of operation to be called at skeleton of object */typedef void (*METHOD_CALL)(unsigned, char* unsigned*, char**); long register_object (METHOD_CALL call); /* register an object */void unrigester_object (long object)id); /* unrigester an object */void invoke_adapter (message *request); /* call the adapter */ • The header.h file used by the adapter and any program that calls an adapter.

23. Object Adapter typedef struct thread THREAD; /* hidden definition of a thread */ thread *CREATE_THREAD (void (*body)(long tid), long thread_id);/* Create a thread by giving a pointer to a function that defines the actual *//* behavior of the thread, along with a thread identifier */ void get_msg (unsigned *size, char **data);void put_msg(THREAD *receiver, unsigned size, char **data);/* Calling get_msg blocks the thread until of a message has been put into its *//* associated buffer. Putting a message in a thread's buffer is a nonblocking *//* operation. */ • The thread.h file used by the adapter for using threads.

24. Object Adapter • The main part of an adapter that implements a thread-per-object policy.

25. Why Migrating of Code? • Needed often for better Load Sharing and Balancing • Move work from lightly to heavily loaded nodes. • The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server.

26. Types of Mobility • Processes consist of [Fugetta 98] • Code segment (set of instructions that make up the program) • Resource segment (references to external resources) • Execution segment(stores the current execution state) • Weak mobility: transfer only the code section (Java applets). • Strong mobility:transfer the execution section as well (D’Agents).

27. Models-Alternatives for Code Migration

28. Migration and Local Resources • Transferring a resource is sometimes exceedingly difficult (if not impossible) • Move a process that holds a specific TCP port.. • Move a process that accesses a file via a URL. • [Fugetta 98] classifies process-to- resource bindings • By identifier (the strongest) • By value (weaker – C library that may be local but in a different location in the target FS). • By type (process indicates that it needs –references- specific type of resources such as printers, monitors, etc

29. Local Resources • If and how a reference should be changed depends on whether that resource can be moved along to the target machine. • Resource-to-machine bindings • Unattached resources (ie, data files – can be easily moved around) • Fastened Resources(may be moved but expensive – ie, databases, web sites etc) • Fixed Resources (specific site resources such as local communication endpoints).

30. Migration and Local Resources Resource-to machine binding Process-to-resource binding GR: establish a global systemwide reference MV: move the resource CP: copy the value of the resource RB: rebind process to locally available resource • Actions to be taken with respect to the references to local resources when migrating code to another machine.

31. Migration in Heterogeneous Systems Weak mobility possible only when a program migrates between Procedure calls (use idea of migration stack-machine independent) 3-15 • The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment

32. Agents.. • Agent is an autonomous process that can react to, and/or initiate changes in its environment (possibly with the collaboration of other processes and/or users).

33. Software Agents in Distributed Systems • Some important properties by which different types of agents can be distinguished.

34. Agent Technology • The general model of an agent platform (adapted from [fipa98-mgt]).

35. Agent Communication Languages • Examples of different message types in the FIPA ACL [fipa98-acl], giving the purpose of a message, along with the description of the actual message content.

36. Agent Communication Languages • A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information.