Define Remote Procedure Call. Explain working of RPC in details. (December 17/ May 17). (10 Marks).

Q. Define Remote Procedure Call. Explain working of RPC in details. (December 17/ May 17). (10 Marks).
     Explain Call Semantic of RPC.
Ans - A remote procedure call is an inter process communication technique that is used for client-server based applications. It is also known as a subroutine call or a function call.
A client has a request message that the RPC translates and sends to the server. This request may be a procedure or a function call to a remote server. When the server receives the request, it sends the required response back to the client. The client is blocked while the server is processing the call and only resumed execution after the server is finished.

The sequence of events in a remote procedure call are given as follows:

1. The client stub is called by the client.
2. The client stub makes a system call to send the message to the server and puts the parameters in the message.
3. The message is sent from the client to the server by the client’s operating system.
4. The message is passed to the server stub by the server operating system.
5. The parameters are removed from the message by the server stub.
6. Then, the server procedure is called by the server stub.  

Advantages

1. Remote procedure calls support process oriented and thread oriented models.
2. The internal message passing mechanism of RPC is hidden from the user.
3. The effort to re-write and re-develop the code is minimum in remote procedure calls.
4. Remote procedure calls can be used in distributed environment as well as the local environment.
5. Many of the protocol layers are omitted by RPC to improve performance. 

 

Disadvantages

1. The remote procedure call is a concept that can be implemented in different ways. It is not a standard.
2. There is no flexibility in RPC for hardware architecture. It is only interaction based.
3. There is an increase in costs because of remote procedure call.

Call Semantic in RPC

In RPC the caller and callee processes can be situated on different nodes. The normal functioning of an RPC may get disrupted due to one or more reasons mentioned below:

• Call message is lost or response message is lost
• The callee node crashes and is restarted
• The caller node crashes and is restarted.

In RPC system the call semantics determines how often the remote procedure may be executed under fault conditions. The different types of RPC call semantics are as follows:

1. May-Be Call Semantics

• This is the weakest semantics in which a timeout mechanism is used that prevents the caller from waiting indefinitely for a response from the callee.
• This means that the caller waits until a pre-determined timeout period and then continues to execute.
•  Hence this semantics does not guarantee the receipt of call message nor the execution. This semantics is applicable where the response message is less important and applications that operate within a local network with successful transmission of messages.

2. Last-Once Call Semantics

• This call semantics uses the idea of re-transmitting the call message based on timeouts until the caller receives a response.
• The call, execution and result of will keep repeating until the result of procedure execution is received by the caller.
• The results of the last executed call are used by the caller, hence it known as last-one semantics.
•  Last one semantics can be easily achieved only when two nodes are involved in the RPC, but it is tricky to implement it for nested RPCs and cases by orphan calls.

3. Last-of-Many Call Semantics

• This semantics neglects orphan calls unlike last-once call semantics. Orphan call is one whose caller has expired due to node crash.
• To identify each call, unique call identifiers are used which to neglect orphan calls.
• When a call is repeated, it is assigned to a new call identifier and each response message has a corresponding call identifier.
• A response is accepted only if the call identifier associated with it matches the identifier of the most recent call else it is ignored.

4. At-Least-Once Call Semantics

• This semantics guarantees that the call is executed one or more times but does not specify which results are returned to the caller.
• It can be implemented using timeout based re-transmission without considering the orphan calls.

5. Exactly-Once Call Semantics

• This is the strongest and the most desirable call semantics. It eliminates the possibility of a procedure being executed more than once irrespective of the number of re-transmitted call.
• The implementation of exactly-once call semantics is based on the use of timeouts, re-transmission, call identifiers with the same identifier for repeated calls and a reply cache associated with the callee.