Distributed

Computing

Lecture 9:
Remote Invocation
MR.FREDRICK
BOAFO
 Distributed
Reference Computing

Chapter 5
of
Coulouris G.,Dollimore J.,Kindberg T.,Blair G.,“Distributed
Systems:Concepts and Design”, 5 th Edition, Addison-Wesley,2012
 Distributed
Learning Outcomes Computing

This lecture specifical y focuses on achieving the following ILO

• Havea good understanding of RPC,its role in middleware,

issues in its design (e.g. transparency), and how it is
implemented
 Distributed
Outline Computing

• Request-reply protocols
• Remote procedure cal
• Remote method invocation
• Casestudy: JavaRMI
 Distributed
Middleware Layers Computing

We study this layer deeply

Distributed
Computing
Distributed
Computing
Distributed
Computing
 Distributed
Request-Reply Protocols Computing

Request-Reply communication
 Distributed
Request-Reply Protocols: Computing
Operations
• public byte[] doOperation (RemoteRefs, int operationId, byte[] arguments);

– Sendsa request message to the remote server

– Returns the reply arguments of theoperation
operation to be invoked

• public byte[] getRequest ();

– Acquires a client request via the server port

• public void sendReply(byte[] reply, InetAddress clientHost, int clientPort);

– Sends the reply message to the client at its Internet address and port
 Distributed
Request-Reply Protocol: Computing
Message Structure
Theinformation to be transmitted in a requestmessageor a reply

• Eachmessagewill have a unique messageidentifier

( requestId, Identifier for the sender process )

e.g. port and Internet address

 Distributed
Request-Reply Protocols Computing

• Designed to support the rolesand messageexchangesin

client-server interactions
• Thecommunication is ‘usually’ synchronous
– Client processblocks until it receivesreply from the server
– Asynchronous request-reply communication is an alternativethat
may be useful in situations where clients can afford to retrieve
replies later
• The communication ‘can be’ reliable
– Thereply from the server is an acknowledgement to the client
 Distributed
Request-Reply Protocols Computing

• Canbe implemented using UDPorTCP

• UDPimplementation avoids the overheads associated with the
TCP stream protocol suchas;
– Acknowledgements are redundant because requests are followed
by replies
– Establishing a connection needs two extra pairs of messages
– Flow control is redundant (due to small arguments and results)

However,TCP simplifies implementation of request –reply

protocols (see the failure model inthe later slides)
 Distributed
Request-Reply Protocols: Computing
Failure Model
• If the three primitives are implemented over UDP datagrams,
– omissionfailures may occur
– messagesare not guaranteed to be delivered in senderorder
• Theprotocol may suffer from failure of processes(may crash)
– when processes halt, they remain halted – no Byzantinebehavior

• Totake care of server failures doOperation() usestimeouts

after a timeout,
– Either doOperation() may return producing error messageor
– Sends the requests repeatedly until it gets a reply or until
it identifies that the delay is due to lack of server response
 Distributed
Request-Reply Protocols: Computing
Failure Model (Continued…)
• The protocol is designed to recognize successive messages
(from the sameclient) with thesame request identifier, to filter
out duplicates.
canbe performed repeatedly with
the same effect asif it
had been performed exactly once.

• A server whose operations are all idempotent need not take

special measures to avoid executing its operations more than
once.
• In order to retransmit replies without re-execution of
operations, a history may be used by the server
A structure containing record of (reply) messagesthat has been transmitted
contains a request identifier, a messageand an identifier of the client
 Distributed
Request-Reply Protocols: Computing
TCP option
• TCP streams allow arguments and results of any sizeto
be transmitted
• If TCPprotocol is used to implement request-reply protocols,
it ensures that request and reply messages are delivered
reliably, sothere is noneed for the request -reply protocol to
deal with retransmission of messages and filtering of
duplicatesor with histories
• The flow-control mechanism of TCP al ows large arguments
and results to be passed without any special measures to
avoid overwhelming the recipient
 Distributed
Styles of exchange protocols Computing

