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
InterProcess Communication mechanisms (Unix)
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
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 [fipa98-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.