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, TL B … Ch ang es t o. M MU , T LB … IPC needs extensive context switching Instead of processes : threads
Thread Implementation user level : 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 Lightweight 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 A multithreaded server (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 model are “sequential” and synchronous The finite-state machine model is asynchronous and simulates the multithreaded model
Client-Side Software for Distribution Transparency 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 informations on clients state (file server) Where clients contact a server? • Preassigned endpoint (port) • No preassigned 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)
Reasons for Migrating Code Improving performances ( optimizing CPU load, minimizing communications…) 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!)
Models for Code Migration Code se starts gment, pr og from initia ram l state t en m eg om s r on rts f i t u ec. sta off x d e prog t letf n a d i de rate ere o C ig wh M Alternatives for code migration.
Migration and Local Resources 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
Software Agents in Distributed Systems autonomous units capable of performing tasks in collaboration with other agents • • Collaborative agent is part of a multiagent system Mobile agent can move between different machine • • Interface agent assists user to interact with an application Information agent manages informations 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 Naming service Other agents in platform The general model of an agent platform (from Foundation for Intelligent Physical Agents (FIPA)).
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 [fipa 98 -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.
- Slides: 17