You are on page 1of 5

Introduction:

Remote Procedure Call protocol (RPC) is a powerful technique for constructing distributed, client-server based applications. It is based on extending the notion of conventional or local procedure calling, so that the called procedure need not exist in the same address space as the calling procedure. The two processes may be on the same system, or they may be on different systems with a network connecting them. By using RPC, programmers of distributed applications avoid the details of the interface with the network. The transport independence of RPC isolates the application from the physical and logical elements of the data communications mechanism and allows the application to use a variety of transports.

General RPC model:


The remote procedure call (RPC) model is similar to a local procedure call model. In the local model, the caller places arguments to a procedure in a specified location such as a result register. Then, the caller transfers control to the procedure. The caller eventually regains control, extracts the results of the procedure, and continues execution. RPC works in a similar manner, in that one thread of control winds logically through two processes: the caller process and the server process. First, the caller process sends a call message that includes the procedure parameters to the server process. Then, the caller process waits for a reply message (blocks). Next, a process on the server side, which is dormant until the arrival of the call message, extracts the procedure parameters, computes the results, and sends a reply message. The server waits for the next call message. Finally, a process on the caller receives the reply message, extracts the results of the procedure, and the caller resumes execution.

Figure1: Remote Procedure Call flow diagram

The above Remote Procedure Call Flow figure illustrates the RPC paradigm. This diagram shows the client process on the left which contains (listed from top to bottom) the client, client stub, RPC run-time library. The server process on the right contains the following (listed from top to bottom): manager procedures, server stub, and the RPC run-time library. The calls can go from the client to the manager procedures crossing the apparent flow and above the interface. The call from the client can also go through the interface to the client stub. From the client stub, the call can travel to the RPC run-time library in the client process. The call can travel to the library in the server process as a network message. Calls in the server process can go from the RPC run-time library to the server stub and from the server stub to the manager procedures. Note that there is a return in the opposite direction of each call mentioned previously. In the RPC model, only one of the two processes is active at any given time. Furthermore, this model is only an example. The RPC protocol makes no restrictions on the concurrency model implemented, and others are possible. For example, an implementation can choose asynchronous Remote Procedure Calls so that the client can continue working while waiting for a reply from the server. Additionally, the server can create a task to process incoming requests and thereby remain free to receive other requests.

Transports and Semantics of RPC


The RPC protocol is independent of transport protocols. How a message is passed from one process to another makes no difference in RPC operations. The protocol deals only with the specification and interpretation of messages. RPC does not try to implement any kind of reliability. The application must be aware of the type of transport protocol underneath RPC. If the application is running on top of a reliable transport, such as Transmission Control Protocol/Internet Protocol (TCP/IP), then most of the work is already done. If the application is running on top of a less-reliable transport, such as User Datagram Protocol (UDP), then the application must implement a retransmission and time-out policy, because RPC does not provide these services. Due to transport independence, the RPC protocol does not attach specific semantics to the remote procedures or their execution. The semantics can be inferred from (and should be explicitly specified by) the underlying transport protocol. For example, consider RPC running on top of a transport such as UDP. If an application retransmits RPC messages after short time outs and receives no reply, the application infers that the procedure was executed zero or more

times. If the application receives a reply, the application infers that the procedure was executed at least once. A transaction ID is packaged with every RPC request. To ensure some degree of execute-atmost-once semantics, RPC allows a server to use the transaction ID to recall a previously granted request. The server can then refuse to grant that request again. The server is allowed to examine the transaction ID only as a test for equality. The RPC client mainly uses the transaction ID to match replies with requests. However, a client application can reuse a transaction ID when transmitting a request. When using a reliable transport such as TCP/IP, the application can infer from a reply message that the procedure was executed exactly once. If the application receives no reply message, the application cannot assume that the remote procedure was not executed. Even if a connectionoriented protocol like TCP/IP is used, an application still needs time outs and reconnection to handle server crashes. Transports besides datagram or connection-oriented protocols can also be used. For example, a request-reply protocol, such as Versatile Message Transaction Protocol (VMTP), is perhaps the most natural transport for RPC.

Implementation of RPC
In an RPC we can divide the whole parts into two major parts, Client part and Server part. The client part consisted by the client, the client stub and one instance of RPC Runtime execute on the client machine, while the server part is consisted by the server, the server stub and another instance of RPC Runtime execute on the server machine. So the implementation of an RPC mechanism usually involves the following five elements of program: The client The client stub The RPC Runtime The server stub The server

The job of each of these elements is described below. The Client

The client is a user process that initiates a remote procedure call. To make a remote procedure call, the client makes a perfectly normal local call that invokes a corresponding procedure in the client stub. The Client Stub The client stub is responsible for carrying out the following two tasks: On receipt of a call request from the client, it packs a specification of the target procedure and the arguments into a message and then asks the local RPC Runtime to send it to the server stub. On receipt of the result of procedure execution, it unpacks the result and passes it to the client.

The RPC Runtime The RPC Runtime handles transmission of messages across the network between client and server machines. It is responsible for retransmissions, acknowledgments, packet routing and encryption. The RPC Runtime on the client machine receives the call request message from the client stub and sends it to the server machine. It also receives the message containing the result of procedure execution from the server machine and passes it to the client stub. On the other hand, the RPC Runtime on the server machine receives the message containing the result of procedure execution from the server stub and sends it to the client machine. It also receives the call request message from the client machine and passes it to the server stub.

The Server Stub The job of the server stub is very similar to that of the client stub. It performs the following two tasks: On receipt of the call request message from the local RPC Runtime, the server stub unpacks it and makes a perfectly normal call to invoke the appropriate procedure in the server. On receipt of the result of procedure execution from the server, the server stub packs the result into a message and then asks the local RPC Runtime to send it to the client stub.

The Server On receiving a call request from the server stub, the server executes the appropriate procedure and results the result of procedure execution to the server stub.

RPC Stub Generation


Stub is the most important part of a RPC program. It can be generated in two ways: Manually Automatically

The processes are described below.

Manually In this method, the RPC implementer provides a set of translation functions from which a user can construct his or her own stubs. This method is simple to implement and can handle very complex parameter types. Automatically
This is more commonly used method for stub generation. It uses an interface description language (IDL) that is used for defining the interface between Client and Server. For example, an interface definition has information to indicate whether, each argument is input, output or both only input arguments need to be copied from client to server and only output elements need to be copied from server to client.

RPC Messages

Conclusion