Building an RPC application

1
Building an RPC application

• Lecture 11

2
Ways to Use RPC Applications

• Program specification
• Both program specification and as abstraction in
  design
• Conceptual design
• Design and implementation (software from
  scratch)?
• Design and implementation (using libraries/etc)?
• Automated implementation

3
Programming Mechanisms to Support RPC

• Rarely will anyone build an RPC application by
  hand!
• Use of the following tools
• XDR library routines to convert data back and
  forth
• XDR library routines to format complex data
• RPC runtime library to call remote procedure
• RPCGEN!
• Usually a programmer will build and test a
  program
• then, split it into a client piece and a server
  piece
• then, run rpcgen to build additional code
• then, compile all together in 2 separate programs

4
Dividing a Program

• Working program
• Basically, RPC will replace a local function call
  with a socket call
• Need to write working program to support RPC
• no passing of file descriptors
• no use of global variables between client/server
• must have functions broken down to support either
  client or server

.............
5
Stub Procedures

• Additional procedures added to both client and
  server code
• Basically
• Server stub replaces the receiving of the call
• Client stub replaces the calling procedure
• This allows the programs to compile and not know
  about the fact that the function is no longer

.............
stub routines
6
Multiple Remote Procedures

• Rare is it that there is only 1 call, usually
  many
• Remember that RPC calls are functions, and if
  there are may 'types' of functions, there are
  many RPC calls
• RPC calls do not maintain state, they are simple
  iterative I/O calls through a dispatcher
• Dispatcher responsible to confront problem of
  rendezvous

7
RPCGEN RPC Generator (source code)?

• rpcgen used to create stub procedures, common
  code
• Much of RPC code is somewhat static, so routine
  is fairly straight forward
• Programmer needs to create specification file
  for rpcgen to run
• rpcgen will create output files for use in
  compiling

8
Stub Types

• Communication stub deals with RPC functions
• created from rpcgen
• can be modified by user (remember that it is only
  source code)?
• Interface Stub link between original code and
  communication stub
• created by programmer
• map between original call and new communication
  stub call

9
Rpcgen I/O

• Need to create a specification file
• e.g. Q.x
• rpcgen will run with the specification file as an
  argument
• Output files
• Q.h header file common to all compiled code
• Q_xdr.c XDR conversion and marshaling routines
• Q_clnt.c Client side communication stub
• Q_svc.c Server side communication stub

10
Rpcgen
11
8 Steps to a Distributed Application

• Build a conventional application (and test!)?
• Divide the program by choosing a set of
  procedures
• Write an rpcgen specification for the remote
  program
• Run rpcgen to check the specification and
  generate source code
• Write stub interface routines
• Compile and link client and server applications
• Start the server, then client(s)?

12
Step 1 Build a Conventional Program

• Knowing that you will be breaking the application
  apart
• Determine which functions are needed for server
  and which for client
• Do not pass pointers between what will be client
  to server functions
• Do not pass file descriptors between client and
  server functions
• Do not use shared globals/memory (process memory,
  shared memory is ok)?
• Once complete, test your application, now is the
  time!

13
Step 2 Divide Program into Client and Server

• Simply break apart program so that the main from
  the original code becomes the client
• Basically
• Main code client functions in 1 file
• All other functions in server file
• NOTE no main function in server file rpcgen
  will create
• When creating files, don't worry about things
  compiling/linking/running yet, not in that state
  yet......

14
Step 3 Write rpcgen Specification File .x

• Simply create a file with the following
  information
• Constants
• Any structures to be passed (rpcgen will create
  XDR representations of these data types)?
• Labels for
• Program (number)?
• with procedures embedded in XDR language
• e.g. int INSERTW(string) 2 / second proc /
• Version (number)?
• NOTE this is the only place any new form of
  language will appear!

15
Step 4 Run rpcgen

• One argument specification file
• Will validate specification file
• Source code created
• .h header file
• _xdr.c xdr conversion (communication) routines
• _clnt.c client communication stub
• _svc.c server communication stub
• NOTE. the name of the specification file
  (denoted by the characters before the '.x', will
  be the names of the new files.

16
Step 5 Write Client Stub Interface Routines

• Will need to create both client and server side
  interface routines
• Simply wrapper code so you don't need to change
  original code
• Notice that when the client calls insertw(char
  word), this function is now a wrapper to
  insertw_1(arg, handle)?
• NOTE arg is a pointer to a pointer, handle is a
  global handle pointer used for RPC calls

17
Step 5 Write Server Stub Interface Routines

• Same idea as client, but backwards
• RPC mechanisms will call functions like
• insertw_1_svc
• These need to be translated to real calls!!!
• Again, the same wrapping of code
• Notice the value passed into insertw_1_svc is a
  pointer to a pointer, but when passed to real
  function it needs more indirection
• insertw((char )w)

18
Step 67 Compile and Link Programs

• Use of -c option to simply compile, but not link
  to start
• NOTE Can only compile source / libraries to
  run if there is only 1 main() function!!!
• Will need to compile each .c file by itself and
  have the .o files available for final linking
• Final compile will actually link all of the .o
  files together

19
Step 8 Run Programs

• Server will run as a daemon
• quick way to start is to run in it's own window,
  or use the '' character at the end of the
  command to put it in the process background
• NOTE does not make it a daemon!!
• Clients can connect from anywhere...