Distributed systems have been based on explicit message exchange between processes.

The procedures send and receive do not conceal communication at all, which is important to achieve access transparency in distributed systems.

When a process on machine A calls' a procedure on machine B, the calling process on A is suspended, and execution of the called procedure takes place on B. Information can be transported from the caller to the callee in the parameters and can come back in the procedure result. No message passing at all is visible to the programmer. This method is known as Remote Procedure Call, or often just RPC.

Basic RPC operation - To understand the basic operation of RPC we need to first understand the conventional procedure call i.e the single machine call and then split the call to a client and server part that can be executed on different machines.

Conventional Procedure Call:

To understand the conventional procedure call, consider the example

count = trial (fd, buf, nbytes)

Where fd is an .integer indicating a file, buf is an array of characters into which data are read, and nbytes is another integer telling how many bytes to read.

Client and Server Stub:

The RPC is intended to make communication between the process and the procedures, where the parameters are passed by the local process to the remote procedure using the local system call.

Therefore to make RPC more transparent, the calling process at the client side packs the parameters and data in to a message called the client stub.

The packing of the data is also called the marshalling process.

The RPC transport sends client stub across the network to the server side.

The server stub is generated at the server side, which unpacks client stub and passes the parameter to the called procedure that generate the result.

The server stub is also responsible for packing the result in to message and sending across the network to the client, where the client stub unpacks it and sends the result back to the client process.

The unpacking of data is also called the Unmarshalling process.

Steps of a Remote Procedure Call

• Client procedure calls client stub in normal way.

• Client stub builds message, calls local OS.

• Client's OS sends message to remote OS

• Remote OS gives message to server stub

• Server stub unpacks parameters, calls server

• Server does work, returns result to the stub

• Server stub packs it in message, calls local OS

• Server's OS sends message to client's OS

• Client's OS gives message to client stub

• Stub unpacks result, returns to client

Parameter Passing:

In RPC, the parameter are passed in two ways - Pass by value and Pass by reference.

In pass by value, the actual parameters and their data types are copied in to the stack and passed to the called procedure.

In pass by reference, the pointer to the data is passed instead of value to the called procedure at the server side.

It is very difficult to implement as the server needs to keep the track of the pointer to the data at the client’s address space.

Asynchronous RPC:

As in conventional procedure calls, when a client calls a remote procedure, the client will block until a reply is returned.

This strict request-reply behavior is unnecessary when there is no result to return, and only leads to blocking the client while it could have proceeded and have done useful work just after requesting the remote procedure to be called.

Examples of where there is often no need to wait for a reply include: transferring money from one account to another, adding entries into a database, starting remote services, batch processing, and so on.

To support such situations, RPC systems may provide facilities for what are called asynchronous RPCs, by which a client immediately continues after issuing the RPC request.

With asynchronous RPCs, the server immediately sends a reply back to the client the moment the RPC request is received, after which it calls the requested procedure.

The reply acts as an acknowledgment to the client that the server is going to process the RPC.

The client will continue without further blocking as soon as it has received the server's acknowledgment. Figure below shows how client and server interact in the case of asynchronous RPCs.