1. Processes Chapter 3

2. Processes Process: Program in execution. In DSs, more concepts come into consideration, eg. Multi-treading, process migration, code migration, Threads: finer granular than processes, multiple thread of control in a single process. Agents at the end of this chapter.

3. Threads Process :: Virtual processor Process table, used to manage virtual processors. Separation of processes domain in order to prevent intervention! Concurrency transparency exists, but expensive! Threads are similar to processes, but no attempt to provide such level of concurrency transparency  gaining performance. Thread context consists of nothing except CPU switch + little tasks.

4. Threads-2 Blocking of the whole process when a block system call is executed; while we need to continue other aspects of the task. Examples: An spreadsheet with two tasks, data input and broadcasting of changes. Utilizing the processing power of more than one CPU in a program. RPC with single-tread processes.

5. Thread Usage in Nondistributed Systems Context switching as the result of IPC

6. Threads-4 Thread switching can be done in the user area, thus no context switch! Threads are implemented in the form of a tread package. Operatins include create, destroy + operations for synchronization Two approaches –Thread library and entirely in the user mode Cheap   Blocking of the process will block all! –Support of kernel to be aware and to schedule them Expensive  no benefit of using threads!!

7. Thread Implementation Combining kernel-level lightweight processes and user-level threads. Several LWP in the context of a single process. Multithread application is constructed by creating threads, and assign each tread to a LWP Each LWP finds a running thread and Context switch of LWPs are done in the user space

8. Multithreaded Clients & Servers Browsing a web page containing several links Paralled downloading of pages through multithreading to replicas of a web-server, when thr server is the bottleneck. Main usage in DSs is for serevrs, for parallelism and higher performance.

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

10. Multithreaded Servers (2) Three ways to construct a server. ModelCharacteristics ThreadsParallelism, blocking system calls Single-threaded processNo parallelism, blocking system calls Finite-state machine Parallelism, nonblocking system calls Using msgs.

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

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

13. Servers Iterative Servers Concurrent Servers, through threads or even forking new processes. Next slide …. Staeless Server: does not keep info on the state of its clients; can change its own state regardless of the clients:: Web Server Statefull Server: File Server Object Server: A server to support distributed objects.

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

15. Object Adapter (1) Alternatives for Invoking Objects –Only one way to invoke …Inflexible –Diffeerent policies Making a transient object at the first invocation Each object is located in a memory segment of its own. Activation Policy: How to invoke an object? Organization of an object server supporting different activation policies. Object Adapter : Group objects per policy

16. Object Adapter (2) 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 */

17. Object Adapter (3) 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. */

18. Object Adapter (4) The main part of an adapter that implements a thread-per-object policy.

19. Code Migration Till now, passing data as parameters to a remote process/thread/object. Sometimes, it is needed to pass a program, EVEN while it is being run. Code migration in –Homogeneous systems –Heterogeneous systems Security issues are discussed in section 8.

20. Motivation Getting performance through migrating processes from heavily-loaded machines to lightly-loaded ones Load distribution is a very important player! Optimizing computing capacity is less an issue than minimizing communication! Scenario: A process handling a large quantity of data in a client-server architecture. Which part should be migrated? Data-Centric or UI centric? Flexibility is another motivation.

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

22. Models for Code Migration Alternatives for code migration. Assuming a process has 3 segments: code, resource, execution

23. Mobility Weak: transfer code + initialization data. Program always starts from ZERO  simple; target machine should be able to execute the code:: Java Applet Strong: the execution segment can also be transferred  The running process should be suspended, transferred, and resumed:: D’Agents Initiator: Sender ( sending to a compute server, or a query to the search engine :: server should know all its clients ) or Receiver ( Java Applet; can be done anonymously )

24. Migration and Local Resources Resource segment cannot be transferred simply! Example: binding to a TCP port! Reference to a file. 3 types of process-to-resource bindings: –by identifier  process requires the referenced resource, nothing else (a URL) –by value  another resource can be used, e.g. general libraries in C or Java. –By type  references to monitor, printer,.. Unattached resources, Fastened resources (local DBSs ), and Fixed resources (bound to local resources)

25. 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 resource; RB: Rebind process to locally available resource 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

26. Migration in Heterogeneous Systems Till now, it is assumed that the code can be run there In the case of weak mobility, new compilation! In the case of strong mobility, migration of the execution segment.  at least we need the same H/W architecture and the same OS. Execution segment includes: data ( private to the process ), current stack ( temp data, platform-dependent register values! ) & PC. A solution for procedural languages in the next slide: Restricting the migration on calling a subroutine

27. Migration in Heterogeneous Systems The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment 3-15

28. D'Agents An agent in D’Agents is a program that can migrate. Programs can be written in any language that can be run in the target machine (Tcl, Java, Scheme) Mobility –Sender-initiated weak, separate process, through agent_submit command Next slide –Process migration strong, through agent_jump command, the caller process is suspended; all segments (code, resource, execution) are marshaled and sent for the destination. A new process is initiated and resume execution after the agent_jum p call. Now the suspended process exit. –Cloning strong

29. Overview of Code Migration in D'Agents (1) A simple example of a Tcl agent in D'Agents submitting a script to a remote machine (adapted from [gray.r95]) 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)

30. Overview of Code Migration in D'Agents (2) An example of a Tcl agent in D'Agents migrating to different machines where it executes the UNIX who command (adapted from [gray.r95]) 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)

31. Implementation Issues (1) The architecture of the D'Agents system. Messaging Agent Mngmnt, Authentication, Inter-agent Communication Language independent core Start and end an agent, Various migration operations

32. Implementation Issues (2) The parts comprising the state of an agent in D'Agents. 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

33. Software Agents Independent views of execution are concluded in Software Agents. Autonomous units capable of performing a task in collaboration with other, possibly remote agents. Collaborative agents: autonomy and cooperation. Mobile agents: Ability to move between different machines. Interface agent: assist end-user in the use of one or more applications. Information agent: manage information from different sources

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

35. Agent Technology The general model of an agent platform (adapted from [FIPA 98-mgt]). ACC: Agent Communication Channel, which provides the abstraction of a reliable/ordered/…. channel.

36. Agent Communication Languages (0) Communication between agents in the application level. A strict separation between the purpose of a message & its content. Purposes of the message in the next slide (FIPA).

37. Agent Communication Languages (1) 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 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)