1. Processes Chapter 3

2. Processes  Process is a program in running state  PROCESSES ARE THE BUILDING BLOCKS OF DISTRIBUTED SYSTEMS, ESPECIALLY IN unix TERMINOLOGY  A process is run as if it is executed by an own virtual processor  The sharing of the same CPU or resources such as memory, hard disks, and communication medium is made transparent by the operating system.

3. Implementation of Concurrent Processes Operating system switches from process to process during its execution whenever necessary, according to certain scheduling principle. With single CPU, the concurrency is achieved y overlapping I/O of one or more processes with execution of one. A process context may be swapped between memory and hard disk, if necessary, to be handled at the same time by the same processor and in the same memory.

4. Threads Threads provide a finer degree of concurrency with less transparency… A thread context switching is faster than that of process. With thread switching context is smaller, comprising only CPU state. Data (memory) protection in between the threads is left to the application. Use of threads requires more sophisticated application development, compared to that of process…

5. Context switching as the result of IPC Process A is put on halt, process B executes to receive the IPC

6. Thread Usage in Nondistributed Systems Use of threads can provide dramatic improvement in performance, as part of a program may not have to wait for the other part, thus increasing the concurrency and performance. Threading can be in the context of an application, in OS kernel, or both. Threads are implemented using a special thread library, providing thread creation, destruction, synchronization. Application level threads does not provide efficient concurrency, a blocking system call block the entire application…

7. Thread Usage in Nondistributed Systems A kernel level thread operates like a process, context switching is required, making it as expensive as multiple processes. The best performance can be achieved by user level threads and so called kernel level light weight process-LWP. LWP, once created, runs a scheduling routine to determine one of the user level threads… So context switching is done at user level, with minimum support from the operating system in thread switching

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

9. Thread Usage in Distributed Systems With threads, it is possible to implement concurrent communications. –This is an important requirement for distributed systems This is prerequisite for multithreaded clients and servers. –When one thread block, the other will continue executing.

10. Multithreaded Clients Clients may be programmed to request data from more than one server or clients may need to mix fast and slow operations. For example, a web browser may have to fetch different part of the display from different servers, or some locally some through servers. All such cases can be implemented using multithreads.

11. Multithreaded Clients-Examples X-Window (X) used to control bit mapped terminals, comprising of monitor, keyboard, and mouse, is based on client server paradigm… Clients run X terminal, servers run applications on remote machines… X kernel is part of the OS that controls the terminal… Window manager is designed to manipulate the screen The devices and events are associated to the related window… X allows compound documents (collection of different kinds) to be maintained…

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

13. Client-Side Software for Distribution Transparency A possible approach to transparent replication of a remote object using a client-side solution. Client sees one return value from one of the replicas only Client- proxy

14. Multithreaded Servers Servers are often designed to serve more than one clients concurrently, This can only be achieved either through multiple processes or multiple threads. This is important both for uniprocessor and multiprocessor cases. Multithread solution is cleaner, simpler and faster…

15. Multithreaded Servers-example (1) A multithreaded server organized in a dispatcher/worker model. Clients requests are received at the dispatcher thread and dispatched to worker threads

16. Different Ways of Server Implementation (2) Three ways to construct a server. Threads allow conventional programming mode FSM is hard to program, as the state need to be recorded and remembered to come back to it, as part of the change in the state… ModelCharacteristics Threads Parallelism, blocking system calls do not block the entire system Single-threaded process No parallelism, blocking system calls block the entire system Finite-state machine Parallelism, nonblocking system calls allow send/receive requests to be nonblocking

17. 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 3.7

18. Server Design Issues Iterative sever Concurrent server Super server Stateless server Stateful Server Cookies in web servers Object servers

19. Object Servers An Object server-ObjServ is tailored to serve distributed objects, which has been gaining importance… ObjServ is a place where objects live. An object server may invoke an object using –One thread per object or –One thread per invocation or –Different policies: transient objects (created when needed, aborted when finished ), objects may have a memory partition of their own, code shared, etc.

20. Object Adapter (1): objects are grouped per policy Organization of an object server supporting different activation policies. One ObjAdapter for each policy, eg. Implementation of a specific invocation

