1. CS533 - Concepts of Operating Systems 1 Remote Procedure Calls - Alan West

2. CS533 - Concepts of Operating Systems 2 What are remote procedure calls?  Remote procedure calls o Extends notion of local procedure calls so a called procedure could exist and be executed on a remote machine. o Used to construct distributed client/server applications where the client calls procedures remotely on the server.

3. CS533 - Concepts of Operating Systems 3 Major design issues  Semantics of a call in presence of machine/communication failure.  How a caller binds to a callee.  Suitable protocol for transfer of data/control between caller and callee.  How to provide data integrity and security.

4. CS533 - Concepts of Operating Systems 4 Goals of RPC  Make things easy to encourage people to use it o Construction of communicating programs perceived as difficult.  Make RPC communication efficient otherwise its use will be avoided  Provide secure communication with RPC

5. CS533 - Concepts of Operating Systems 5 Fundamental decisions made in author’s RPC implementation  Use of the procedure call paradigm (as opposed to message passing for instance) o Procedures were the major data/control transfer mechanism in Mesa.  No concept of shared address space o Author’s intuition that cost of shared address space would exceed benefits  Make remote procedure calls just like local procedure calls o Example: no time out feature with remote procedure calls

6. CS533 - Concepts of Operating Systems 6 Structure  User -> User-stub -> RPCRuntime -> Server-stub -> Server  User-stub and Server-stub automatically generated. o Uses interface modules specifying procedure names with types of arguments and results o A program module can export (implement) an interface or import (call procedures from) an interface

7. CS533 - Concepts of Operating Systems 7 Binding  Client must specify what it wants to bind to (which interface the expects the callee to implement)  Client must determine the address of the callee and specify which procedure it wishes to invoke.  Grapevine is used for binding in author’s implementation o Servers call ExportInterface to register their interface name (type and instance) with Grapevine

8. CS533 - Concepts of Operating Systems 8 Binding (cont.)  Server: o Servers call ExportInterface to register their interface name (type and instance) with Grapevine o RPCRuntime on server maintains table of exported interfaces including the name, dispatcher procedure, and unique ID of export o Table implemented as array.  Client o Call ImportInterface to determine address of exporter o Remote procedure call performed to receive binding info. If successful client receives unique ID of export and index into table.

9. CS533 - Concepts of Operating Systems 9 Binding (cont.)  Once binding succeeds client can make a remote call. A call to the remote machine includes unique ID and table index so RPCRuntime can send call packet to correct dispatcher in server-stub.  Further things to note: o Import has no effect on server (server can support hundreds of clients w/o overhead) o Unique ID of exports provides an implicit unbinding on server crash

10. CS533 - Concepts of Operating Systems 10 Transport Protocol  Transport protocol designed specifically for RPC o From author’s experience this could significantly improve performance. o Request-response nature of RPC is unlike the large data transfers which byte streams are designed for.  Goal in protocol design is to lower connection cost. o Large connection cost would far outweigh the small amount of data sent each call. o Needs to scale to large number of users.  Transport layer defines semantics and guarantees for calls o A successful call will invoke the procedure on the server once o Exception reported in case of server crash or communication failure.

11. CS533 - Concepts of Operating Systems 11 Calls  Caller sends three things per call o Call identifier, requested procedure, arguments  Call identifier allows callee to identify that result packet is the correct one. It consists of o Machine ID, calling process ID, sequence number  Only one outstanding remote call per “activity” (machine ID, process pair)  Server maintains table for each calling activity  Call packet from previously unknown activity creates a connection implicitly.  In case of server crash RPC relies on unique server ID to recognize crash. The ID will change after the machine reboots

12. CS533 - Concepts of Operating Systems 12 Calls (cont.)  Acknowledgements and retransmissions o Sender retransmits packet until ack received o Probe packets sent periodically during long calls to make sure communication to server is still available  Multiple packets sent when argument list is too large  A protocol designed for bulk transfer may be beneficial for more complex calls

13. CS533 - Concepts of Operating Systems 13 Exception handling  Semantics for exception handling equivalent to those in Mesa.  Server can reply with an exception packet instead of result.  If client contains a catch phrase for the exception then it will execute it normally and notify server.

14. CS533 - Concepts of Operating Systems 14 Processes  Process creation and process swapping can be expensive on the scale of a remote procedure call.  A server maintains a stock of idle server processes to avoid procedure creation.  Each packet contains a process ID for both source and destination.  Ethernet driver checks process ID of packet and forwards to correct process

15. CS533 - Concepts of Operating Systems 15 Other stuff  Security: o Author’s implementation give a guarantee of the identity of a callee through the use of the Grapevine DB. o Full end-to-end encryption of calls and results.  Performance o Remote procedure calls appeared to be 1 to 2 orders of magnitude slower than local procedure calls.