Remote Procedure Call
By
BENAY KUMAR RAY
Asst. Professor,
Central University of South Bihar
Problems with Sockets
Sockets are a fundamental part of client-server
networking.
They provide a relatively easy mechanism for a
program to establish a connection to another
program.
Either on a remote or local machine and send
messages back and forth
Moreover, they are the only interface to the
network that most operating systems provide.
Problems with Sockets
It connects, then read/write & finally disconnect. That’s not the usual
way we program. We use Procedure Call.
In design single-process applications, the procedure call is usually
the standard, most popular, and most familiar interface model
If we want to make distributed computing look like centralized
computing, input-output-based streams are not the way to accomplish
this.
Too straightforward to achieve Distributed System properties.
The procedures send and receive do not conceal communication at
all.
Which is important to achieve access transparency in distributed
system
Solution : Remote Procedure Call
Proposed By Birrell and Nelson (1984)
Mechanisms to call procedures on other machines
Processes on machine A can call procedures on machine B
1. Calling process on machine A is suspended
2. Execution of called procedures takes place on B
3. When B returns the result, control passed back to A
4. A is resumed
It should appear to the programmer that a normal
procedure call is taking place
No message passing or I/O is visible to the programmer
Used by both Operating Systems and Applications:
NFS is implemented as a set of RPCs
CORBA, Java RMI are just RPC Systems.
Conventional Procedure Call Mechanism
int cnt = read(fd, buff, nbytes) fd: is an integer indicating a
Main Program file.
Local Variable buff: is an array of
characters into which data
nbytes are read
buff Nbytes: is another integer
fd telling how many bytes to
read
Return Address
read’s
Local Variable
System Call
Operating System
Remote Procedure Call: Client and Server
Stubs
The idea behind RPC is to make a remote procedure call look
as much as possible like a local one.
We want RPC to be transparent-the calling procedure should
not be aware that the called procedure is executing on a
different machine or vice versa
Note: (in case of single processor system) When program needs
to read some data from a file.
The programmer puts a call to read in the code to get the data
In a single-processor system, the read routine is extracted
from the library by the linker and inserted into the object
program.
It is a short procedure, which is generally implemented by
calling an equivalent read system call.
read procedure is a kind of interface between the user code
and the local operating system..
Remote Procedure Call: Client and Server
Stubs
In case of RPC: Client Stub
When read is actually a remote procedure, a different version
of read, called a client stub, is put into the library.
Like the traditional or conventional one, it too, is called using
the same calling sequence.
Like the conventional one, it too, does a call to the local
operating system.
But only unlike the original one, it does not ask the operating
system to give it data.
Instead, it packs the parameters into a message and requests
that message to be sent to the server
Following the call to send(), the client stub calls receive(),
blocking itself until the reply comes back.
Remote Procedure Call: Client and Server
Stubs
In case of RPC: Server Stub
When the message arrives at the server, the server's operating
system passes it up to a server stub.
A server stub is the server-side equivalent of a client stub:
It is a piece of code that transforms requests coming in over the
network into local procedure calls.
The server stub unpacks the parameters from the message and then
calls the server procedure in the usual way (like conventional one).
From the server's point of view, it is as though it is being called
directly by the client:
The parameters and return address are all on the stack.
The server performs its work and then returns the result to the
Server stub
Server Stub packs the result (the buffer) in a message and calls
send to return it to the client
RPC Mechanism
1. Client calls the Client stub in normal
way
2. Client stub builds a message &
Client Process Server Process
calls the OS
k = add ( i, j ) 3. Client OS sends the message to add ( i, j )
Remote OS
4. Remote OS gives the message to Server
Stub
5. Server Stub unpacks the message & calls the
Server
6. Server completes & returns the result
to Server Stub
Client Stub 7. Server Stub packs it into message & Server Stub
calls the OS
proc 8. Server’s OS sends the message to the proc : “add”
proc :: “add”
“add” proc : “add”
int : val(i)
int : val(k)
Client’s OS int
int :: val(i)
val(k)
int : val(j) 9. Client’s OS gives the message to int : val(j)
Client Stub
10. Client Stub unpacks the result & return
to client
NOS NOS
RPC Issues
Transparency
Parameter Passing
Heterogeneity
Dynamic Binding
Failure
Performance
Security
Parameter Passing
Call By Value:
Easy, just copy data or value into messages
Call By Reference / Pointer
Not possible, since processes running on
different address space
Alternative:
1. Copy referenced items into message buffer
2. Server stub sends local pointers to such buffers
to the Server
3. Server Stub returns the original message back
to the client
Heterogeneity
Remote Computer may have:
Different byte ordering (little endian/big endian)
Different sizes for data types
Different floating point representations (decimal,
binary, octal etc.)
Different Character set () For example, the protocol could
prescribe that integers are represented in two's complement,
characters in 16-bit Unicode, and floats in the IEEE standard #754
format
Solution : Standard encoding to enable
communication between heterogeneous systems
Example : Sun’s eXternal Data Representation
(XDR) or XML
Heterogeneity : Data Representation
Implicit typing
Only values are transmitted, not data type or
parameter information
E.g., Sun XDR (eXternal Data Representation)
Explicit typing
Types are transmitted with values
E.g., XML
Dynamic Binding
Clients need binding with Server before communication. How
Client finds Server?
Static binding uses Server’s address as hardcoded in the Client
code.
Disadvantage: If server moves or replicated, the numerous
programs will have to be found and recompiled.
Dynamic binding uses a program, called binder, to bind with
Server at Runtime.
Call By Input Output
register Server Name, Version, Handle, UniqueId
lookup Client Name, Version Handle, UniqueId
deregister Server Name, Version, UniqueId
Dynamic Binding(Cont.)
MyName
Naming Service OtherName
---
Lookup for Register with
MyName MyName
Client Server
Create
Remote Object
X
Failure C ? S
X
RPC Failures:
Client unable to locate Server
Request message from Client to Server is lost
Reply message from Server to Client is lost
Server crashes after receiving a request
Client crashes after sending a request
Can’t locate server:
Proper exception handling or Signaling.
Message lost:
Retransmission & Duplicate handling.
Failure (Cont.)
Server Crashes:
Receive Receive Receive
REQ REQ REQ
Execute Execute Crash
REP NO REP NO REP
Reply Crash
Normal Case Crash after Execution Crash before Execution
Solution with various Call Semantics:
1. At least once : Try until a reply received.
2. At most once : Report failure without retry.
3. Exactly once : No way to guaranty.
Failure (Cont.)
Client Crashes:
Orphan : Active Computation without parent.
Problems:
Waste CPU Cycle
Locked resources.
Confusion betwn recovered client reissue & result from
orphan
Solution:
Extermination :
• Client stub maintains a log & kills the orphans explicitly at
reboot.
• Disadvantage:
Log maintenance is expensive.
Orphans may create grand-orphans by doing RPCs.
Its very difficult to locate them
Even after locating they may not be killed due to
partitioned network.
Failure (Cont.)
Reincarnation :
• Divide times in epochs
• Client broadcasts new epoch when reboots
• Upon hearing a new epoch servers kills the remote
computation on behalf on that client
Gentle Reincarnation :
• When an epoch broadcast comes in, each machine check
to see if it has any remote computations
• If found, tries to locate their owner
• Only if the owner cannot be found is the computation killed.
Expiration :
• Each RPC is given a lease T to finish computation
• If it does not, it needs to ask for another lease
• If client reboots after T sec all orphans are gone
Problem: what is a good value of T?
Examples: CORBA
If existing system is integrated to form Distributed
System then the problems arises are:
Different Operating System
Different Languages
Solution: CORBA
Common Object Request
Broker Architecture
Examples: CORBA
Objective of CORBA:
Platform Independency
Language Independency
Examples: CORBA
ORB: Object Resource Broker (provide platform independency)
IDL (language): Client and Server communicate with each other
in IDL language (provide language independency)
IIOP: Internet inter operable protocol
Examples:Java RMI (Remote Method Invocation)
Platform Independent
It is a mechanism that allows an object residing in one system (JVM)
to access/invoke an object running on another system at separate
address space.
RMI is used to build distributed applications
it provides remote communication between Java programs.
It is provided in the package java.rmi.
Architecture of an RMI Application
In an RMI application, we write two programs, a server program
(resides on the server) and a client program (resides on the client).
Inside the server program, a remote object is created and reference
of that object is made available for the client (using the registry).
The client program requests the remote objects on the server and
tries to invoke its methods.
Examples:Java RMI
(Remote Method Invocation)
Stub − A stub is a representation (proxy) of the remote object at client. It
resides in the client system; it acts as a gateway for the client program.
Skeleton − This is the object which resides on the server side. stub
communicates with this skeleton to pass request to the remote object.
RRL(Remote Reference Layer) − It is the layer which manages the
references made by the client to the remote object.
Transport Layer − This layer connects the client and the server. It
manages the existing connection and also sets up new connections.
Examples:Java RMI (Remote Method Invocation)
Platform Independent
RMI Registry
RMI registry is a namespace on which all server objects are placed.
Each time the server creates an object, it registers this object with the
RMIregistry (using bind() or reBind() methods). These are registered
using a unique name known as bind name.
To invoke a remote object, the client needs a reference of that object.
At that time, the client fetches the object from the registry using its
bind name (using lookup() method).
Examples:Java RMI (Remote Method Invocation)
Platform Independent
RMI Registry