21. Object Adapter (2) The header.h file used by the obj 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 */

22. Object Adapter (3) The thread.h file used by the adapter for using threads, assuming that a thread package is available. 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. */

23. Object Adapter (4) The main part of an adapter that implements a thread-per-object policy. Imp of adapter is independent of the object for which it handles invocation. So generic adapter implementation is possible

24. Code Migration Passing programs in global environment rather than passing control… Process migration is one well known migration type, used in UNIX and other operating systems… Reasons for code migration: –Performance, in terms of load balancing – Parallelism –Flexibility, matching the application design –Dynamic configuration

25. Migrating Client 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.

26. Models for Code Migration Alternatives for code migration.

27. Migration and Local Resources Actions to be taken with respect to the references to local resources when migrating code to another machine: GR- Global Ref, MV-Move Resource, CP-Copy Value, RB:Rebind proc to loc avail resource Unattached to machine like local files Fastened to machine, like db Fixed to machine, like comm end points By identifier (strongest binding) By value(weak) By type (weakest) 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) Kinds of Resource-to machine binding Process- to- resource binding

28. Migration in Heterogeneous Systems The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment. Procedure B creates Program stack using migration stack… 3-15

29. Reading material: D’Agent: Tcl-Tool command language script based D’agent is a Tcl script program that can migrate between heterogeneous machines Tcl, like Java is an interpretable language, which makes it easily migratable in heterogeneous environments This migration based mobility is achieved by weak (usually script based) or strong (usually process based) mobility.

30. Example Migratable code in D'Agents: Taking factorial of a number n A simple example of a Tel agent in D'Agents submitting a script to a remote machine (adapted from [gray.1995]) proc factorial n { if ($n  1) { return 1; }# fac(1) = 1 expr $n * [ factorial [expr $n – 1] ] # fac(n) = n * fac(n – 1) } set number … # tells which factorial to compute set machine … # identify the target machine agent_submit $machine –procs factorial –vars number –script {factorial $number } agent_receive …# receive the results (left unspecified for simplicity)

31. Example Migratable code in D'Agents (2):Unix Who command An example of a Tel agent in D'Agents migrating to different machines where it executes the UNIX who command (adapted from [gray.1995]) all_users $machines proc all_users machines { set list ""# Create an initially empty list foreach m $machines {# Consider all hosts in the set of given machines agent_jump $m# Jump to each host set users [exec who]# Execute the who command append list $users# Append the results to the list } return $list# Return the complete list when done } set machines …# Initialize the set of machines to jump to set this_machine# Set to the host that starts the agent # Create a migrating agent by submitting the script to this machine, from where # it will jump to all the others in $machines. agent_submit $this_machine –procs all_users -vars machines -script { all_users $machines } agent_receive …#receive the results (left unspecified for simplicity)

32. Implementation Issues (1) The architecture of the D'Agents system, Server manages the agent each as a separate process; RTS: Run Time System implements the agent (start-end etc,).

33. Implementation Issues (2) The parts comprising the state of a running agent in D'Agents: –In case of migration the content of all the tables and the stacks is marshaled into a stream of bytes and shipped to the target machine, where it unmarshaled into the new state, executed as a new process StatusDescription Global interpreter variablesVariables needed by the interpreter of an agent Global system variablesReturn codes, error codes, error strings, etc. Global program variablesUser-defined global variables in a program Procedure definitionsDefinitions of scripts to be executed by an agent Stack of commandsStack of commands currently being executed Stack of call frames Stack of activation records, one for each running command

34. Software Agents in Distributed Systems Autonomous process capable of inducing changes and reacting to changes in its environment, possible collaborating with other agents. An agent can be mobile as well as stationary. An agent can be adaptive with a certain degree of intelligence. An agent can play a role of an interface or information or security type An agent can be collaborative, mobile, interface, and information type

35. 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

36. Technology to support agent based application development: Agent development platforms The general model of an agent platform (adapted from [FIPA-Foundation for Intelligent Physical Agents-98-mgt]). ACC-Agent Comm Ch

37. Agent Communication Languages as part of Agent Technology 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

38. Agent Communication Languages (2) A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy as an ontology type 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)