Remote Procedure Call

( csc6320 survey paper )

Yong Li
Dec. 02 2000
Remote Procedure Call 0
!"#$R!C$
Remote Procedure Call (RPC) is a powerful technique for constructing distributed, client/server
based applications. his surve! is to e"plain RPC mechanism, how to use the #un RPC convert
local procedures to remote procedures.
%. &ntroduction to Client'#erver Distri(uted !rc)itecture
$an! modern data processing applications utili%e &distributed computing architecture' in which
a user must access data or service across a networ(. Client/server is a computational architecture
that involves client processes requesting service from server processes. he term client/server
was first used in the )*+0s in reference to personal computers (PCs) on a networ(. he actual
client/server model started gaining acceptance in the late )*+0s. he client/server software
architecture is a versatile, message,based and modular infrastructure that is intended to improve,
usabilit!, fle"ibilit!, interoperabilit!, and salabilit! as compared to centrali%ed, mainframe, time
sharing computing.
he logical e"tension of this is to have clients and servers running on the appropriate hardware
and software platforms for their functions. -or e"ample, database management s!stem servers
running on platforms speciall! designed and configured to perform queries, or file servers
running on platforms with special elements for managing files.
he client is a process (program) that sends a message to a server process (program), requesting
that the server perform a tas( (service). Client programs usuall! manage the user,interface
portion of the application, validate data entered b! the user, dispatch requests to server programs,
and sometimes e"ecute business logic. he client,based process is the front, end of the
application that the user sees and interacts with. he client process contains solution,specific
logic and provides the interface between the user and the rest of the application s!stem. he
Remote Procedure Call )
client process also manages the local resources that the user interacts with such as the monitor,
(e!board, wor(station CP. and peripherals. /ne of the (e! elements of a client wor(station is
the graphical user interface (0.1). 2ormall! a part of operating s!stem i.e. the window manager
detects user actions, manages the windows on the displa! and displa!s the data in the windows.
3 server process (program) fulfills the client request b! performing the tas( requested. #erver
programs generall! receive requests from client programs, e"ecute database retrieval and
updates, manage data integrit! and dispatch responses to client requests. #ometimes server
programs e"ecute common or comple" business logic. he server,based process 4ma!4 run on
another machine on the networ(. his server could be the host operating s!stem or networ( file
server5 the server is then provided both file s!stem services and application services. /r in some
cases, another des(top machine provides the application services. he server process acts as a
software engine that manages shared resources such as databases, printers, communication lin(s,
or high powered,processors. he server process performs the bac(,end tas(s that are common to
similar applications.
3 client is defined as a requester of services and a server is defined as the provider of services.
he client (user s!stem) sends a message to a server requesting the server to perform a tas( or
service. he client programs perform tas(s in the user interface portion of the application. he!
validate data entered b! the user and send the request to the server programs.
he basic characteristics of client/server architectures are6
hese are the common characteristics of client/server architectures
3 client who interacts with the user and a server, which interacts with the resources.
he computing resources needed b! the client and the server li(e memor!, processor
speed, dis( speeds etc. are different.
he hardware platform and operating s!stem of client and server can be heterogeneous
3n important characteristic of client,server s!stems is salabilit!.
Remote Procedure Call 7
8hat is distributed function processing9
he distribution of applications and business logic across multiple processing platforms.
:istributed processing implies that processing will occur on more than one processor in order for
a transaction to be completed. 1n other words, processing is distributed across two or more
machines and the processes are most li(el! not running at the same time, i.e. each process
performs part of an application in a sequence. /ften the data used in a distributed processing
environment is also distributed across platforms. ;ere the split occurs in the application
functionalit!, one part going to the client, other to the server. he underl!ing communications
facilities ma! implement either a message,based or remote procedure call (RPC) mechanism for
transfer of dialog and data.
2. RPC *vervie+
he Remote Procedure Calls (RPC) mechanism is a high,level communications paradigm for
networ( applications. RPC is a powerful technique for constructing distributed, client/server
based applications. 1t is based on e"tending the notion of conventional, or local procedure
calling, so that the called procedure need not e"ist in the same address space as the calling
procedure. he two processes ma! be on the same s!stem, or the! ma! be on different s!stems
with a networ( connecting them.
<! using RPC, programs on networ(ed platforms can communicate with remote (and local)
resources. RPC allows networ( applications to use speciali%ed (inds of procedure calls designed
to hide the details of underl!ing networ(ing mechanisms. he comple"it! involved in the
development of distributed processing is reduced b! (eeping the semantics of a remote call the
same whether or not the client and server are collocated on the same s!stem.
Remote Procedure Call =
he transport independence of RPC isolates the application from the ph!sical and logical
elements of the data communications mechanism and allows the application to use a variet! of
transports.
3. ,o+ RPC -or.s
3n RPC is analogous to a function call. >i(e a function call, when an RPC is made, the calling
arguments are passed to the remote procedure and the caller waits for a response to be returned
from the remote procedure. -igure ) shows the flow of activit! that ta(es place during an RPC
call between two networ(ed s!stems. he client ma(es a procedure call that sends a request to
the server and waits. he thread is bloc(ed from processing until either a repl! is received, or it
times out. 8hen the request arrives, the server calls a dispatch routine that performs the
requested service, and sends the repl! to the client. 3fter the RPC call is completed, the client
program continues. RPC specificall! supports networ( applications.
Remote Procedure Call ?
/igure %. Remote Procedure Calling 0ec)anism
1. RPC !pplication Development
o develop an RPC application the following steps are needed6
#pecif! the protocol for client server communication
:evelop the client program
:evelop the server program
Remote Procedure Call @
he programs will be compiled separatel!. he communication protocol is achieved b! generated
stubs and these stubs and rpc (and other libraries) will need to be lin(ed in.
1.% $)e rpcgen Protocol Compiler
he easiest wa! to define and generate the protocol is to use a protocol compiler such as rpcgen.
rpcgen provides programmers a simple and direct wa! to write distributed applications. rpcgen
does most of the dirt! wor(, allowing programmers to debug the main features of their
application, instead of requiring them to spend most of their time debugging their networ(
interface code.
rpcgen is a compiler. 1t accepts a remote program interface definition written in a language,
called RPC >anguage, which is similar to C. 1t produces a C language output which includes stub
versions of the client routines, a server s(eleton, A:R filter routines for both parameters and
results, and a header file that contains common definitions. he client stubs interface with the
RPC librar! and effectivel! hide the networ( from their callers. he server stub similarl! hides
the networ( from the server procedures that are to be invo(ed b! remote clients. rpcgenBs output
files can be compiled and lin(ed in the usual wa!. he developer writes server procedures ,, in
an! language that observes #un calling conventions ,, and lin(s them with the server s(eleton
produced b! rpcgen to get an e"ecutable server program. o use a remote program, a
programmer writes an ordinar! main program that ma(es local procedure calls to the client stubs
produced b! rpcgen. >in(ing this program with rpcgenBs stubs creates an e"ecutable program.
(3t present the main program must be written in C). rpcgen options can be used to suppress stub
generation and to specif! the transport to be used b! the server stub.
he output of rpcgen is6
3 header file of definitions common to the server and the client
3 set of A:R routines that translate each data t!pe defined in the header file
3 stub program for the server
Remote Procedure Call C
3 stub program for the client
3 time,out for servers (optionall!)
C,st!le arguments passing 32#1 C,compliant code (optionall!)
(optionall!) dispatch tables that the server can use to chec( authori%ations and then
invo(e service routines.
1.2 RPC speci2ication
3 file with a DD."BB suffi" acts as a remote procedure specification file. 1t defines functions that
will be remotel! e"ecuted functions. -unctions are restricted6 the! ma! ta(e at most one in
parameter, and return at most one out parameter as the function result.
1f !ou want to use more than one in parameter, !ou have to wrap them up in a single structure,
and similarl! with the out values.
$ultiple functions ma! be defined at once. he! are numbered from one upward, and an! of
these ma! be remotel! e"ecuted.
he specification defines a program that will run remotel!, made up of the functions. he
program has a name, a version number and a unique identif!ing number (chosen b! !ou).
RPC >anguage #pecification li(es this6
program-def:
"program" identifier "{"
version-def
version-def *
"}" "=" constant ";"

version-def:
"version" identifier "{"
procedure-def
procedure-def *
"}" "=" constant ";"

Remote Procedure Call E
procedure-def:
type-specifier identifier "(" type-specifier ")"
"=" constant ";"
1.3 RPC versions and num(ers
Fach RPC procedure is uniquel! identified b! a program number, version number, and procedure
number.
he program number identifies a group of related remote procedures, each of which has a
different procedure number. Program numbers are given out in groups of he"adecimal 70000000.
0 - 1fffffff defined by un
!0000000 - "fffffff defined by user
#0000000 - $fffffff transient
%0000000 - &fffffff reserved
'0000000 - (fffffff reserved
a0000000 - bfffffff reserved
c0000000 - dfffffff reserved
e0000000 - ffffffff reserved
Fach program also has a version number, so when a minor change is made to a remote service
(adding a new procedure, for e"ample), a new program number does not have to be assigned.
he first implementation of a program will most li(el! have version number ). <ecause most
new protocols evolve into better, stable, and mature protocols, a version field of the call message
identifies the version of the protocol the caller is using. Gersion numbers ma(e spea(ing old and
new protocols through the same server process possible. Gersion numbers are incremented when
functionalit! is changed in the remote program. F"isting procedures can be changed or new ones
can be added. $ore than one version of a remote program can be defined and a version can have
more than one procedure defined.
Remote Procedure Call +
he procedure number identifies the procedure to be called. hese numbers are documented in
the specific programBs protocol specification.
1.1 #tu(s
8hen the calling process calls a procedure, the action performed b! that procedure will not be
the actual code as written, but code that begins networ( communication. 1t has to connect to the
remote machine, send all the parameters down to it, wait for replies, do the right thing to the
stac( and return. his is the client side stub.
he server side stub has to wait for messages as(ing for a procedure to run. 1t has to read the
parameters, and present them in a suitable form to e"ecute the procedure locall!. 3fter e"ecution,
it has to send the results bac( to the calling process.
/igure 2. #tu(s
). he client calls the local stub procedure. he stub pac(ages up the parameters into a
networ( message. his is called marshaling.
Remote Procedure Call *
7. 2etwor(ing functions in the //# (ernel are called b! the stub to send the message.
=. he (ernel sends the message(s) to the remote s!stem. his ma! be connection,oriented
or connectionless.
?. 3 server stub unmarshals the arguments from the networ( message.
@. he server stub e"ecutes a local procedure call.
C. he procedure completes, returning e"ecution to the server stub.
E. he server stub marshals the return values into a networ( message.
+. he return messages are sent bac(.
*. he client stub reads the messages using the networ( functions.
)0. he message is unmarshalled. 3nd the return values are set on the stac( for the local
process.
1.3 Data representation
3 procedure, for e"ample, ma! have a short int, a string and an ordinar! int as parameters. ;ow
is it to be marshaled so that it can be correctl! unmarshaled at the other end9
-or e"ample, the short int could use the first two b!tes with the ne"t two blan(s, or the other wa!
round. he string could be prefi"ed b! its length or be terminated b! a sentinel value. 1f the
length is sent, should it be an int9 3 short int9 he ordinar! int could be big,endian or little,
endian.
he #un RPC uses a standard format called 4DR(e4ternal Data Representation), a protocol for
the machine,independent description and encoding of data. . A:R is an data abstraction needed
for machine independent communication. he client and server need not be machines of the
same t!pe. A:R is useful for transferring data between different computer architectures.
RPC can handle arbitrar! data structures, regardless of different machinesB b!te orders or
structure la!out conventions, b! alwa!s converting them to A:R representation before sending
Remote Procedure Call )0
them over the wire. he process of converting from a particular machine representation to A:R
format is called serializing, and the reverse process is called deserializing.
Galid data t!pes supported b! A:R include6
int
unsigned int
)ong
enum
boo)
f)oat
doub)e
typedef
structure
fi*ed array
string (nu)) terminated c+ar *)
3. Converting Local Procedures into Remote Procedures
3ssume an application that runs on a single machine. #uppose we want to convert it to run over
the networ(. ;ere we will show such a conversion b! wa! of a simple e"ample program that
calculates pi.
o declare a remote procedure, first, determine the data t!pes of all procedure,calling arguments
and the result argument. he calling argument of calcuHpi () is a void, and the result is a double.
8e can write a protocol specification in RPC language that describes the remote version of
calcuHpi. he RPC language source code for such a specification is6
,* pi-*: .emote pi ca)cu)ation protoco) *,
program /0/.12 {
version 345367/089. {
doub)e 345367/0() = 1;
} = 1;
} = 0*"('&%$#";
Remote Procedure Call ))
Remote procedures are alwa!s declared as part of remote programs. he code above declares an
entire remote program that contains the single procedure C3>C.HP1.
1n this e"ample,
C3>C.HP1 procedure is declared to be6
the procedure ),
in version ) of the remote program
P1PR/0, with the program number 0*"('&%$#".
2otice that the program and procedure names are declared with all capital letters. his is not
required, but is a good convention to follow.
o compile a ." file using
rpcgen a C pi.x
where6 option Ia tells rpcgen to generate all of the supporting files
option IC indicates 32#1 C is used
his will generate the files6
piHclnt.c ,, the client stub
piHsvc.c ,, the server stub
pi.h ,, the header file that contains all of the A:R t!pes generated from the specification
ma(efile.pi ,, ma(efile for compiling all of the client and server code
piHclient.c ,, client s(eleton, need to be modified
piHserver.c I server s(eleton, need to be modified
#un RPC supports the passing of onl! a single parameter and the return of onl! a single result. 1f
more than one argument is required, the arguments must be passed in a struct. rpcgen ma! also
be used to generate A:R routines, i.e., the routines necessar! to convert local data structures into
A:R format and vice,versa.
Remote Procedure Call )7
he following e"ample a remote adding and subtracting two integers service, built using rpcgen
not onl! to generate stub routines, but also to generate the A:R routines.
,** simp-*
* t+e definition of t+e data type t+at :i)) be passed to
* bot+ of t+e remote procedures add() and sub()
*,
struct operands {
int *;
int y;
};
,* program; version and procedure definitions-
*,
program 0</7/.12 {
version 0</789.01= {
int 4>>(operands) = 1;
int 6?(operands) = !;
} = 1;
} = 0*!'(&%$#";
Running rpcgen on simp.x not onl! creates the header file, client stub routines and server
s(eleton. 1t also creates the A:R routines necessar! for converting instances of declared data
t!pes from host platform representation into A:R format, and vice,versa. hese routines are
output in the file simp_xdr.c.
2ow, we come bac( the first e"ample. here are Just two more files to modif!6
the remote procedure itself, piHserver.c
the main client program that calls it, piHclient.c
;ereBs one possible definition of a remote procedure to implement the C3>C.HP1 procedure we
declared previousl!6
/*
* pi_server.c: implementation of the remote procedure "calcu_pi"
*
* The formula is:
* (pi / 4) = 1 - 1/ ! 1/" - 1/# ...
*/
Remote Procedure Call )=
@inc)ude Arpc,rpc-+B /* al$a%s needed */
@inc)ude "pi-+" /* &enerated '% rpc&en compiler */
/** (emote verson of "calcu_pi" */
doub)e * ca)cu7pi717svc(void *argp; struct svc7reC *rCstp){
static doub)e pi;
doub)e sum = 0;
int i;
int sign;
for (i=1; iA10000000; iDD ){
sign = (iD1) E !;
if ( sign == 0 )
sign = 1;
e)se
sign = -1;
sum D= 1 , (!*(doub)e)i -1) * (doub)e)sign;
}
pi = # * sum;
return (Fpi);
}
2otice that the declaration of the remote procedure calcuHpiH)() differs from that of the local
procedure in several wa!s6
1t alwa!s ta(es pointers to their arguments instead of arguments themselves. his is true of all
remote procedures.
1t returns a pointer to a double instead of a double itself. his is also generall! true of remote
procedures6 the! alwa!s return a pointer to their results.
1t has an DH)B appended to its name. 1n general, all remote procedures called b! DrpcgenB are
named b! the following rule6 the name in the program definition (here DC3>C.HP1B) is
converted to all lower,case letters, an underbar (DHB) is appended to it, and finall! the version
number (here D)B) is appended.
8hen rpcgen is used, it is essential to have result (in this e"ample) declared as static. 1n the
code generated b! rpcgen, the result address is converted to A:R format after the remote
procedure returns. 1f the result were declared local to the remote procedure, references to its
address would be invalid after the remote procedure returned. #o the result must be declared
static when rpcgen is used.
Remote Procedure Call )?
he last thing to do is declare the main client program that will call the remote procedure. ;ere
is one possibilit!6
/** pi_client.c) remote version of client pro&ram
*/
@inc)ude Astdio-+B
@inc)ude Arpc,rpc-+B /* al$a%s needed */
@inc)ude "pi-+" /* &enerated '% rpc&en*/
main(int argc; c+ar *argvGH)
{
3509=I *c)nt;
doub)e *resu)t71;
c+ar *+ost;
c+ar * ca)cu7pi717arg;

/* must have t$o ar&uments) includin& server host name */
if (argc A !) {
printf("usage: Es server7+ostJn"; argvG0H);
e*it(1);
}
+ost = argvG1H; /* server host name */

/** *reate client "handle" used for callin& +,+(-.
* on the server desi&nated on the command line.
*/
c)nt = c)nt7create(+ost; /0/.12; 345367/089.; "tcp");
if (c)nt == (3509=I *) =655) {
/* *ouldn/t esta'lish connection $ith server
* +rint error messa&e and die.
*/
c)nt7pcreateerror(+ost);
e*it(1);
}
/* call remote procedure on the server side */
resu)t71 = ca)cu7pi71((void *)Fca)cu7pi717arg; c)nt);
if (resu)t71 == (doub)e *) =655) {
/** 0n error occurred $hile callin& the server.
* +rint error messa&e and die.
*/
c)nt7perror(c)nt; "ca)) fai)ed");
e*it(1);
}
/** -1a%) $e successfull% called the remote procedure.
* print the pi value
*/
Remote Procedure Call )@
printf("/0 is EfJn" ; *resu)t71);
c)nt7destroy(c)nt);
e*it(0);
}
here are four things to note here6
-irst a client handle is created using the RPC librar! routine clntHcreate(). his client handle
will be passed to the stub routines that call the remote procedure.
he last parameter to clntHcreate() is DDtcpBB.
he remote procedure calcuHpiH)() is called e"actl! the same wa! as it is a local procedure
e"cept for the inserted client handle as the second argument. 1t also returns a pointer to the
result instead of the result itself.
he remote procedure call can fail in two wa!s. he RPC mechanism itself can fail or,
alternativel!, there can be an error in the e"ecution of the remote procedure. 1n the former
case, the remote procedure returns with a 2.>>. 1n the later case, however, the details of
error reporting are application dependent. ;ere, the error is being reported via Kresult.
;ereBs how to compile the programs6
$ rpcgen C a pi.x
$ gcc pi_client.c pi_clnt.c -o pi_client -lnsl
$ gcc pi_server.c pi_svc.c -o pi_server lnsl
wo programs are compiled here6 the client program pi5client and the server program pi5server.
/nce created, the server should be copied to a remote machine and run. (1f the machines are
homogeneous, the server can be copied as a binar!. /therwise, the source files will need to be
copied to and compiled on the remote machine.) -or this e"ample, the remote machine is called
remote and the local machine is called local. he server is started from the shell on the remote
s!stem6
remoteK pi7server
hereafter, a user on local can calculate pi as follows6
)oca)K pi7c)ient remote
Remote Procedure Call )C
1n summar!, follow these steps in converting local calls to remote calls6
0et the program to wor( using local functions.
Restructure each functions so it has onl! one parameter which is passed b! values, and be
sure that it wor(s when called locall!,
Create a specification file having a ." e"tension.
Call repgen with the Ia and IC options to generate a complete set of files.
$odif! the calling program generated b! rpcgen ( Hclient.c ).
$odif! the server program generated b! rpcgen( Hserver.c ).
Compile the modified filed lin(ing with the stub files.
Put server file on the remote machine and run.
Run client file on local machine.
6. Conclusion
#un rpcgen is a ver! powerful compiler. 1t can provide programmers a simple and direct wa! to
write distributed applications. rpcgenB reduces development time that would otherwise be spent
coding and debugging low,level routines. #ince #un RPC supports the passing of onl! a single
parameter and the return of onl! a single result. 1f more than one argument is required, the
arguments must be passed in a struct. Programmers should pa! more attention on this restriction.
Remote Procedure Call )E
3PPF:1A
,** simp-*
* t+e definition of t+e data type t+at :i)) be passed to
* bot+ of t+e remote procedures add() and sub()
*,
struct operands {
int *;
int y;
};
,* program; version and procedure definitions-
*,
program 0</7/.12 {
version 0</789.01= {
int 4>>(operands) = 1;
int 6?(operands) = !;
} = 1;
} = 0*!'(&%$#";
,* simp7server-c; definition of t+e remote add and subtract procedure used by
* simp)e ./3 e*amp)e
* rpcgen :i)) create a temp)ate for you t+at contains muc+ of t+e code
* needed in t+is fi)e is you give it t+e "-s" command )ine arg-
*,
@inc)ude "simp-+"
,* Lere is t+e actua) remote procedure *,
,* I+e return va)ue of t+is procedure must be a pointer to intM *,
,* :e dec)are t+e variab)e resu)t as static so :e can return a
pointer to it *,
int *
add717svc(operands *argp; struct svc7reC *rCstp)
{
static int resu)t;
printf("2ot reCuest: adding Ed; EdJn"; argp-B*; argp-By);
resu)t = argp-B* D argp-By;
return (Fresu)t);
}
int *
sub717svc(operands *argp; struct svc7reC *rCstp)
{
static int resu)t;
Remote Procedure Call )+
printf("2ot reCuest: subtracting Ed; EdJn"; argp-B*; argp-By);
resu)t = argp-B* - argp-By;
return (Fresu)t);
}
,* simp7c)ient-c ./3 c)ient for simp)e addition and subtraction e*amp)e *,
@inc)ude Astdio-+B
@inc)ude "simp-+" ,* 3reated for us by rpcgen - +as everyt+ing :e need M *,
,* Nrapper function taOes care of ca))ing t+e ./3 procedure *,
int add( 3509=I *c)nt; int *; int y) {
operands ops;
int *resu)t;
,* 2at+er everyt+ing into a sing)e data structure to send to t+e server *,
ops-* = *;
ops-y = y;
,* 3a)) t+e c)ient stub created by rpcgen *,
resu)t = add71(Fops;c)nt);
if (resu)t===655) {
fprintf(stderr;"Iroub)e ca))ing remote procedureJn");
e*it(0);
}
return(*resu)t);
}
,* Nrapper function taOes care of ca))ing t+e ./3 procedure *,
int sub( 3509=I *c)nt; int *; int y) {
operands ops;
int *resu)t;
,* 2at+er everyt+ing into a sing)e data structure to send to t+e server *,
ops-* = *;
ops-y = y;
,* 3a)) t+e c)ient stub created by rpcgen *,
resu)t = sub71(Fops;c)nt);
if (resu)t===655) {
fprintf(stderr;"Iroub)e ca))ing remote procedureJn");
e*it(0);
}
return(*resu)t);
}
int main( int argc; c+ar *argvGH) {
3509=I *c)nt;
Remote Procedure Call )*
int *;y;
if (argcM=#) {
fprintf(stderr;"6sage: Es +ostname num1 numJn";argvG0H);
e*it(0);
}
,* 3reate a 3509=I data structure t+at reference t+e ./3
procedure 0</7/.12; version 0</789.01= running on t+e
+ost specified by t+e 1st command )ine arg- *,
c)nt = c)nt7create(argvG1H; 0</7/.12; 0</789.01=; "udp");
,* <aOe sure t+e create :orOed *,
if (c)nt == (3509=I *) =655) {
c)nt7pcreateerror(argvG1H);
e*it(1);
}
,* get t+e ! numbers t+at s+ou)d be added *,
* = atoi(argvG!H);
y = atoi(argvG"H);
printf("Ed D Ed = EdJn";*;y; add(c)nt;*;y));
printf("Ed - Ed = EdJn";*;y; sub(c)nt;*;y));
return(0);
}
Remote Procedure Call 70