Introduction
We are aware of the inter-process communication(IPC) mechanisms like shared memory, and message passing. These techniques were mainly used when the processes in the same system had to communicate with each other. The remote procedure call (RPC) comes into the picture when processes in the different systems want to communicate. The systems, in this case, are connected via a network. A simple example of this is a client-server system, where a process in the client system wants to communicate with the process present in the server.
Remote Procedure Call (RPC) is a protocol that one process can use to request a service from a process located in another computer on a network without having to look into the details of the network.
Each message that needs to be exchanged is addressed to an RPC daemon listening to a port on the remote system, and each contains an identifier of the function to execute and the parameters that are passed to the function.
The function is then executed as requested, and any output, if any, is sent back to the requester in a separate message.
The above lines will be more clear when we will see the working of the RPC.
Also See, FCFS Scheduling Algorithm, Multiprogramming vs Multitasking
Working of Remote Procedure Call (RPC)
- The RPC system will hide the details that allow communication to take place by providing a stub on the client side.
- A separate stub is available for each separate remote procedure (RPC).
- When the client starts a remote procedure, the RPC system makes a call to the appropriate stub and passes it to the parameters provided to the remote procedure. The work of the stub is to locate the port on the server and marshall the parameter.
- Parameter marshaling involves converting and packaging the parameters into a form that can be transmitted over a network on the server.
- The stub will then transmit a message to the server using message passing.
- The same kind of stub on the server side receives this message and invokes the procedure on the server.
- After completing the work on the server side, the stub on the server side will again marshall the return value, if any, into a message. After that, it will be again sent back to the transport layer by the stub.
- The client stub will receive the message. It will unpack or demarshalls the returned parameters, and finally, the executing process returns to the caller.
Issues in RPC and their solutions
1. In case of a network failure, the remote procedure calls can fail or may execute more than once
In order to avoid this, it must be ensured that the procedure call is executed exactly once. It may be complex for the Operating System to ensure this. However, we have another technique where the server could send an acknowledgment to the client representing that the procedure call has been successfully executed.
2. Binding: How does the client know the port numbers on the server?
Whenever a procedure call is made, we call it by its name, but the procedure has to be addressed using its memory address. There is a fixed port number for both the client and server. Although the client knows the name of the procedure, it is calling but not its port number or memory address.
Here binding can be done dynamically using a matchmaker. The client sends a message to the matchmaker containing the name of RPC, requesting the port address of the RPC it wants to execute. The port number is returned by the matchmaker.
Click on the following link to read further: Multitasking Operating System and Open Source Operating System.
7+ registered 
