6.4.

2 Remote Procedure Call

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
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.
402
The actual steps in making an RPC are shown in
Fig. 6-24. 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
kernel sending the message from the client
machine to the server machine. Step 4 is the
kernel 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.
Figure 6-24. Steps in making a remote
procedure call. The stubs are
shaded.
The key item to note here is that the client
procedure, written by the user, just 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.
Despite the conceptual elegance of RPC, there
are a few snakes hiding under the grass. A big
one is the use of pointer parameters. Normally,
passing a pointer to a procedure is not a
problem. The called procedure can use the
pointer in the same way the caller can because
both procedures live in the same virtual address
space. With RPC, passing pointers is
impossible because the client and server are in
different address spaces.
In some cases, tricks can be used to make it
possible to pass pointers. Suppose that the first
parameter is a pointer to an integer, k. The client
stub can marshal k and send it along to the
server. The server stub then creates a pointer to
k and passes it to the server procedure, just
as it expects. When the server procedure returns
control to the server stub, the latter sends k
back to the client where the new k is copied over
the old one, just in case the server changed
it. In effect, the standard calling sequence of
call-by-reference has been replaced by
copyrestore.
Unfortunately, this trick does not always work,
for example, if the pointer points to a
graph or other complex data structure. For this
reason, some restrictions must be placed on
parameters to procedures called remotely.
A second problem is that in weakly-typed
languages, like C, it is perfectly legal to write a
procedure that computes the inner product of
two vectors (arrays), without specifying how
large either one is. Each could be terminated by
a special value known only to the calling and
called procedure. Under these circumstances, it
is essentially impossible for the client stub to
marshal the parameters: it has no way of
determining how large they are.
A third problem is that it is not always possible to
deduce the types of the parameters, not
even from a formal specification or the code
itself. An example is printf, which may have any