PreviousNext

How an RPC Call Works

A short walk-through of what happens during an RPC call may help clarify the RPC concept and how it works. This topic describes the RPC call shown in the following figure. (This description is somewhat simplified. The use of dced is not shown.)


RPC Runtime Process

On the server side, the Bank Server process is started up. Before it begins its continuous cycle of receiving and servicing requests, the server process advertises its location in the Cell Directory Service (see Point 1 in the preceding figure). In this way, when a client queries the Directory Service for a bank server, it will be able to find it. After initialization, the server listens for a request to come in from a client over the network. This call to wait for client requests is a call to the RPC runtime, since the runtime handles network communications.

Eventually, a user on the Bank Client machine invokes the bank application. The Bank Client initialization code calls the RPC runtime to find a server offering the Bank Service (see Point 2). The Bank Client application code makes a call to a remote procedure; for example, a call to a procedure that credits a bank account (3). This results in a call to the client stub code. The stub transforms the arguments of the call into a network message (4). It then calls the client's RPC runtime library, which sends the message to the server (5).

Back on the server side, the RPC request is received by the RPC runtime, which has been waiting for a client request (6). The runtime passes control, and the received packet, to the server stub. The stub unpacks the arguments sent by the client (7) and passes them to the appropriate operation by making a procedure call to it. At this point, the server application code that implements the requested operation is called. The operation is performed - the account is credited (8).

The RPC reply (not shown in the figure) returns in the reverse direction. The Bank Server application procedure returns the results of the credit operation to the stub. The stub packs up the return parameters and passes the resulting message to the RPC runtime to send off to the client over the network. The server then waits for the next client request to come in.

The client's runtime receives the server's reply. The client stub then unpacks the received network message, arranging returned parameters such that when the client application call to RPC returns, it looks like it has just performed a local procedure call.

The mechanisms in both the client and server stubs and the runtime library are transparent to the application programmer. The programmer writes the application calls to the RPC operations on the client side, and provides implementations for those operations on the server side, but the network communications code is generated automatically.