REMOTE
INVOCATION
• Remote invocation enables an entity to call a procedure that typically
executes on another computer without the programmer explicitly coding
the details of communication
• The underlying middleware will take care of raw-communication
• Programmer can transparently communicate with remote entity
• Two types of remote invocations:
[Link] Procedure Calls (RPC)
[Link] Method Invocation (RMI)
REMOTE
PROCEDURE CALLS
(RPC)
• RPC enables a sender to communicate with a receiver using a simple
procedure call
• No communication or message-passing is visible to the programmer
Client Stub:
• Gets invoked by user code as a local procedure.
• Packs (or serializes or marshals) parameters into a request packet
• Invokes a client-side transport routine (e.g., makerpc(request-pkt, &reply-pkt))
• Unpacks (or de-serializes or unmarshals) reply-pkt into output parameters
• Returns to user code
Machine A – Client Machine B – Server
Client Communication
Communication Server
Program Module
Module Procedure
Request int add(int
… x, int y) {
add(a,b); return
… x+y;
}
Response
Client process Server process
Client Server Stub
Stub (Skeleton)
Server Stub
• Gets invoked after a server-side transport routine (e.g., getrequest()) is
returned
• Unmarshals arguments, de-multiplexes opcode, and invokes local server code
• Marshals arguments, invokes a server-side transport routine (e.g.,
sendresponse()), and returns to server loop
CHALLENGES IN RPC
• Parameter Passing via Marshaling
• Procedure parameters and results must be transferred over the
network as bits
• Data Representation
• Data representation must be uniform
• Architecture of the sender and receiver machines may differ
• Failure Independence
• Client and server might fail independently
1. PARAMETER PASSING VIA MARSHALING
• Packing parameters into a message that will be transmitted over the
network is called parameter marshalling
• The parameters to the procedure and the result have to be marshaled before
transmitting them over the network
• Two types of parameters can be passed:
a) Value parameters
b) Reference parameters
a) PASSING VALUE PARAMETERS
• Value parameters have complete information about the variable, and can be
directly encoded into the message
• Example: integer, float, character
• Values are passed through call-by-value
• The changes made by the callee procedure are not reflected in the caller
procedure
b) PASSING REFERENCE PARAMETERS
• Passing reference parameters in RPC leads to incorrect results due to two
reasons:
a. Invalidity of reference parameters at the server
• Reference parameters are valid only within client’s address space
• Solution: Pass the reference parameter by copying the data that is referenced
b. Changes to reference parameters are not reflected back at the client
• Solution: “Copy/Restore” the data
• Copy the data that is referenced by the parameter
• Copy-back the value at server to the client
2. DATA REPRESENTATION
• Computers in DSs often have different architectures and operating systems
• The size of the data-type differ
• E.g., A long data-type is 4-bytes in 32-bit Unix, while it is 8-bytes in 64-bit
Unix systems
• The format in which the data is stored differs
• E.g., Intel stores data in little-endian format, while SPARC stores in
big-endian format
• The client and server have to agree on how simple data is represented in the
message
• E.g., Format and size of data-types such as integer, char and float
3. FAILURE INDEPENDENCE
• In the local case, the client and server live or die together
• In the remote case, the client sees new failure types
• Network failure
• Server machine crash
• Server process crash
• Thus, failure handling code has to be more thorough (and essentially more
complex)
REMOTE PROCEDURE CALL TYPES
• An RPC with strict request-reply blocks the client until the server returns
• Blocking wastes resources at the client
• Asynchronous RPCs are used if the client does not need the result from
server
• The server immediately sends an ACK back to the client
• The client continues the execution after an ACK from the server
Client wait for result
client wait for acceptance
return
call remote call remote return
from call
procedure procedure from call
request reply
request accept request
Server
server
call local procedure and return results call local procedure
time time
Synchronous RPCs Asynchronous RPCs
DEFERRED SYNCHRONOUS RPCS
• Asynchronous RPC is also useful when a client wants the results, but does
not want to be blocked until the call finishes
• Client uses deferred synchronous RPCs
• Single request-response RPC is split into two RPCs
• First, client triggers an asynchronous RPC on server
• Second, on completion, server calls-back client to deliver the results
wait for acceptance interrupt client
client
return
call remote
from call return results acknowledge
procedure
request accept request
server
call local procedure time
call client with
asynchronous RPC
REMOTE METHOD
INVOCATION
(RMI)
• RMI is similar to RPC, but in a world of distributed objects
• The programmer can use the full expressive power of object-oriented
programming
• RMI not only allows to pass value parameters, but also pass object
references
• In RMI, a calling object can invoke a method on a potentially remote
object
• In RMI, objects whose methods can be invoked remotely are known as
“remote objects”
• Remote objects implement remote interfaces
• During any method call, the system has to resolve whether the method is
being called on a local or a remote object
• Local calls should be called on a local object
• Remote calls should be called via remote method invocation
• Remote Reference Module is responsible for translating between local and
remote object references
Machine A – Client Machine B – Server
Communication Communication
Module Module
Skeleton and
Proxy Request Dispatcher for
Obj A for B B’s class
Remote Obj
Remote Response Remote
Reference
B
Reference
Module
Module
FAILURE MODES OF RMI/RPC
Request
correct lost
Execute request
function
Reply
Request Channel
Execute fails
during
Execute, crash reply
Crash before Reply
reply
Request Client
machine
Execute fails
crash before
Crash before
Reply receiving
execution reply