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

Chapter: Distributed Systems - Communication in Distributed System

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

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

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