RPC stands for "Remote Procedure Call", and it is a method of calling code that is on a remote host similarly to calling it locally. This may not seem like a big deal, but it's incredibly useful and there are quite a few details that it takes care of for you.
Before we talk about using RPCs in your code, lets talk about a simple shell version of a remote procedure call. The shell command rsh lets you run a command on a remote host (provided you are on a machine in the trusted host list for that host). rsh -n styx Server & for example, would run a server program on styx. The -n option connects the stdin of the command on the remote host to /dev/null, which is generally a good idea (if you want to run a command than needs input, just ssh to the host).
In general RPCs work as follows: An RPC protocol definition file is run through rpcgen, which creates a client stub, a server stub, a header file, and an XDR (eXternal Data Representation) file.
The XDR is what lets computers with different data representations (e.g. big-endian vs. little-endian) successfully communicate numbers back and forth. All of this is taken care of, so you can ignore it for coding. One of the conveniences of RPCs.
The stubs are where the real convenience is. When you make a call to a remote procedure, the client stub takes the parameters, marshals them (flattens data structures, filters them through the XDR, etc.) then it does all the hardware-level communication with the server stub. When a reply comes back, it unpacks the marshaled return value from the server stub, and passes them along to your program. The server stub does essentially the same things in reverse at it's end.
So at a high level, at least, it's very useful. Unfortunately, as is often the case with UNIX/C programming, there are ugly details to worry about. I won't go too much into depth here, since you won't have a programming assignment on RPCs this year, but it's worth scanning through chapter 9 to see what's involved, and looking at code from previous years. If you read through the description and solution to last year's assignment (I know it's long, but I like to think it's fairly readable), it should make a whole lot more sense than just reading the monkey book.
As I said, there are ugly details. Without going too far in depth, here's a list of some of the big ones:
However, once you get through those and learn the functions like clnt_create
and clnt_destroy that you need to use to initialize RPC programs,
coding remote programs is almost as easy as local programs. So although there
is a learning curve, it really pays off once you're past it.
While all the gritty details are language-specific, the concepts apply in many languages. For example, Java's RMI (Remote Method Invocation) and the very popular and (mostly) cross-language SOAP are built on the same principles, although they both have much much cleaner interfaces. So I really suggest learning the concept thoroughly even if you never plan to use C RPCs.
Stuart Morgan, 2003