1
Distributed Program
Generation (rpcgen Example)
Chuan-Ming Liu
CSIE,NTUT
Spring ’04,TAIWAN
2
Introduction
Presents the sequence of steps a
programmer takes to first create a
conventional program and then divide the
program into local and remote components
Uses an example application to show the
output from rpcgen and additional code
required to create the client and server
components of a distributed program that
uses RPC
3
An Example to Illustrate Rpcgen
An example will clarify how rpcgen works
and will illustrate most of the details
To explain how rpcgen works,we have
selected an extremely simple application
4
Dictionary Operations
Consider an application that implements a
simple database that offer 4 basic
operations,initialize,insert,delete,and
lookup
Assume that input to the application is a
text file,where each line contains a one-
letter command followed by a word
Fig,23.1 lists the commands,and gives the
meaning of each
6
Steps to Distributed
Application
Fig,22.6
1,Build a conventional application
2,Divide the program into two parts
3,Create an rpcgen specification
4,Run rpcgen to generate 4 source code
files
5,Write stub interface procedures
6,Compile and link the client program
7,Compile and link the server program
8,Start the server and execute the client
8
Step 1,Build a Conventional
Application Program
An application program (dict.c) for the
dictionary problem written in C
To produce an executable binary for the
application,the programmer invokes the C
compiler to produce an executable file
named dict:
cc –o dict dict.c
9
Step 2,Divide the Program
into Two Parts
Fig,23.2 shows the procedure call graph
for the original,conventional programs that
solves the dictionary problem
A call graph represents a program’s
procedural organizations
When considering which procedures can be
moved to a remote machine,the
programmer must consider the facilities
that each procedure needs
11
Step 2,Divide the Program
into Two Parts (cont.)
Procedures that perform I/O,e.g.,nextin,or
otherwise access file descriptors cannot be
moved to a remote machine easily
Procedures should execute on the same
machine as the data they access; passing
large data structures as arguments to remote
procedures is inefficient
Thus,procedures initw,insertw,deletew,
and lookup belong on the same machine as
the dictionary itself
12
Step 2,Divide the Program
into Two Parts (cont.)
Fig,23.3 illustrates the new structure of the
dictionary application with the data for the
dictionary and access procedures moved to
a remote machine
The programmer must consider the
arguments that each remote procedure will
require along with the cost of passing that
information across a network
The diagram helps the programmer assess
how network delays will affect program
performance
15
Step 2,Divide the Program
into Two Parts (cont.)
The compiler checks for problems like
symbolic constant referenced by both parts,
and the linker checks to see that all data
structures have been collected together
with the procedures that reference them
Catching such problems early (i.e.,before
additional code has been inserted) makes
them easier to repair
16
Step 3,Creating an Rpcgen
Specification
The specification file contains:
declaration for constants used in the client or,
more often,in the server (remote program)
declaration of data types used (especially in
arguments to remove procedures)
declarations of remote programs,the
procedures contained in each program,and the
types of their parameters
17
Step 3,Creating an Rpcgen
Specification (cont.)
All specifications must be given in the RPC
programming,not C
Code rdict.x illustrates an rpcgen
specification for the RPC version of the
dictionary program:
It only defines those constants and types
shared across the client and server or needed to
specify arguments
Following suggested conventions,the
specification file uses upper case names to
define procedures and programs to avoid name
conflicts
18
Step 4,Run Rpcgen
After the specification has been completed,
the programmer runs rpcgen to check for
syntax errors and generate 4 files of code
On Linux,the command syntax is
rpcgen rdict.x (rdict.x is from Step 3,
Creating an Rpcgen Specification)
20
The,h File Produced by
Rpcgen
File rdict.h contains valid C declarations
for any constants and data types declared in
the specification file
21
The XDR Conversion File
Produced by Rpcgen
Fig,23.5 contains calls to conversion
routines for the data types declared in the
dictionary program
22
Figure 23.5
/*
* Please do not edit this file.
* It was generated using rpcgen.
*/
#include "rdict.h"
bool_t
xdr_example (XDR *xdrs,example *objp)
{
register long *buf;
if (!xdr_int (xdrs,&objp->exfield1))
return FALSE;
if (!xdr_char (xdrs,&objp->exfield2))
return FALSE;
return TRUE;
}
23
The Client Code Produced
by Rpcgen
File rdict_clnt.c is an example of the client
stub that rpcgen produces
24
The Server Code Produced
by Rpcgen
File rdict_svc.c is an example server stub
that rpcgen produces
25
Step 5,Write Stub Interface
Procedures
Require client-side and serve-side interface
routines after rpcgen producing the files
One interface procedure for each remote
procedure in the remote program
26
Client-Side Interface
Original application using the same
procedure names and corresponding
arguments to call the procedures
Each procedure interface must convert its
arguments to the form used by rpcgen and
call the corresponding procedure in the
client-side communication routine
All procedures produced by rpcgen use
indirection
27
Server-Side Interface
Accepts calls from the communication
stubs
Pass control to the procedure
Translate the argument type
correctly – indirection
28
Step 7,Compile and Link
Little work on modifying the original
program to have it fit into the distributed
programs
29
Step 8,Start and Execute
The last step to perform.
Try on localhost and then migrate to a real
environment
Use the make utility