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

 

Servant

       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)

 

•Binder

 

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.