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