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.