Distributed Process Implementation Hima Mandava

OUTLINE Logical Model Of Local And Remote Processes Application scenarios Remote Service Remote Execution Process Migration Mobile agent Process migration vs. mobile agents

Logical model of local and remote processes Client server model similar to RPC implementation. It assumes that there are front-end stub processes to facilitate the creation of and communication between processes on different machines. All subsequent communication between local and remote processes is supported indirectly through stub processes.

Logical model of local and remote processes Stub Processes at the server site interprets the messages from the client stub and invokes respective operations.

Significant Application Scenarios Depending on how request messages are Interpreted, there are 3 application scenarios: Remote service: The message is interpreted as a request for a known service at remote site. Remote execution: The messages contain a program to be executed at the remote site. Process migration: The messages represent a process being migrated to the remote site for continuing execution.

Remote service Its primary application is resource sharing in distributed systems. A request message for service can be generated at 3 different software levels. As remote procedure calls at language level. As remote commands at the operating system level. As interpretive messages at application level.

Remote service As remote procedure calls at language level. It is service oriented and provides both access and location transparency. As remote commands at the operating system level. Some frequently used commands that are built in part of command shell like rcp in unix are used to invoke remote objects. As interpretive messages at application level. Messages are interpreted by user-defined daemon processes. A good example is file transfer protocol ftp. Primary implementation issues are I/O redirection and security in Remote service.

Remote execution It is spawning of a process at a remote host. Assumes remote operation initiated by client is created by client. The message sent from client to a server is a client program to be executed at the server. It is a processor-pool model for distributed computation. Implementation of remote execution is more complex.

Remote execution Additional implementation issues are: Load sharing algorithms Location independence System heterogeneity Protection and security

Load sharing algorithms A remote host is selected first. For practical implementation each process server maintains a list of registered hosts. Registering and deregistering services can be implemented by broadcasting. Selection process can also go through a centralized broker process. If the client’s resource requirements are met and is authenticated, server grants permission for remote execution. Finally client initializes the process forked at the remote site.

Location independence Coordination is required among processes created by remote execution to accomplish a common task. It is necessary to support a logical view for the processes. Each remote process is represented by an agent process at the originating host. The file system of originating process is used to provide a common logical computer view for the processes.

System heterogeneity If a remote execution is to be invoked on a heterogeneous host, it is necessary to recompile the program. Overhead may be too high to justify remote execution. As a solution canonical machine-independent intermediate language is used for program execution. To translate data, an External Data Representation (XDR) is integrated into remote execution facility.

Protection and Security It is safer to accept remote execution only in source or intermediate codes. The language could be restricted to exclude potential problems such as use of pointers and multiple inheritance. Run-time checking of parameters and stack overflow is also necessary. In distributed systems protection and security issues for remote execution are topics of ongoing research.

Process migration The load-sharing model is further extended to allow a remote execution to be preempted and moved to another remote host. Since the target process for migration is preempted, its state information must also be transferred. State information consists of computation state and communication state. The computation state is the information necessary to save and restore a process at the remote site and communication state is the status of process communication links and messages in transit.

Process migration Process P1 : Execution suspended Source Site Destination Site Execution Resumed : Process P1 Transfer of control Time Freezing time

Link redirecting Transfer of address space Source node Destination node Suspended Migration decision resumed Freezing time Transfer of address space Source node Destination node Suspended Migration decision resumed Freezing time Total Freezing Pre transferring Merits: easy implementation Demerits:long delay time 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 Sender Origin Dest 1 Dest 2 Receiver Migrate Migrate again Resend Resend again Send Resending messages Messages of type 1 and 2 are either dropped or negatively acknowledged. The sender is notified and it needs to locate the migrant process

Message forwarding Sender Dest 1 Dest 2 Receiver Migrate Migrate again Send Forward Origin 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. Ask origin site

Message forwarding Sender Origin Dest 1 Dest 2 Receiver Migrate Migrate again Link traversal Link Send Forward Send 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 Sender Origin Dest 1 Dest 2 Receiver Migrate Migrate again Link Update Send New location Send New location Send Current location 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 A mobile agent is a process that can transport its state from one environment to another, with its data intact, and be capable of performing appropriately in the new environment. Mobile agents decide when and where to move. Common applications include: Resource availability, discovery, monitoring Information retrieval Network management Dynamic software deployment

Mobile agents Mobile agents are agents that can physically travel across a network, and perform tasks on machines that provide agent hosting capability. This allows processes to migrate from computer to computer, for processes to split into multiple instances that execute on different machines, and to return to their point of origin. Unlike remote procedure calls, where a process invokes procedures of a remote host, process migration allows executable code to travel and interact with databases, file systems, information services and other agents. 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.

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 ExecutionPrograms 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 StateLong-term I/Os are forwarded to processes migrated to the destination. Agents relinquish I/O connections every time they depart for their next destination.

Research work Freeze Free algorithm for process migration to reduce process migration latency. A dynamic scheduling mechanism that considers migration cost as well as other conventional influential factors for performance optimization in a shared, heterogeneous environment. Extended elementary object system (EEOS), we developed a formal model for a generic secure mobile- agent system. Redirection Algorithms for Load Sharing in Distributed Web-server Systems.

Future work Protection and security issues for remote execution in distributed systems. Improvement of Performance and scalability in mobile agents. A system with transparent migration facility in distributed processing.

Resources Distributed operating system and algorithms Randy chow, Theodore Johnson Fast Dynamic Process Migration ieeexplore.ieee.org.ezproxy.gsu.edu/stamp/stamp.jsp?tp=&arnumber= (1996) Dynamic Scheduling with Process Migration ieeexplore.ieee.org.ezproxy.gsu.edu/stamp/stamp.jsp?tp=&arnumber= (2007) Redirection Algorithms for Load Sharing in Distributed Web-server Systems ieeexplore.ieee.org.ezproxy.gsu.edu/stamp/stamp.jsp?tp=&arnumber= (1999) Formal Modeling and Analysis of a Secure Mobile-Agent System ieeexplore.ieee.org.ezproxy.gsu.edu/stamp/stamp.jsp?tp=&arnumber= (2008) Presentation on Parallel & Distributed Computing courses.washington.edu/css434/slides/Migration.ppt Mobile agent - Wikipedia, the free encyclopedia

Thank You