Remote Procedure Call
- 1. RMC-Remote Procedure Call M.Jagadeesh, Assistant Professor, Information Technology, MNM Jain Engineering College, Chennai
- 2. Styles of exchange protocols Request (R) protocol- No requirement of reply or acknowledgment . Soon after request, the client carries out with the other application. Implemented over datagram protocol. Request- reply protocol(RR) – No ACK required because reply acts as ACK. Implemented on UDP. Request- reply- ACK protocol(RRA)- The ACK message contains requestId from the reply message being acknowledged. The arrival of requestId in ACK is interpreted as ACK receipt of all reply messages with lower requestId.
- 3. Definition of Remote Procedure Call 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. This method is known as Remote Procedure Call. A procedure call is also sometimes known as a function call or a subroutine call. Message passing is hidden to the programmer.
- 4. RPC Model It is similar to commonly used procedure call model. RPC is generally implemented over a request- reply protocol. It works in the following manner: 1. For making a procedure call, the caller places arguments to the procedure in some well specified location. 2. Control is then transferred to the sequence of instructions that constitutes the body of the procedure. 3. The procedure body is executed in a newly created execution environment that includes copies of the arguments given in the calling instruction. 4. After the procedure execution is over, control returns to the calling point, returning a result.
- 5. Difference between local and remote procedure call Local procedure call is done either by call by value or call by address/ reference. Disjoint Address Space-In remote procedure call , this is not possible because the address space of procedure calling and one that is called are different. So RPC can be done by *stubs- proxies, Flattening- marshalling. *Stubs- A stub is a piece of code that is used to convert parameters during a RPC. Since RPC allows a client computer to call remote procedures on server as local procedures, the parameters used in function call have to be converted. Stub libraries are installed on the client and server.
- 7. Steps in a remote procedure call
- 8. The client calls a local procedure, called the client stub. To the client process, this appears to be the actual procedure, because it is a regular local procedure. It just does something different since the real procedure is on the server. The client stub packages the parameters to the remote procedure (this may involve converting them to a standard format) and builds one or more network messages. The packaging of arguments into a network message is called marshaling and requires serializing all the data elements into a flat array-of-bytes format. Network messages are sent by the client stub to the remote system (via a system call to the local kernel using sockets interfaces). Network messages are transferred by the kernel to the remote system via some protocol (either connectionless or connection-oriented). A server stub, sometimes called the skeleton, receives the messages on the server. It unmarshals the arguments from the messages and, if necessary, converts them from a standard network format into a machine-specific form.
- 9. The server stub calls the server function (which, to the client, is the remote procedure), passing it the arguments that it received from the client. When the server function is finished, it returns to the server stub with its return values. The server stub converts the return values, if necessary, and marshals them into one or more network messages to send to the client stub. Messages get sent back across the network to the client stub. The client stub reads the messages from the local kernel. The client stub then returns the results to the client function, converting them from the network representation to a local one if necessary. The client code then continues its execution.
- 10. Transparency of RPC 1. Syntactic Transparency means that the remote procedure call should have exactly the same syntax as a local procedure call. 2. Semantic Transparency means that the semantics of a remote procedure call are identical to those of a local procedure call
- 11. RPC procedure call semantics RPC supports 3 different “call semantics” that define the level of guarantee of requests: 1. maybe call semantics. 2. at-least-once call semantics. 3. at-most-once call semantics.
- 12. maybe call semantics: No retransmission of request messages. Client is not certain whether the procedure has been executed or not. No fault-tolerance measures (RPC call may or may not be successful). Generally not acceptable (low level of guarantee). at-least-once call semantics: The message module repeatedly resends request messages after timeouts occur until it either gets a reply message or a maximum number of retries have been made. No duplicate request message filtering. The remote procedure is called at least once if the server is not down. The client does not know how many times the remote procedure has been called. This could produce undesirable results (e.g., money transfer) unless the called procedure is “idempotent” (= repeatable with the same effect as a single call).
- 13. at-most-once call semantics: Retransmission of request messages. Duplicate request message filtering. If the server does not crash and the client receives the result of a call, then the procedure has been called exactly once. Otherwise, an exception is reported and the procedure will have been called either once or not at all. Works for both idempotent and non-idempotent operations. More complex support required due to the need for request message filtering and for keeping track of replies.
- 14. Comparison