Home | | Distributed Systems | Remote method invocation(RMI)

Chapter: Distributed Systems : Communication in Distributed System

Remote method invocation(RMI)

Two design issues that arise in extension of local method invocation for RMI

Remote method invocation(RMI)


Design Issues for RMI

·        Two design issues that arise in extension of local method invocation for RMI

o   The choice of invocation semantics


·        Although local invocations are executed exactly once, this cannot always be the case for RMI due to transmission error


o   Either request or reply message may be lost

o   Either server or client may be crashed

o   The level of transparency

·        Make remote invocation as much like local invocation as possible


RMI Design Issues: Invocation Semantics

·        Error handling for delivery guarantees

o   Retry request message: whether to retransmit the request message until either a reply is received or the server is assumed to have failed


o   Duplicate filtering: when retransmissions are used, whether to filter out duplicate requests at the server


o   Retransmission of results: whether to keep a history of result messages to enable lost results to be retransmitted without re-executing the operations


·        Choices of invocation semantics

o   Maybe: the method executed once or not at all (no retry nor retransmit)

o   At-least-once: the method executed at least once

o   At-most-once: the method executed exactly once


Invocation semantics: choices of interest

RMI Design Issues: Transparency


·        Transparent remote invocation: like a local call

o   marshalling/unmarshalling

o   locating remote objects

o   accessing/syntax


·        Differences between local and remote invocations




o   latency: a remote invocation is usually several order of magnitude greater than that of a local one


o   availability: remote invocation is more likely to fail

o   errors/exceptions: failure of the network? server? hard to tell


·        syntax might need to be different to handle different local vs remote errors/exceptions (e.g. Argus)


o   consistency on the remote machine:

·        Argus: incomplete transactions, abort, restore states [as if the call was never made]


Implementation of RMI


·        •Communication module


o   Two cooperating communication modules carry out the request-reply protocols: message type, request ID, remote object reference


·        Transmit request and reply messages between client and server

·        Implement specific invocation semantics


o   The communication module in the server

·        selects the dispatcher for the class of the object to be invoked,

·        passes on local reference from remote reference module,

·        returns request


The role of proxy and skeleton in remote method invocation


Remote reference module


o   Responsible for translating between local and remote object references and for creating remote object references


o   remote object table: records the correspondence between local and remote object references

       remote objects held by the process (B on server)

       local proxy (B on client)


o   When a remote object is to be passed for the first time, the module is asked to create a remote object reference, which it adds to its table



       An instance of a class which provides the body of a remote object

       handles the remote requests


•RMI software


       Proxy: behaves like a local object, but represents the remote object

       Dispatcher: look at the methodID and call the corresponding method in the skeleton

       Skeleton: implements the method

Generated automatically by an interface compiler





Implementation Alternatives of RMI


Dynamic invocation

Proxies are static—interface complied into client code


Dynamic—interface available during run time

Generic invocation; more info in ―Interface Repository‖ (COBRA)

Dynamic loading of classes (Java RMI)




A separate service to locate service/object by name through table mapping for names and remote object references


Activation of remote objects

o   Motivation: many server objects not necessarily in use all of the time

§  Servers can be started whenever they are needed by clients, similar to inetd

o   Object status: active or passive

§  active: available for invocation in a running process

§  passive: not running, state is stored and methods are pending

o   Activation of objects:


§  creating an active object from the corresponding passive object by creating a new instance of its class


§  initializing its instance variables from the stored state

o   Responsibilities of activator

§  Register passive objects that are available for activation

§  Start named server processes and activate remote objects in them


§  Keep track of the locations of the servers for remote objects that it has already activated


Persistent object stores

o   An object that is guaranteed to live between activations of processes is called a


o   persistent object


o   Persistent object store: managing the persistent objects

o   stored in marshaled from on disk for retrieval

o   saved those that were modified

o   Deciding whether an object is persistent or not:

o   persistent root: any descendent objects are persistent (persistent Java, PerDiS)

o   some classes are declared persistent (Arjuna system)

o   Object location

o   specifying a location: ip address, port #, ...

o   location service for migratable objects


o   Map remote object references to their probable current locations


§  Cache/broadcast scheme (similar to ARP)

o   Cache locations

o   If not in cache, broadcast to find it

o   Improvement: forwarding (similar to mobile IP)


Distributed Garbage Collection

       Aim: ensure that an object

o   continues to exist if a local or remote reference to it is still held anywhere

o   be collected as soon as no object any longer holds a reference to it

       General approach: reference count

       Java's approach

o   the server of an object (B) keeps track of proxies

o   when a proxy is created for a remote object

       addRef(B) tells the server to add an entry

o   when the local host's garbage collector removes the proxy

       removeRef(B) tells the server to remove the entry


o   when no entries for object B, the object on server is deallocated


Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail
Distributed Systems : Communication in Distributed System : Remote method invocation(RMI) |

Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.