• Three styles of exchange protocols are commonly used:

– Request(R) protocol
– Request-Reply (RR) protocol
– Request-Reply– Acknowledge reply(RRA)protocol
• Theyproduce differing behaviours in the presence of
communication failures
 Distributed
Exchangeprotocols: Computing

Types or Styles
• Rprotocol:
– Usedwhen there is no value to be returned and when the client
need no confirmation regarding the execution of the operation
– Client need not wait for the reply
– Implemented over UDP(hence, sametypes of failures)

• RRprotocol:
– Useful for most client -server exchanges,because,itis basedon
Request-Reply protocol
• HTTP is an example
 Distributed
Exchangeprotocols: Computing
Types or Styles
• RRAprotocol:
– The Acknowledge reply message contains the requestId from the
reply messagebeing acknowledged enabling the server todiscard
entries from its history
– Thearrival of a requestId in an acknowledgement messagewill be
interpreted asacknowledging the receipt of all reply messages
with lower requestIds
– Client need not be blocked for acknowledging thereply
 Distributed
Request-Reply Protocols: Computing
Case Study
HTTP(HyperText Transfer Protocol)
• used by web browser clients to make requests to web servers
and to receive replies from them
• Resources managed by web servers may be;
– data (e.g. text of an HTMLpage, image)
– Programs (e.g. Javaservlets, PHPor Pythonprograms)
 Distributed
Request-Reply Protocols: Computing

Case Study
HTTP(HyperText Transfer Protocol)
• Theprotocol specifies the messagesinvolved in a request-reply
exchange; methods, arguments, results, and the rules for
representing (marshalling) them in themessages
• In addition to invoking methods on web resources,the protocol
al ows for content negotiation and password-style
authentication
• HTTP is implemented overTCP
• Methods used:
– GET,HEAD,POST,PUT, DELETE,OPTIONS,TRACE
 Distributed
Request-Reply Protocols: Computing
Case Study
HTTP(HyperText Transfer Protocol)
• HTTPrequest message:

• HTTPreplymessage:
 Distributed
Request-Reply Protocols: Computing
Case Study
HTTP(HyperText Transfer Protocol)
• Things to observe/note:
– What version of http is being usedcurrently?
– How is it different from the originalversion?
– What operations of httpare idempotent? How are they useful?
– How are the request and reply messages marshalled?
– What is the structure of request message?
– What is the structure of the replymessage?
 Distributed
Remote Procedure Cal : Computing
(RPC)
• Design goal: Making the programming of distributed systems
look similar to conventional programming
• Idea: Procedureson remote machines canbe cal ed asif they
are procedures in the local address space
• Effect:Theunderlying RPCsystemhidesimportant aspects
of distribution like
– encoding and decoding of parameters and results
– the passing of messagesand
– preserving of the required semantics for the procedure call
 Distributed
Remote Procedure Cal : Computing

Design Issues
• Three issuesare important in understanding the RPCsystems
– Thestyle of programming :- programming with interfaces
– Transparency and its relation with RPC
– The call semantics
 Distributed
Remote Procedure Cal : Computing

Design Issues
• Programming with Interfaces:
– Modules in programs are defined with interfaces, whichspecifies
the procedures and variables that can be accessed for the
purpose of communication
– In distributed programs,modules can run in separate processes
– In the client-server model, the specification of procedures offered
by a server is referred to asservice interface
 Distributed
Remote Procedure Cal : Computing

Design Issues
• Programmingwith Interfaces - Advantages
• Programmers are concerned only with the abstraction offered
by the service interface
– Implementation need not beknown
• Heterogeneity of the underlying platform andprogramming
language are masked
• Provides natural support for software evolution
– Implementations can change aslong asthe interface remains
same
 Distributed
Remote Procedure Cal : Computing

Design Issues
• ServiceInterface definition – caveats for distributed systems:
– Service interface cannot specify direct accessto variables
– The call by reference parameter-passing mechanism used in local
procedure cal s is not supported
– Specification of a procedure in the interface of a module
describes the parameters asinput and/or output
those sent in the request messages those sent in the reply
to the server and used as messages from the server and
arguments in the remote operation used in the calling environment

