Remote Procedure

Call
Chapter Outline
• Discussion on most primitive service, request-reply
communication, which represents relatively minor
enhancements to the underlying interprocess communication
primitives
• Discussion on the two most prominent remote invocation
techniques for communication in distributed systems
• The remote procedure call (RPC) approach extends the common
programming abstraction of the procedure call to distributed
environments, allowing a calling process to call a procedure in a
remote node as if it is local
• Remote method invocation (RMI) is similar to RPC but for
distributed objects.
Introduction

⚫ Remote Objects : that receive remote invocations and implement a remote

interface

⚫ Extended programming models for distributed applications

◦ Conventional procedure call model to Remote procedural call model
● Client programs to call procedures in server programs running in
separate processes /different computers
◦ Object based programming model to Remote method invocation
● Objects living in one process to invoke the methods of an object living
in another process
◦ Event based programming model
● To receive notification of the events at other objects in which they have
registered interest

by Kumudha Raimond
Middleware
⚫ Middleware consists of a layer of services added between those of a regular
network OS and the actual applications
⚫ It offers an infrastructure that enables application processes to
communicate with each other
⚫ It facilitates the implementation of distributed applications and attempt to
hide the heterogeneity of the underlying system architectures (both
hardware and software) and provide location transparency
⚫ Middleware is usually based on a particular model, for describing
distribution and communication (procedure call model, object model, event
based model)
⚫ Model automatically provides an abstraction for programmers to follow,
and provides direction for how to design and set up the distributed
applications

by Kumudha Raimond
Middleware Hides Heterogeneity

Applications

RMI, RPC and events

Middleware
Request reply protocol layers

External data representation

Operating System

by Kumudha Raimond
Why Middleware?
Distributed computing environments are heterogeneous:
⚫ Networks
◦ ATM, Ethernet, etc. have different protocols
⚫ Computer hardware
◦ data types (integers) can be represented differently
⚫ Operating systems
◦ the API to IP differs from one OS to another
⚫ Programming languages
◦ e.g., different paradigms (functional, OO, etc.)
◦ e.g., data structures (arrays, records) can be represented
differently
⚫ Applications implemented by different developers
◦ Use different standards
by Kumudha Raimond
Middleware Characteristics
⚫ Location transparency
◦ client/server need not know their location (transparency provided by RPC,
RMI, Event based)
⚫ Sits on top of OS, independent of
◦ Communication protocols:
use abstract request-reply protocols over UDP, TCP
◦ Computer hardware:
use external data representation e.g. CORBA CDR
◦ Operating system:
The higher level abstractions provided by the middleware layer are
independent of the underlying OS
◦ Programming language:
e.g. CORBA supports Java, C++

Middleware provides a programming abstraction and masks the

