DISTRIBUTED PROCESS IMPLEMENTAION

Download Report

Transcript DISTRIBUTED PROCESS IMPLEMENTAION

DISTRIBUTED PROCESS IMPLEMENTAION
BHAVIN KANSARA
OBJECTIVE


Logical Model Of Local And Remote Processes
Three application scenarios
• Remote Service
• Remote Execution
• Process Migration


Mobile agent
Process migration vs. mobile agents
Logical Model Of Local And Remote Processes
CLIENT
SERVER
Local Process
Remote Process
Stub Process
Stub Process
THREE APPLICATION SCENARIOS
Depending on how request messages are interpreted,
there are three significant application scenarios :



Remote Service
Remote Execution
Process Migration
REMOTE SERVICE
Its primary application : resource sharing in
distributed systems.
request message for remote service can be
generated at three different software levels.
•
•
•
As remote procedure calls at the language level
As remote commands at the operating system level
As interpretive messages at the application level
Remote Procedure Calls At The Language Level
At language level for remote service requests
Most suitable model : RPC
It is service oriented and provides both access and location transparency
At the operating system level
There are some frequently used commands that need to invoke
remote objects. These commands can be built in as part of the
command shell and recognized by the local operating system
Remote Commands At The Operating System Level
Remote commands are limited only to shell commands. The concept can be
generalized to process messages.
user
invoke
Want to send message
Remote host
Some user-defined operations at remote host
Stub process at Server site has capability of
-- Interpreting messages sent from client stub
-- invoking respective operations
Rules  application communication protocol
Based on
the content
of message
Interpretive Messages At The Application Level
Remote operations
Initiated by
Remote procedure calls
remote commands
interpretive messages
Constrained to
Services that are supported at the remote host
Primary implementation issues
I/O redirection
Client stub
server stub
copies
copies
security
Client process’ standard input to the
remote command
Standard output and error of the remote
command to client process
Access to remote
resources required
authorization
REMOTE EXECUTION
• Remote operation initiated by client is created by the client
• message sent from client to server is client program to be executed at the
server
Means generating process at remote host
Selected host
System with specific resources
for resource sharing
System with purpose of
load sharing
Remote Execution
Remote Service
Implementation issue
Load sharing algorithm
location independence
system heterogeneity
protection and security
Load sharing algorithm
Process server
Responsible for
Remote execution
Initiated
Relationship of process
Maintaining load information
negotiating remote host
invoking remote operation
creating stub processes for linking client& server
Implicitly – local process server
explicitly – process
Parent/child or disjoint
Load sharing algorithm
Practical implementation
Each process server maintain list of registered hosts
First step is to select remote host
Client process server
indicate
Resource requirement to process server at
remote site
If authenticated and its resource request can be met
Server grants permission for remote execution
LOCATION INDEPENDANCE
Process created by
remote execution
require
Coordination to accomplish
common task
So, it is necessary to support logical view for the processes
Each remote process is represented by an agent process at the
originating host
SYSTEM HETEROGENEITY
If remote execution is invoked on heterogeneous host
It is necessary to recompile the program
Overhead may be too high
Solution
Use canonical machine-independent intermediate language for
program execution.
PROTECTION AND SECURITY
Remote execution
powerful
Foreign code image can be Trojan horse
Solution
• Accept only remote execution in source or intermediate codes
• Language used to describe a remote execution could be
restricted to exclude potential problems
• Run-time checking of parameters and stack overflow is also
necessary to protect the integrity of the remote hosts
PROCESS MIGRATION
Time
Source Site
Destination Site
Process P1
:
:
:
:
Execution
suspended
Freezing
time
Transfer of
control
Execution
Resumed
:
:
:
:
Process P1
LINK REDIRECTION
Total Freezing
Pretransferring
Source
node
Source
node
Suspended
Freezing
time
Destination
node
Destination
node
Migration
decision
Migration
decision
Transfer of
address space
Transfer of
address space
resumed
Merits:
easy implementation
Demerits: long delay time
Suspended
Freezing
time
resumed
Merits:
freezing time reduce
Demerits: total time extended
MESSAGE FORWARDING
Three types of messages:
1. received when the process execution is stopped on the source
node and has not restarted on the destination node
2. received on the source node after the execution started on
destination node
3. sent to the migrant process after it started execution on
destination node
MESSAGE FORWARDING
Resending messages
Origin
Receiver
Sender
Send
Ask origin site
Origin
Sender
Send
ResendMigrate
Dest 1
Receiver
Migrate
Forward
Dest 1
Resend again
Migrate again
Dest 2
messages of type 1 and 2 are either dropped
or negatively ack-ed, the sender is notified
and it needs to locate the migrant process
Migrate again
Dest 2
origin node keeps the info on the current
location of the process created there, all
messages are sent to origin which
forwards them to migrant process
MESSAGE FORWARDING
Link traversal
Origin
Sender
Send
Send
Receiver
Forward
Link
Migrate
Dest 1
Forward
Link
Migrate again
Dest 2
messages of type 1 are queued and
sent to destination node as part of
migration procedure
link is left on source node to redirect
messages of type 2 and 3, link
contains the system-wide
unique id of a process and its last
known location
MESSAGE FORWARDING
Link Update
Origin
Sender
Send
Receiver
New location
Migrate
Send
New location
Send
Current location
Dest 1
Migrate again
Dest 2
during the transfer the source node
sends the notification (link update)
of the transfer to all the nodes to
which the process communicates:
messages of type 1 and 2 are
forwarded by the source node
messages of type 3 are sent
directly to the destination node
MOBILE AGENTS
• it is composition of computer software and data which is able to move
from one computer to another autonomously and continue its execution on
the destination computer.
• It refers to a process that can transport its state from one environment to
another, with its data intact
• Mobile agents can decide when and where to move next
• When a mobile agent decides to move, it saves its own state and transports
this saved state to next host and resume execution from the saved state.
Common applications include:
• Resource availability, discovery, monitoring
• Information retrieval
• Network management
• Dynamic software deployment
Process migration vs. mobile agents
Process Migration
Mobile Agents
Navigational
Autonomy
Migration decision is made by
system.
Agents decide where and where to
go
Code Execution
Programs are fully compiled and
executed in native mode.
Most agents are coded in Java and
are interpreted by their execution
engine.
Strong/Weak Migration
Execution is resumed where it
has been suspended.
Java-based agents resume their
execution from the top of a given
method.
I/O State
Long-term I/Os are forwarded to
processes migrated to the
destination.
Agents relinquish I/O connections
every time they depart for their
next destination.
REFERENCES
Distributed operating system and algorithms
Randy chow, Theodore johnson
A Framework for Process Migration in Software DSM Environments
ieeexplore.ieee.org/iel5/6662/17807/00823407.pdf …. ( 2000 )
Presentation on Parallel & Distributed Computing
courses.washington.edu/css434/slides/Migration.ppt
Mobile agent - Wikipedia, the free encyclopedia
en.wikipedia.org/wiki/Mobile_agent