– Addressesin processes cannot be passedasarguments or

returned asresults of cal s to remotemodules
 Distributed
Remote Procedure Cal : Computing

Design Issues
• Interface DefinitionLanguages(IDLs):
– IDLsare designedto allow procedures implemented indifferent
languages to invoke one another
– IDLprovides a notation for defininginterfaces
• eachof the parametersof an operation maybe described as
whether it is for input or output in addition to its type
– Concept of an IDLwas initially developed for RPCsystemsbut
applies equally to RMI and also webservices.
• SunXDR: Example of an IDLfor RPC
• CORBAIDL: Example of an IDLfor RMI
• WebServicesDescription Language(WSDL):designedfor Internet -
wide RPCsupporting web services
• protocol buffers usedat Googlefor storing and interchanging many
kinds of structured information
 Distributed
Remote Procedure Cal : Computing

Design Issues
• RPC cal semantics: (Describes the fault-tolerance in RPC)

Indicates execution of procedure at the server

Note: Forlocal procedure calls, the semantics are exactly once

(except for process failure)
 Distributed
Remote Procedure Cal : Computing

Design Issues
• Maybe semantics:
– Theremote procedure call may be executed once or not at all
– Arises when no fault-tolerance measures are applied
– Suffers from;
• Omission failures (when the request or result is lost)
• Crashfailures (when the server hosting the remote operationfails)
– Useful only for applications in which occasionalfailed cals are
acceptable.
 Distributed
Remote Procedure Cal : Computing
Design Issues
• At-least-once semantics:
– The invoker receives either a result
(indicates that the procedure is executed at least once) or
an exceptioninforming it that no result was received
– Retransmission of request messages masks the omission failures
of the request or result message
– However, suffers from;
• Crashfailures (when the server hosting the remote operation fails)
• Arbitrary failures (in case of retransmission, the remote server may
execute the procedure more than once causing the wrong values to
be stored or returned)
– Example: increasing bank balance by $10 should be done only once
– Acceptable when service interface hasidempotent operations
 Distributed
Remote Procedure Cal : Computing
Design Issues
• At-most-once semantics:
– The invoker receives either a result
(indicates that the procedure is executed exactly once) or
an exceptioninforming it that no result was received
(i.e., the procedure will have been executed either once or not atall)
– Usesall the fault tolerance measures; retransmitting reply,
duplicate filtering, re-execution of procedure
– omission failures can be masked by retransmission
– arbitrary failures can be prevented by executing proceduresat
most once
 Distributed
Remote Procedure Cal : Computing
Design Issues
• Transparency: Transforming to a format suitable for transmission

– All the necessary cal s to marshalling and message-passing

procedures were hidden from the programmer making thecall
– Retransmission of request messages after a timeout is abstracted
(i.e., Location and accesstransparencies are guaranteed)
– Middleware supports RPC with additional levels of transparency
– Achieving Failure transparency is challenging
• Impossible to distinguish between failure of network and failure of
remote server
– Latency of RPC is greater than local call by several orders
of magnitude (programs should consider thisfact)
• Caler should be able to abort a call taking longer time with no effect
on the server
 Distributed
Remote Procedure Cal : Computing

Implementation
• Software components required for implementing RPC

Role of client and server stub procedures

 Distributed
Remote Procedure Cal : Computing
Implementation
Client side:
• For each procedure in the service interface, a stub procedure is
included
• stub procedure behaves like a local procedure to the client, but,
it does not execute the cal
• The main task of the stub is marshalling the procedure
identifier and the arguments into a request message and
sending it to the server via the communication module
• Upon receiving the reply stub unmarshals the results
• The communication module is responsible for sendingand
receiving the marshal ed messages
 Distributed
Remote Procedure Cal : Computing

