Remote Procedure Calls

A thorough introduction to RPC for programmers of distributed systems.

As any programmer knows, procedure calls are a vital software development technique. They provide the leverage necessary for the implementation of all but the most trivial of programs. Remote procedure calls (RPC) extend the capabilities of conventional procedure calls across a network and are essential in the development of distributed systems. They can be used both for data exchange in distributed file and database systems and for harnessing the power of multiple processors. Linux distributions provide an RPC version derived from the RPC facility developed by the Open Network Computing (ONC) group at Sun Microsystems.

RPC and the Client/Server Model

In case the reader is not familiar with the following terms, we will define them here since they will be important in later discussion:

  • Caller: a program which calls a subroutine

  • Callee: a subroutine or procedure which is called by the caller

  • Client: a program which requests a connection to and service from a network server

  • Server: a program which accepts connections from and provides services to a client

There is a direct parallel between the caller/callee relationship and the client/server relationship. With ONC RPC (and with every other form of RPC that I know), the caller always executes as a client process, and the callee always executes as a server process.

The Remote Procedure Call Mechanism

In order for an RPC to execute successfully, several steps must take place:

  1. The caller program must prepare any input parameters to be passed to the RPC. Note that the caller and the callee may be running completely different hardware, and that certain data types may be represented differently from one machine architecture to the next. Because of this, the caller cannot simply feed raw data to the remote procedure.

  2. The calling program must somehow pass its data to the remote host which will execute the RPC. In local procedure calls, the target address is simply a machine address on the local processor. With RPC, the target procedure has a machine address combined with a network address.

  3. The RPC receives and operates on any input parameters and passes the result back to the caller.

  4. The calling program receives the RPC result and continues execution.

External Data Representation

As was pointed out earlier, an RPC can be executed between two hosts that run completely different processor hardware. Data types, such as integer and floating-point numbers, can have different physical representations on different machines. For example, some machines store integers (C ints) with the low order byte first while some machines place the low order byte last. Similar problems occur with floating-point numeric data. The solution to this problem involves the adoption of a standard for data interchange.

One such standard is the ONC external data representation (XDR). XDR is essentially a collection of C functions and macros that enable conversion from machine specific data representations to the corresponding standard representations and vice versa. It contains primitives for simple data types such as int, float and string and provides the capability to define and transport more complex ones such as records, arrays of arbitrary element type and pointer bound structures such as linked lists.

Most of the XDR functions require the passing of a pointer to a structure of “XDR” type. One of the elements of this structure is an enumerated field called x_op. It's possible values are XDR_ENCODE, XDR_DECODE, or XDR_FREE. The XDR_ENCODE operation instructs the XDR routine to convert the passed data to XDR format. The XDR_DECODE operation indicates the conversion of XDR represented data back to its local representation. XDR_FREE provides a means to deallocate memory that was dynamically allocated for use by a variable that is no longer needed. For more information on XDR, see the information sources listed in the References section of this article.

RPC Data Flow

The flow of data from caller to callee and back again is illustrated in Figure 1. The calling program executes as a client process and the RPC runs on a remote server. All data movement between the client and the network and between the server and the network pass through XDR filter routines. In principle, any type of network transport can be used, but our discussion of implementation specifics centers on ONC RPC which typically uses either Transmission Control Protocol routed by Internet Protocol (the familiar TCP/IP) or User Datagram Protocol also routed by Internet Protocol (the possibly not so familiar UDP/IP). Similarly, any type of data representation could be used, but our discussion focuses on XDR since it is the method used by ONC RPC.

Figure 1. RPC Data Flow

______________________

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