Remote Procedure Calls

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

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

4. Goals of RPC • Make things easy to encourage people to use it • Construction of communicating programs perceived as difficult. • Make RPC communication efficient otherwise its use will be avoided • Provide secure communication with RPC 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) • Procedures were the major data/control transfer mechanism in Mesa. • No concept of shared address space • Author’s intuition that cost of shared address space would exceed benefits • Make remote procedure calls just like local procedure calls • Example: no time out feature with remote procedure calls CS533 - Concepts of Operating Systems

6. Structure • User -> User-stub -> RPCRuntime -> Server-stub -> Server • User-stub and Server-stub automatically generated. • Uses interface modules specifying procedure names with types of arguments and results • A program module can export (implement) an interface or import (call procedures from) an interface 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 • Servers call ExportInterface to register their interface name (type and instance) with Grapevine CS533 - Concepts of Operating Systems

8. Binding (cont.) • Server: • Servers call ExportInterface to register their interface name (type and instance) with Grapevine • RPCRuntime on server maintains table of exported interfaces including the name, dispatcher procedure, and unique ID of export • Table implemented as array. • Client • Call ImportInterface to determine address of exporter • Remote procedure call performed to receive binding info. If successful client receives unique ID of export and index into table. 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: • Import has no effect on server (server can support hundreds of clients w/o overhead) • Unique ID of exports provides an implicit unbinding on server crash CS533 - Concepts of Operating Systems

10. Transport Protocol • Transport protocol designed specifically for RPC • From author’s experience this could significantly improve performance. • 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. • Large connection cost would far outweigh the small amount of data sent each call. • Needs to scale to large number of users. • Transport layer defines semantics and guarantees for calls • A successful call will invoke the procedure on the server once • Exception reported in case of server crash or communication failure. CS533 - Concepts of Operating Systems

11. Calls • Caller sends three things per call • Call identifier, requested procedure, arguments • Call identifier allows callee to identify that result packet is the correct one. It consists of • 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 CS533 - Concepts of Operating Systems

12. Calls (cont.) • Acknowledgements and retransmissions • Sender retransmits packet until ack received • 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 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. 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 CS533 - Concepts of Operating Systems

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