by Kumudha Raimond
heterogeneity of networks etc.
Middleware Programming Models
Commonly used models:
⚫ Distributed objects and remote method invocation
(Java RMI, Corba (Middleware that is language-independent), Microsoft
COM, DCOM, Enterprise Java Beans, SOAP (Simple Object Access
Protocol) – (HTTP is request-reply protocol & XML for data
representation)
⚫ Remote event notification (Jini)
⚫ Remote Procedure Calls (SunRPC, DCE RPC, XML-RPC)
⚫ Message Oriented (Java Message Queue, IBM MQSeries)
⚫ Distributed transaction processing (IBM CICS, BEA Tuxedo)

CORBA:
⚫ provides remote object invocation between
◦ a client program written in one language and
by Kumudha Raimond
Introduction
Issue : Design of RPC with transparency property
A transparency mechanism : Local and remote procedures are
indistinguishable to programmers
This requires the following two types of transparencies:
Syntactic Transparency : RPC should have exactly the same syntax as a local
procedure call
Semantic Transparency : Semantics of a RPC are identical to those of a local
procedure call
Introduction
Definition :

A remote procedure call (RPC) is when a computer program causes a

procedure to execute in another address space (another computer in a shared
network) which is coded as if it were a local procedure call, without the
programmer explicitly coding the details for the remote interaction.

The programmer write the same code whether the procedure is local or
remote.
Implementing RPC Mechanism
Requirement : To achieve semantic transparency and network transparency
Solution :
Based on the concept of stubs – which provide a perfectly local procedure call
abstraction by concealing from programs the interface to the underlying RPC
system
Based on RPCRuntime : An RPC communication package is used on both the
client and server sides to hide the details of underlying network
Implementation :
It involves the following 5 elements:
1.Client
2.Client stub
3.RPCRuntime
4.Server stub
5.Server
Implementing RPC Mechanism
Client Server

Execute
Return Call Call Return

Client Stub Server Stub

Unpack Pack Unpack Pack

RPCRuntime RPCRuntime
Wait
Receive Send Receive Send

Call Packet
Receive Packet
Implementing RPC Mechanism
Client
•It is a user process that initiates a RPC
•To make a RPC, it makes a perfect local call that invokes a corresponding
procedure in the client stub

Client Stub
Responsible for carrying out the following 2 tasks:
•On receipt of a call request from the client, it packs a specification of the
target procedure and the arguments into a message (Parameter Marshalling)
and then asks the local Runtime to send it to server stub

•On receipt of the result of procedure execution, it unpacks the result and
passes it to the client
Implementing RPC Mechanism
Client Stub
Instead of the code to provide the service, the client machine has a stub
procedure

In general,
•Puts the arguments in a message
•Sends the message to the server
•Waits for the reply message
•Unpacks the results
•Return to the application call
Implementing RPC Mechanism

RPCRuntime (This library consists of a set of routines)

•It handles transmission of messages across the network between client

and server machines
•It is responsible for retransmissions, acknowledgements, packet routing
and encryption
•Also involves with the client finding the server in the distributed system,
getting messages back and forth, managing any state that exists between
requests, and processing any errors that occur.
Implementing RPC Mechanism
Server Stub
Code in the server should be normal, so that it can be used by other
code on the server to provide the same service locally.
Responsible for carrying out the following 2 tasks:
•On receipt of a call request message from the local Runtime, it unpacks it
and makes a normal call to the server
•On receipt of the result of procedure execution, it packs the result and
passes it to the client stub

Server
•On receiving a call request from the server stub, it executes the
procedure and returns to the stub
Steps of RPC
Steps of RPC
Step 7: add executes and returns answer to server stub

Step 8: Server stub composes reply message containing this answet

Step 9: Message is sent across the network

Step 10: Client OS passes reply to client stub

Step 11: Client stub unpacks and return result

Stub Generation

Two ways to generate stubs:

•Manually : RPC implementer provides a set of translation functions from which a user can construct
his/her own stubs – simple

•Automatically : Using Interface Definition Language (IDL)

•Interface definition languages (IDLs) are designed to allow procedures implemented in different
languages to invoke one another. An IDL provides a notation for defining interfaces in which each of the
parameters of an operation may be described as for input or output in addition to having its type
specified.
Stub Generation
When writing a Distributed application :
• A programmer first writes an interface definition using IDL
Example
Identified by
#include <header.h>
unique ID
Specification of file_server, version 3.1 :
long read (in char name[Max_Path], out char buf[Buf_Size], in long bytes, in long position);
long write (in char name[Max_Path], out char buf[Buf_Size], in long bytes, in long position);
int create (in char [Max_Path], in int mode);
int delete (in char [Max_Path]);

The specification is an input to the stub generator, which produces both the client and server stub
Both are put into the appropriate libraries
When a client program calls any of the procedures defined by this spec, the corresponding client
stub procedure is linked into its binary
Stub Generation
Two ways to generate stubs:
•Manually : RPC implementer provides a set of translation functions from which a user can construct
his/her own stubs – simple

•Automatically : Using Interface Definition Language (IDL)

❖ Using IDL to define the interface between a client and a server
❖ A server that provides RPC services defines the available procedures in a service interface
❖ A service interface is generally defined in an IDL, which is a simplified programming language,
sufficient for defining data types and procedure signatures but not for writing executable code
❖ The IDL service interface definition is used to generate client and server stub codes
❖ Also reduces data storage and amount of data transferred – by indicating input and output
arguments
CORBA IDL
The interface named PersonList
specifies the methods available for
RMI in a remote object that
implements that interface.
Ex: Method addPerson specifies its
argument as in, meaning that it is an
input argument, and the method
getPerson that retrieves an instance of
Person by name specifies its second
argument as out, meaning that it is an
output argument.
IDL
The concept of an IDL was initially developed for RPC systems but applies equally to RMI and also
web services.

• Sun XDR as an example of an IDL for RPC

• CORBA IDL as an example of an IDL for RMI
How to Locate the Server?
It is necessary for a client stub to know the location of a server before a RPC can take place between
them
Option 1 : Hardwire the network address of the server into the client - inflexible
Option 2 : Dynamic Binding
•The process by which a client becomes associated with a server so that calls can take place – Dynamic
Binding
• Servers exports the server interface to register their willingness to provide service
• Server sends a message to a binder – registering the server

Call Input Output

Register Name, Version,
Handle, Unique id
The Binder Deregister Name, Version,
Interface Unique id
Lookup Name, Version Handle, Unique id
How to Locate the Server?
Example : Client calls “read”
• The client calls one of the remote procedures for the first time, “read”
• The client stub is not yet bound to a server
• Client sends a message to the binder asking to import ver 3.1 of the
file_server interface
• Binder checks whether server have already exported an interface with this
name and version number
• If there is no server, the call fails
• If suitable server exists, the binder gives its handle and UID to the client stub
• Client uses the handle (address) to send the request message to
• It sends the UID and the parameters
• Server’s kernel sends the request to the correct process
Sun RPC
Sun RPC – provides an interface language called XDR and rpcgen compiler
Interface Definition Language

Used to define a service interface for Sun RPC by specifying a set of procedure definitions

Generation = rpcgen(Interface definition)

1.Client stub procedure
2.Server main, dispatcher and stub procedures
3.XDR marshalling and unmarshalling procedures for use
RPC Client and Server
client process server process
Request

Reply
client stub server stub
procedure procedure
client service
program Communication Communication procedure
module module dispatcher

Implemented over Request-Reply protocol

Client and Server stub procedures and the dispatcher – generated by interface
compiler from the interface definition of the Service
RPC Client and Server
client process server process
Request

Reply
client stub server stub
procedure procedure
client service
program Communication Communication procedure
module module dispatcher

Client :
Includes one stub procedure for each procedure in the service interface
Stub :
Similar to proxy – behaves –local procedure – marshals pid, arguments – unmarshals
RPC Client and Server
client process server process
Request

Reply
client stub server stub
procedure procedure
client service
program Communication Communication procedure
module module dispatcher

Dispatcher:
Selects one of stub procedure according to pid
Stub :
Similar to skeleton –unmarshals pid, arguments – marshals results
Case Study : DCE Only these 3 files are
manually written and
edited by an application
programmer

This file is manually

included in the client
and server code and
automatically included
in the client and server
stub and XDR files using
include

http://www.dcerpc.org/
RPC Messages
Two types of messages involved in the implementation of an RPC system:
• Call Message
• Reply Message
RPC protocol defines the format and interpretation of these messages
Independent of transport protocols

• Call: Sent by the client to the server for requesting execution of a particular
remote procedure
• Reply : Sent by the server to the client for returning the result of remote
procedure execution
RPC Messages
Call Message
Necessary basic components are :
• The identification information of the remote procedure to be executed
• The arguments necessary for the execution
• Sent by the server to the client for returning the result of remote procedure
execution
• Message Type : Call/Reply

Typical RPC Call Message Format

Message Message Client Arguments Remote Procedure Identifier
Identifier Type Identifier
Program Version No Proc No
No
RPC Messages
A Successful Reply Message Format
Message Message Reply Result
Identifier Type Status

An Unsuccessful Reply Message Format

Message Message Reply Reason for
Identifier Type Status Failure
Server Management
In RPC based applications, two important issues that need to be considered are
•Server Implementation
•Server Creation

Server Implementation
Servers may be of two types
• Stateful : It maintains clients’ state information from one RPC to the next
• Stateless : Does not maintain an y client state information.
Server Management
Stateful Server:
Client Server

Open (filename, mode) File Table

Fid, Mode,
return(fid)
R/W ptr
read(fid, 100 buf)
return(bytes 0 to 99)
read(fid, 100 buf)
return(bytes 100 to 199)

Stateful server as it maintains the current state information for a file that has
been opened for use by a client
•Provide an easier programming paradigm – relieves the client from maintaining
state information
•More efficient
Server Management
Stateless Server:

Client Server

File State read(filename, 0,100 buf)

Information
Fid, Mode,
R/W ptr return(bytes 0 to 99)

read(filename, 100,100 buf)

return(bytes 100 to 199)

• In this case, the client has to keep track of the file state information
• Every request from a client must be accompanied with all the necessary
parameters to successfully carry out the desired operation
Server Management
Why Stateless Server ?

• Stateless servers have a distinct advantage over stateful servers in the event
of a failure
• In case of Failure in Stateful
• Stateful server may crash – lost the state information – client is unaware
– result in inconsistent results for the client
• Client crash – server will be holding invalid state information
• The system should be properly designed to detect the crashes
• In case of Failure in Stateless
• Client crash – has to retry a request until the server responds

🡪 The choice is purely application dependent

Server Management
Server Creation
• The remote procedure to be executed in server is totally independent of the
client process
• Independence – client and server have separate life time, normally run on
separate machines
• Server process may either be created and installed before the client process
request or be created on a demand basis
Parameter Passing Semantics
Call by Value
All parameters are copied into a message that is transmitted from the client to
the server through the intervening network

Call by Reference
How are pointers or references passed ?
Generally, it is avoided since client and server exist in different address spaces
One solution : If the client stub knows that a parameters points to an array of
characters and also knows its size,
Client Stub : Copy the array into the message and send it to the server
Server Stub : Stub will call the server with a pointer to this array, even though
the pointer has a different numerical value than the original one
Server : Changes made by server will affect the buffer in server stub

Call by reference 🡪 replaced by copy/restore

Call Semantics
Normal functioning of an RPC may get disrupted due to :
•The call message gets lost
•The response message gets lost
•The callee node crashes and is restarted
•The caller node crashes and is restarted
Failure handling code is generally a part of RPCRuntime

Types of call semantics:

•Possibly or May-be
•Last-one
•Last-of-many
•At-least-once
•Exactly-once
Call Semantics
Possibly or May-be Call Semantics
• This is the weakest and is not really appropriate to RPC
• A timeout mechanism is used to prevent the caller from waiting indefinitely
• Suitable where the response message is not important for the caller

Last-one Call Semantics

• Based on the idea of retransmitting the call message based on the timeouts
until a response is received by the caller (i.e., calling-execution-returning
results)
• The results of the last executed call are used by the caller
• Difficult if involved with more than 2 processors
• May result in orphan calls (whose parent (caller) has expired due to a node
crash)
• Orphan calls must be terminated before restarting the crashed process
Call Semantics
Last-of-Many Call Semantics
• Similar to the last-one semantics with orphan calls neglected
• Use call identifiers to uniquely identify each call and repeated calls
• Each response has the corresponding call identifier
• Caller accepts only if the identifier matches with the most recent call id

At-least-once Call Semantics

• It takes the result of the first response message and ignores the others

Exactly-once Call Semantics

• Most desirable – eliminates the possibility of a procedure being executed
more than once no matter how many times a call is retransmitted