Processes Processes and threads Process forms a building
Processes
Processes and threads • Process forms a building block in distributed systems • Processes granularity is not sufficient for distributed systems • Multiple threads make easier to build distributed applications
Thread Usage in Nondistributed Systems large applications : many cooperating programs (processes) via Inter-Process Communication mechanisms (Unix) Ch an ge st o M M U, T LB … Ch ang es to MM U, TL B… IPC needs extensive context switching process B Instead of processes : threads
Thread Implementation user level library: switching in a few instructions, no change in memory maps etc. but a blocking system call blocks the entire process O. S. kernel level : no problem with blocking system call but every thread operation has to be carried out by the kernel, so switching contest similar to process Light. Weight Processes (LWP) • Manipulation of threads at user level • A blocking call doesn’t suspend the entire process • Applications don’t need to know LWPs • Different LWPs on different CPUs Combining kernel-level lightweight processes and user-level threads.
Multithreaded Servers The true benefit from multithreading in DS is having multithreaded servers A multithreaded server (i. e. file server) organized in a dispatcher/worker model.
Multithreaded Servers Model Characteristics Threads Parallelism, blocking system calls Single-threaded process No parallelism, blocking system calls Finite-state machine Parallelism, nonblocking system calls Three ways to construct a server: The multi- and single-threaded models are “sequential” and synchronous The finite-state machine model is asynchronous and simulates the multi-threaded model; instead of blocking, it records the request and gets the next message. Not a sequential process, hard to program.
Client-Side Software for Distribution Transparency Client software is a lot more than user interfaces Access, location, migration, replication, failure transparency: cooperation with client-side software A possible approach to transparent replication of a remote object using a client-side solution.
Servers: General Design Issues • • Iterative server – the server itself handles the request Concurrent server – the server passes the request to a separate thread or process • • Stateless server – no information on clients state (Web) Stateful server – maintains information on clients state (file server: AFS) Where clients contact a server? • Pre-assigned endpoint (port) • No pre-assigned endpoint a special daemon running on the server
Servers: General Design Issues 3. 7 a) b) Client-to-server binding using a daemon as in DCE Client-to-server binding using a superserver as in UNIX (inetd)
Object Server • An object server doesn’t provide a real specific service • Services are provided by objects • One can add or modify services adding or modifying objects Different invocation approach can be used to invoke an object in an object server (activation policy) An object adapter (or o. wrapper) is a mechanism to group objects per policy An obj. adapter controls one or more objs. If a server supports objs with different activation policy, several adapters reside on the same server Organization of an object server supporting different activation policies.
Reasons for Migrating Code Improving performances ( optimizing CPU load, minimizing communication…) and flexibility The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server (security!)
Process segmentation • • • Code segment: set of instruction of the program Resource segment: references to external resources needed to the process Execution segment: current execution state of the process Mobility • • Weak mobility: only code segment is moved Strong mobility: execution segment too is moved Where migration starts ? • • Sender-initiated: migration initiate at the machine where the code resides Receiver initiated: migration starts by target machine initiative
Models for Code Migration Code se starts gment, pr og from initia ram l state t en m eg rom s n f tio arts u f t c xe g. s tf of e nd pro it le a d de rate ere o C ig wh M Alternatives for code migration.
Migration and Local Resources What about resource segment? To migrate code we need to migrate local references to the new machine Different types of process-to-resource and resource-to-machine bindings exist. Resource-to-machine binding Process-toresource binding By identifier By value By type Unattached Fastened Fixed MV (or GR) CP ( or MV, GR) RB (or GR, CP) GR (or MV) GR (or CP) RB (or GR, CP) GR GR RB (or GR) MV: Move the resource GR: Establish a global reference CP: Copy the resource value RB: Rebind process to local resource Actions to be taken with respect to the references to local resources when migrating code to another machine.
Migration in Heterogeneous Systems 3 -15 The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment (compiler and runtime system dependent) Migration can take place only when a subroutine is called. A migration stack is maintained in a machine independent way. (Compiler and runtime system dependent)
Software Agents in Distributed Systems autonomous units capable of performing tasks in collaboration with other agents • • Collaborative agent is part of a multi-agent system Mobile agent can move between different machine • • Interface agent assists user to interact with an application (with learning capability) Information agent manages information from many different sources Property Common to all agents? Description Autonomous Yes Can act on its own Reactive Yes Responds timely to changes in its environment Proactive Yes Initiates actions that affects its environment Communicative Yes Can exchange information with users and other agents Continuous No Has a relatively long lifespan Mobile No Can migrate from one site to another Adaptive No Capable of learning
Agent Technology Agent Communication channel Creating, deleting, Looking up endpoint Naming service Other agents in platform services The general model of an agent platform (from Foundation for Intelligent Physical Agents (FIPA)) that could be incorporate in middleware. An agent platform provides basic services (creating, deleting, locating. . . agents) for a multi-agent system.
Agent Communication Languages ACL is an application level protocol providing an high level communication protocol between a collection of agents Message purpose Description Message Content INFORM Inform that a given proposition is true Proposition QUERY-IF Query whether a given proposition is true Proposition QUERY-REF Query for a give object Expression CFP Ask for a proposal Proposal specifics PROPOSE Provide a proposal Proposal ACCEPT-PROPOSAL Tell that a given proposal is accepted Proposal ID REJECT-PROPOSAL Tell that a given proposal is rejected Proposal ID REQUEST Request that an action be performed Action specification SUBSCRIBE Subscribe to an information source Reference to source Examples of different message types in the FIPA ACL, giving the purpose of a message, along with the description of the actual message content.
Agent Communication Languages (example) Field Value Purpose INFORM Sender max@http: //fanclub-beatrix. royalty-spotters. nl: 7239 Receiver elke@iiop: //royalty-watcher. uk: 5623 Language Prolog Ontology genealogy Content female(beatrix), parent(beatrix, juliana, bernhard) A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information. The message is specific to the communicating agents; no format or language is prescribed for the content of the message
- Slides: 19