1. 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. 2 Process Communication Context switching as the result of IPC Usual Mechanisms are: Pipes Message Queues Shared Segments What do they all have in common??

3. 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. 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. 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. 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. 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. 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. 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. 10 Thread Implementation Combining kernel-level lightweight processes and user-level threads.

11. 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. 12 Multithreaded Servers A multithreaded server organized in a dispatcher/worker model. Threads are extremely useful when one writes server code

13. 13 Multithreaded Servers Three ways to construct a server. ModelCharacteristics ThreadsParallelism, blocking system calls Single-threaded processNo parallelism, blocking system calls Finite-state machineParallelism, nonblocking system calls 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

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

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

16. 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. 17 Servers Design Issues a)Client-to-server binding using a daemon as in DCE b)Client-to-server binding using a superserver as in UNIX

18. 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. 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. 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. 21 Object Adapter Organization of an object server supporting different activation policies. 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.

22. 22 Object Adapter The header.h file used by the adapter and any program that calls an 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 */

23. 23 Object Adapter The thread.h file used by the adapter for using threads. 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. */

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

25. 25 Why Migrating of 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. Needed often for better Load Sharing and Balancing Move work from lightly to heavily loaded nodes.

26. 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. 27 Models-Alternatives for Code Migration

28. 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 1.By identifier (the strongest) 2.By value (weaker – C library that may be local but in a different location in the target FS). 3.By type (process indicates that it needs –references- specific type of resources such as printers, monitors, etc

29. 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. 30 Migration and Local Resources Actions to be taken with respect to the references to local resources when migrating code to another machine. 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 GR: establish a global systemwide reference MV: move the resource CP: copy the value of the resource RB: rebind process to locally available resource

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

32. 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. 33 Software Agents in Distributed Systems Some important properties by which different types of agents can be distinguished. Property Common to all agents? Description AutonomousYesCan act on its own ReactiveYesResponds timely to changes in its environment ProactiveYesInitiates actions that affects its environment CommunicativeYes Can exchange information with users and other agents ContinuousNoHas a relatively long lifespan MobileNoCan migrate from one site to another AdaptiveNoCapable of learning

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

35. 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. Message purposeDescriptionMessage Content INFORMInform that a given proposition is trueProposition QUERY-IFQuery whether a given proposition is trueProposition QUERY-REFQuery for a give objectExpression CFPAsk for a proposalProposal specifics PROPOSEProvide a proposalProposal ACCEPT-PROPOSALTell that a given proposal is acceptedProposal ID REJECT-PROPOSALTell that a given proposal is rejectedProposal ID REQUESTRequest that an action be performedAction specification SUBSCRIBESubscribe to an information source Reference to source

36. 36 Agent Communication Languages A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information. FieldValue PurposeINFORM Sendermax@http://fanclub-beatrix.royalty-spotters.nl:7239 Receiverelke@iiop://royalty-watcher.uk:5623 LanguageProlog Ontologygenealogy Contentfemale(beatrix),parent(beatrix,juliana,bernhard)