Remote Procedure Call (RPC)
In a certain sense, sending a message to a remote host and getting a reply back is a lot like
making a function call in a programming language. In both cases, you start with one or more
parameters and you get back a result. This observation has led people to try to arrange request-
reply interactions on networks to be cast in the form of procedure calls. Such an arrangement
makes network applications much easier to program and more familiar to deal with. For
example, just imagine a procedure named get IP address (host name) that works by sending a
UDP packet to a DNS server and waiting for the reply, timing out and trying again if one is not
forthcoming quickly enough. In this way, all the details of networking can be hidden from the
programmer. The key work in this area was done by Birrell and Nelson (1984). In a nutshell,
what Birrell and Nelson suggested was allowing programs to call procedures located on remote
hosts. When a process on machine 1 calls a procedure on machine 2, the calling process on 1 is
suspended and execution of the called procedure takes place on 2. Information can be transported
from the caller to the callee in the parameters and can come back in the procedure result. No
message passing is visible to the application programmer. This technique is known as RPC
(Remote Procedure Call) and has become the basis for many networking applications.
Traditionally, the calling procedure is known as the client and the called procedure is known as
the server, and we will use those names here too. The idea behind RPC is to make a remote
procedure call look as much as possible like a local one. In the simplest form, to call a remote
procedure, the client program must be bound with a small library procedure, called the client
stub, that represents the server procedure in the client’s address space. Similarly, the server is
bound with a procedure called the server stub. These procedures hide the fact that the procedure
call from the client to the server is not local.
The actual steps in making an RPC are shown in Fig. Step 1 is the client calling the client stub.
This call is a local procedure call, with the parameters pushed onto the stack in the normal way.
Step 2 is the client stub packing the parameters into a message and making a system call to send
the message. Packing the parameters is called marshaling. Step 3 is the operating system
sending the message from the client machine to the server machine. Step 4 is the operating
system passing the incoming packet to the server stub. Finally, step 5 is the server stub calling
the server procedure with the unmarshaled parameters. The reply traces the same path in the
other direction. The key item to note here is that the client procedure, written by the user, just
1 SKK IT KIET RPC
makes a normal (i.e., local) procedure call to the client stub, which has the same name as the
server procedure. Since the client procedure and client stub are in the same address space, the
parameters are passed in the usual way. Similarly, the server procedure is called by a procedure
in its address space with the parameters it expects. To the server procedure, nothing is unusual.
In this way, instead of I/O being done on sockets, network communication is done by faking a
normal procedure call.
2 SKK IT KIET RPC
