The RPC model is similar to the local procedure call model. In the local case, the caller places arguments to a procedure in some well-specified location. The caller then transfers control to the procedure, and eventually regains control. At that point, the results of the procedure are extracted from a well-specified location, and the caller continues execution.
The RPC model is similar, in that one thread of control logically winds through two processes. One is the caller's process, the other is a server's process. Conceptually, the caller process sends a call message to the server process and waits for a reply message. The call message contains the procedure's parameters, among other information. The reply message contains the procedure's results, among other information. After the reply message is received, the results of the procedure are extracted, and the caller's execution is resumed.
On the server side, a process is dormant awaiting the arrival of a call message. When one arrives, the server process extracts the procedure's parameters, computes the results, sends a reply message, and then awaits the next call message.
Note that in this description only one of the two processes is active at any given time. However, the RPC protocol makes no restrictions on the concurrency model implemented. For example, an implementation might choose to have RPC calls be asynchronous, so that the client can do useful work while waiting for the reply from the server. Another possibility is to have the server create a task to process an incoming request so that the server is free to receive other requests.