Remote Procedure Call

1. Remote Procedure Call

2. Introduction • Remote Procedure Call (RPC) is a high-level model for client-sever communication. • It provides the programmers with a familiar mechanism for building distributed systems. • Examples: File service, Authentication service.

3. Introduction • Why we need Remote Procedure Call (RPC)? • The client needs a easy way to call the procedures of the server to get some services. • RPC enables clients to communicate with servers by calling procedures in a similar wayto the conventional use of procedure calls in high-level languages. • RPC is modeled on the local procedure call, but the called procedure is executed in a different process and usually a different computer.

4. Introduction • How to operate RPC? • When a process on machine A calls a procedure on machine B, the calling process on A is suspended, and the 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 or I/O at all is visible to the programmer.

5. The RPC model client server Call procedure and wait for reply request Receive request and start process execution Send reply and wait for next execution reply Resume execution Blocking state Executing state

6. Characteristics • The called procedure is in another process which may reside in another machine. • The processes do not share address space. • Passing of parameters by reference and passing pointer values are not allowed. • Parameters are passed by values. • The called remote procedure executes within the environment of the server process. • The called procedure does not have access to the calling procedure's environment.

7. Features • Simple call syntax • Familiar semantics • Well defined interface • Ease of use • Efficient • Can communicate between processes on the same machine or different machines

8. Design Issues • Exception handling • Necessary because of possibility of network and nodes failures; • RPC uses return value to indicate errors; • Transparency • Syntactic  achievable, exactly the same syntax as a local procedure call; • Semantic  impossible because of RPC limitation: failure (similar but not exactly the same);

9. RPC Mechanism • Based on concepts of stubs • Stub is a code used for converting parameter used in procedure call • RPC involves Client & Server Process • Mechanism involves following five elements: • The Client • The Client Stub • The RPCRuntime • The Server Stub • The Server

10. RPC Mechanism Client Machine Server Machine Server Client Call Return Return Call Client Stub Server Stub Unpack Pack Unpack Pack RPC Runtime RPC Runtime Receive Send Receive Send Call Packet Result Packet

11. 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

12. Client: • Initiates RPC • Makes a local call that invokes a corresponding procedure in the client stub • Client Stub: • Receiving a call request from client: • Packs the specification of the target procedure & the arguments into a message • Asks local RPCRuntime to send it to server stub • Receiving result of procedure execution • Unpacks the result & passes it to the client

13. RPCRuntime: • Client Machine • Receive call request message from Client Stub & sends to server machine • Receives the message containing the result of procedure execution from the server machine & sends to client stub • Server Machine • Receives the message containing the result of procedure execution from the server stub & sends it to client machine • Receive call request message from the client machine & sends it to server stub

14. Server Stub: • Receiving a call request from local RPCRuntime: • Unpacks & makes a normal call to invoke the appropriate procedure in Server • Receiving result of procedure execution • Packs the result into a message • Asks local RPCRuntime to send it to client stub • Server: • Receiving a call request from the server stub • Executes the appropriate procedure • Returns the result of execution to the server stub

15. Stub Generation • Manually • The RPC implementor provides a set of translation functions from which a user can construct his/her own stubs • It is simple to implement and can handle very complex parameter types • Automatically • Uses Interface Definition Language(IDL) • Define interface between a client & a server • Interface Definition-> a list of procedure names supported by the interface, with the types of their arguments & results • It helps the client & server to independently perform compile-time type checking & to generate appropriate calling sequence

16. RPC Messages • Two Types of Messages involved • Call Messages • Sent by the client to the server for requesting execution of particular remote procedure • Reply Messages • Sent by the server to the client for returning the result of remote procedure execution

17. Call Messages • Two basic fields in a call message are as follows: • The identification information of the remote procedure to be executed • The arguments necessary for the execution • Other additional fields are: • A message identification field that consist of sequence number • A message type field that used to distinguish call messages from reply message • A client identification field -> 2 purposes: • To allow the server of RPC to identify the client • To allow the server to check the authentication of the client process for executing the concerned procedure

18. Reply Message • Two message format • A successful message format • Msg Message Reply Status • identifier Type (successful) Result • An unsuccessful message format • Msg Message Reply Status Reason for • identifier Type (unsuccessful) Failure

19. Marshaling Arguments & Result • The transfer of message data between two computers requires encoding & decoding of the message data • This operation in RPCs is known as Marshaling • Actions involved in Marshaling • Taking the arguments • Encoding the message data on sender’s computer • Decoding the message data on receiver’s computer

20. Server Management • Two issues in server management • Server Implementation • Stateful Server • Stateless Server • Server Creation • Instance-per-call server • Instance-per-session server • Persistent servers

21. Server Implementation • Based on the style of implementation, it is of two types • Stateful Servers • Maintains clients’ state information • For eg: Consider a server for byte stream files that allows the following operations on file: • Open(filename, mode) • Read(fid, n, buffer) • Write(fid, n, buffer) • Seek(fid, position) • Close(fid)

22. Client Process Server Process Open(filename,mode) Return(fid) R/W ptr Mode fid Read (fid, 100, buf) Return(bytes 0 to 99) Read (fid, 100, buf) Return(bytes100 to199) Stateful File Server

23. Stateless Servers • Does not maintain any client state information • For eg: Consider a server for byte stream files that allows the following operations on files is stateless: • Read(filename, position, n ,buffer) • write(filename, position, n ,buffer)

24. Client Process Server Process Read (fid, 100, buf) R/W ptr Mode fid Return(bytes 0 to 99) Read (filename, 100, buf) Return(bytes100 to199) Stateless File Server

25. Server Creation Semantics • Based on time duration for which RPC servers survive, it is classified into three • Instance-per-Call Servers • Exist only for the duration of a single call • Created by RPCRuntime -> when a call message arrives • Instance-per-Session Servers • Exist for the entire session for which a client & a server intract • Persistent Servers • Remains in existence indefinetely