Implementation
Server side:
• For each procedure in the service interface, a dispatcher, a stub
procedure and one service procedure are included
implements the procedures in the interface
• The dispatcher at the server selects one of the server stub
procedures according to the procedure identifier in the request
message
• Server stub procedure unmarshals the arguments in the
request message, cal s the corresponding service procedure
and marshals the return values to include in the reply message

Client stub, server stub, and dispatcher are generated automatically by the
interface compiler
 Distributed
Remote Method Invocation Computing

• Closely resembles RPCbut, supports object orientedparadigm

• Commonalities between RPCandRMI:
– Programming with interfaces
– Constructed on the top of request-reply protocols
– Offers similar level of transparency
• Local and remote cal s use same syntax
• But, remote interfaces exposedistributed nature of the call by
means of remote exceptions
• RMI benefits
– OOPfeatures enhanceexpressiveness
– Richer parameter passing semantics : - supports object references
• Useful for passing complex objects
 Distributed
Remote Method Invocation: Computing

Design Issues
• Design issues shared with RPC;interfaces,call semantics,
transparency
• Additionalissue:Transition from objects to‘distributed objects’
• Distributed object model:
– Some of the objects in processes can receive both local and
remote invocations
– Local invocations: between objects within the sameprocess
– Remote invocations: between objects in different processes
 Distributed
Remote Method Invocation: Computing

Design Issues
• Distributed object model:
– All objects can receive local invocations, but, if required
– Remote object references: Methods of a remote object can be
invoked by having accessto remote object reference.
– Remote interfaces: Everyremote object hasa remote interface
that specifies which of its methods can be invokedremotely
 Distributed
Remote Method Invocation: Computing

Design Issues
Remote object references:
• Aremote object reference is an identifier of a particular unique
remote object, which can be used throughout the distributed
system.
• Passedasarguments and results of remote method invocations.
• Acommonly used format (Section 4.3.4 of textbook):
 Distributed
Remote Method Invocation: Computing
Design Issues
Remote interfaces:
• Objects of a different processcaninvoke only the methods that
belong to remote interface, implemented in remote object’s
class
 Distributed
Remote Method Invocation: Computing

Design Issues
• Remote object referencesmay be obtained asthe results of
remote method invocations
• Remote objects may be instantiated by remotemethod
invocation, when the method containssuch code

• Distributed garbage collection and exceptions should be

handled by proper mechanisms
 Distributed
Remote Method Invocation: Computing
Implementation
• Modules involved in remote method invocation
 Distributed
Remote Method Invocation: Computing

Implementation
Modules involved in remote method invocation:
• Communication Module:
– Carryout the Request-Replyprotocol using the messagetype,
requestID, and remote reference fields of the message
– Responsiblefor providing a specified invocation semantics,like
‘at-most-once’
– On server side, selects the dispatcher for the class of the object to
be invoked. (local reference of the dispatcher is obtained from the
remote referencemodule)
 Distributed
Remote Method Invocation: Computing

Implementation
Modules involved in remote method invocation:
• Remote Reference Module:
– Responsiblefor translating between local and remote object
references and for creating remote object references
– Aremote object table is used to record the correspondence
between local object references and remote object references in
a process
 Distributed
Remote Method Invocation: Computing

Implementation
Modules involved in remote method invocation:
• AServant is a remote object, which handles the requests
passed by the skeleton (object of implementation class)
• TheRMIsoftware: Consistsof three major middleware objects;
Proxy, Dispatcher, Skeleton
– Proxymakesremote method invocation transparent to clients by
behaving like a local object to the invoker. Performs marshalling
and unmarshalling operations
– Dispatcher receives request messages from the communication
module, choosesappropriate method in the skeleton andpasses
on the request messages
– Skeletonunmarshals the arguments in the request messageand
invokes the corresponding method in theservant
 Distributed
Remote Method Invocation: Computing
Case Study
• Java RMI:

Assignment:
Map the theoretical concepts of RMI discussed to the Java
RMI based on the practical Java RMI exercise carried out in
the previous class
(Refer section 5.5 of the textbook)
 Distributed
Computing

Questions and Discussion…

Thank you