Remote Procedure Calls

A thorough introduction to RPC for programmers of distributed systems.
Review of Network Programming Theory

In order to complete our picture of RPC processing, we'll need to review some network programming theory.

In order for two processes running on separate computers to exchange data, an association needs to be formed on each host. An association is defined as the following 5-tuple: {protocol, local-address, local-process, foreign-address, foreign-process}

The protocol is the transport mechanism (typically TCP or UDP) which is used to move the data between hosts. This, of course, is the part that needs to be common to both host computers. For either host computer, the local-address/process pair defines the endpoint on the host computer running that process. The foreign-address/process pair refers to the endpoint at the opposite end of the connection.

Breaking this down further, the term address refers to the network address assigned to the host. This would typically be an Internet Protocol (IP) address. The term process refers not to an actual process identifier (such as a Unix PID) but to some integer identifier required to transport the data to the correct process once it has arrived at the correct host computer. This is generally referred to as a port. The reason port numbers are used is that it is not practical for a process running on a remote host to know the PID of a particular server. Standard port numbers are assigned to well known services such as TELNET (port 23) and FTP (port 21).

RPC Call Binding

Now we have the necessary theory to complete our picture of the RPC binding process. An RPC application is formally packaged into a program with one or more procedure calls. In a manner similar to the port assignments described above, the RPC program is assigned an integer identifier known to the programs which will call its procedures. Each procedure is also assigned a number that is also known by its caller. ONC RPC uses a program called portmap to allocate port numbers for RPC programs. It's operation is illustrated in Figure 2. When an RPC program is started, it registers itself with the portmap process running on the same host. The portmap process then assigns the TCP and/or UDP port numbers to be used by that application.

Figure 2. Portmap Operation

The RPC application then waits for and accepts connections at that port number. Prior to calling the remote procedure, the caller also contacts portmap in order to obtain the corresponding port number being used by the application whose procedures it needs to call. The network connection provides the means for the caller to reach the correct program on the remote host. The correct procedure is reached through the use of a dispatch table in the RPC program. The same registration process that establishes the port number also creates the dispatch table. The dispatch table is indexed by procedure number and contains the addresses of all the XDR filter routines as well as the addresses of the actual procedures.

RPCGEN: The Protocol Compiler

Listing 1. Source for avg.x

If the discussion of the mechanisms supporting RPC sounds complex, that's because it is. Fortunately, the development of RPC applications can be greatly simplified through the use of rpcgen, the protocol compiler. rpcgen has its own input language which is used to declare programs, their procedures and the data types for the procedures' parameters and return values. This is best illustrated by an example. The source code for an average procedure is shown in Listing 1. If we store this source code in a file called avg.x and invoke rpcgen with the following command:

rpcgen avg.x

Obtain the header file avg.h shown in Listing 2. This file contains all of the function prototypes and data declarations needed for the development of our application. It will also generate three other source files:

  1. avg_clnt.c: the stub program for our client (caller) process

  2. avg_svc.c: the main program for our server (callee) process

  3. avg_xdr.c: the XDR routines used by both the client and the server

These sources are to be used “as is” and must not be edited.

Listing 2. Header File avg.h

To complete the application at the server end, we need code to provide the actual “smarts” required to correctly process the input data. This must be created manually. The code for the sample application presented here is shown in Listing 3. This code takes the XDR decoded array from the client and separates and averages the values. It returns the result which is then XDR encoded for transmission back to the client.

Listing 3. Server Code for Average Application

To complete the application at the client end, the input data must be packed into XDR format, so that it can be sent to the server. The client program is also generated manually and is shown in Listing 4. The Makefile shown in Listing 5 can be used to build the application.

Listing 4. Client Code for Average Application

Listing 5. Makefile

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

RPC

Anonymous's picture

What is difference between RPC in Windows and that of LINUX?

the steps and content are

Anonymous's picture

the steps and content are good..but if clear picture about the running RPC if given would have been very useful...any how thank u all the information about RPC...

About Version

Ravi Khadgi's picture

I'm little bit confused with the version. If we make any changes to our program, then how we update the version. Can anyone give an example for this?
You can take the following example:
version 1: adds two floating point numbers and returns floating point result
version 2(updated): returns the rounded value

regarding the rpc

Anonymous's picture

Thanks a lot for the article that you have presented. It was a lot of information. I would like to know is there any standard rpc mechanism to know about the services running over a particular machine. I need such a program to know about the processes running on a particular machine. It would be great to have your feedbacks regarding the same.

Works between ARM linux and x86 linux

Anonymous's picture

Hi,

Thanks for posting the code. I tested it with server on arm-linux (Stargate xbow) and client on x86 linux. Cross compiling the code for arm-linux( just the server side files) and running /sbin/portmap on stargate will allow the rpc to register.

The program works well for C and C++ as well.

How to get ravg.c file...the

Bhupesh Chawda's picture

How to get ravg.c file...the makefile has no rule to get it...please excuse me if its a silly question..thanx

ravg.c is the code from

gigi's picture

ravg.c is the code from listing 4
avg_proc.c is the code from listing 3

The code works

Tushar's picture

It is really very useful. I am a new comer in Unix [Linux], and could develop a server/client application on RPC using this code. Thank you, Ed.

I've been reading up on RPC

South Aussie's picture

I've been reading up on RPC to implement it for our project, but this is the first tutorial I've found that presents it in a clear and readable manner and where the example code actually WORKS.
Thanks for a well written article, I wish there were more like it.

good introduction, with working program..

prashant's picture

1) link of tutorial on makefile will add its value..
i find this a good one

http://www.eng.hawaii.edu/Tutor/Make/index.html

2)while excuting makefile "/n" creates problem.. i have deleted it from makefile and necessary file got generated..
3) try running server by ./avg_ser
and by client by ./ravg in seperate terminal..
4) i feel strongly that comment should be provided in avg_proc.c,ravg.c..
at last i am much thankful for this exceptionaly simple running tutorial..

Re: Remote Procedure Calls

Anonymous's picture

Thanks a lot. I'm a chilean engineering student and your article has been very useful for me since it explain very clearly what RPCs are and what are they used for.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState