Remote Procedure Calls

In order to understand this section, a general understanding of procedure calls is needed. A remote procedure call (RPC) invokes a procedure on a remote system. The reason we call this a ‘procedure call’ is because the intent is to make it appear to the programmer that a normal procedure call is taking place (Stevens, p. 692). Figure 2 is the RPC model (Stevens, p. 693).

Why would someone want to execute a procedure on another person's machine?
The following scenario is realistic. A caller in Ottawa wants to insert a tuple into an Oracle database in Nashville and has no local installation of Oracle. A client could call a remote procedure to do the job. Provided the remote machine has a valid installation of Oracle, an insertion could be accomplished. A Server RPC could be set up in Nashville to accept an SQL statement from the client, execute it, then return the result.

Unfortunately RPCs are subject to the same idiosyncrasies of regular procedure calls and the same network problems mentioned in the socket section. RPC's essential concept is hiding all the network code in the stub procedures. The goal of the RPC is to make the writing of distributed applications easier (Stevens, p. 694). RPC transparency allows such; however, these transparencies raise other problems.

Transparency Issues (Stevens, p. 695):

• Parameter passing - True pass-by-reference is not permitted. Pass-by-copy/restore simulates this. Also, it is very difficult to send and make sense of complex data types such as user defined types.
• Binding - finding the remote host, finding the correct server process.
• Exception Handling - Client or server crash detection.
• Call Semantics - How many times has the procedure actually executed? At least once and at most once semantics are available.
• Data Representation - Different machine architectures implement data in different formats (ie. little endian VS big endian).
• Performance - Usually the performance loss in RPCs VS regular procedure calls is a factor of ten.
• Security - Remember, RPCs are usually executed across networks and the data is subject to public scrutiny.

Other Issues

To make programming even easier, Sun RPC offers a program called rpcgen, which takes a specification of a remote procedure and converts it to C programs containing all the network information to process the request. The programmer simply has to fill in the implementation of the actual procedure. Once again, all the network details are hidden.

Below are examples of remote procedure calls as implemented on hercules and the Dec stations at the University of Regina. The hand coded RPC is an example of a limiting rsh program, allowing one machine to remotely execute a command on another. Hercules includes a rpcgen program which is an automatic RPC generator. This is also illistrated below. The automatically generated RPC returns the date of the remote machine (Stevens, p. 702).

Hand Coded remote shell Remote Procedure Call

This is a remote shell server. Remeber to restrict access to server for your own protection.

This program was tested on hercules and dec5kd on Oct 8/96.

"rpcclient.c" : RPC Client
"rpcserver.c" : RPC Server
"hcrpc.h" : RPC .h File Common To Both

Automatically Generated Remote Procedure Call

• The first example retrieves the date on the server and prints it out on the client.

"date.x" : Function Specification Source Code. Usage: rpcgen date.x
"date_proc.c" : Remote Date Server Functions
"date_svc.c" : Remote Date Server Stub Generated By rpcgen
"date_clnt.c" : Remote Date Client Stub Generated By rpcgen
"rpcclient.c" : Remote Date Client -- Calls Remote Date Server
"date.h" : .h file common to above 4 files. Generated by rpcgen.


Notes: Compile the client on hercules and the server on the dec stations. The reason for this is that RPCGEN has not been installed on the Dec stations. Remember that for the RPCGEN generated code you must replace the bzero command with memset to compile the server on the Dec stations. This is because the bstring library that includes bzero has not been installed on the dec stations.

The client was tested on hercules on Oct 8/96.

The server was tested on hercules and dek5kd on Oct 8/96.

Server:
#!/bin/csh
cc -o date_svc date_proc.c date_svc.c


Client:
#!/bin/csh
cc -o rdate rdate.c date_clnt.c


• The second example calls getutent on the server to get information about who is logged in (similar to the who command). The server saves this info in a linked list and returns the linked list to the client. The client then prints out the info. Because the libraries for getutent are not installed on the dec stations you must compile and run both the server and client on hercules.

"mywho.x" : Function Specification Source Code. Usage: rpcgen mywho.x
"mywho_proc.c" : Remote Who Server Functions
"mywho_svc.c" : Remote Who Server Stub Generated By rpcgen
"mywho_clnt.c" : Remote Who Client Stub Generated By rpcgen
"mywho_xdr.c" : Remote Who XDR data conversion routines Generated by rpcgen
"mywho.c" : Remote Who Client -- Calls Remote Who Server
"mywho.h" : .h file common to above 5 files. Generated by rpcgen.


Notes: Compile the client and server on hercules. The reason for this is that the command getutent() has not been installed on the Dec stations. This is the command to retrieve user information like who is logged on to what terminal etc.

The client and server was tested on hercules on Oct 8/96.

Server:
#!/bin/csh
cc -o mywho_svc mywho_proc.c mywho_svc.c mywho_xdr.c


Client:
#!/bin/csh
cc -o mywho mywho.c mywho_clnt.c mywho_xdr.c

Remember, the rpcgen RPC will only work on hercules !