Remote Procedure Call

1. Remote Procedure Call

2. RPC: Remote Procedure Call • “To allow programs to call procedures located on other machines.” • Effectively removing the need for the DS programmer to worry about all the details of network programming (i.e., no more sockets).

3. How RPC Works: Part 1 • As far as the programmer is concerned, a “remote” procedure call looks and works identically to a “local” procedure call. • In this way, transparency is achieved. • Before looking a RPC in action, let’s consider a conventional “local” procedure call (LPC).

4. Local Procedures Application Procedure Main Body Procedure

5. Remote Procedures Application Procedure Main Body Procedure Client Network Server

6. Conventional Local Procedure Call • Parameter passing in a local procedure call: the stack before the call to read. • The stack while the called procedure is active.

7. How RPC Works: Part 2 • The procedure is “split” into two parts: • The CLIENT “stub” – implements the interface on the local machine through which the remote functionality can be invoked. • The SERVER “stub” – implements the actual functionality, i.e., does the real work! • Parameters are “marshaled” by the client prior to transmission to the server.

8. Client and Server Stubs Principle of RPC between a client and server program.

9. The 10 Steps of a RPC • 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

10. Passing Value Parameters (1) Steps involved in doing remote computation through RPC.

11. Interface Definition Language (IDL) • RPCs typically require development of custom protocol interfaces to be effective. • Protocol interfaces are described by means of an Interface Definition Language (IDL). • IDLs are “language-neutral” – they do not presuppose the use of any one programming language. • That said, most IDLs look a lot like C …

12. Interface Definition • /* arith.idl */ • [ • uuid(C9B5A380-295B-61C0-A51B-38502A0ECDF9) • ] • interface arith • { • const float pi = 3.14 • void sum_num([in] int a, [in] int b, [out] int *c); } • idl arith.idl : arith.h, arith_cstub.o, arith_sstub.o

13. Interface Definition (Cont.) • client.c • #include “arith.h” • Main() • { • …… • } • server.c • #include “arith.h” • Main() • { • …… • } • gcc –o server server.c arith_sstub.o –ldce • gcc –o client client.c arith_cstub.o –ldce

14. Writing a Client and a Server The steps in writing a client and a server in RPC. 2-14

15. Failure Situations • Locating the Server • Hard coded into client’s code • Client broadcasts • Dynamic Binding • Server registers itself to along with the services it offers with a registry server • Clients can query it and find out… • Server crashes • Client crashes • Orphan • Log entry – extermination • Broadcasting id – reincarnation • Server kills all orphans – expiration

16. RPC Problems • Global Variables (not visible to servers) • Pointers (integer / linked list) • Inherently Synchronous (ARPC) • RPC works really well if all the machines are homogeneous. • Complications arise when two machines use different character sets, e.g., EBCDIC or ASCII. • Byte-ordering is also a problem: • Intel machines are “big-endian”. • Sun Sparc’s are “little-endian”. • Extra mechanisms are required to be built into the RPC mechanism to provide for these types of situations – this adds complexity.

17. Passing Value Parameters (2) • Original message on the Pentium. • The message after receipt on the SPARC. • The message after being inverted. The little numbers in boxes indicate the address of each byte.

18. RMI: Remote Method Invocation • “Remote objects” can be thought of as an expansion of the RPC mechanism (to support OO systems). • An important aspect of objects is the definition of a well-defined interface to “hidden” functionality. • Method calls support state changes within the object through the defined interface. • An object may offer multiple interfaces. • An interface may be implemented by multiple objects. • Within a DS, the object interface resides on one machine, and the object implementation resides on another.

19. The Distributed Object • Organization of a remote object with client-side “proxy”. • The “proxy” can be thought of as the “client stub”. • The “skeleton” can be thought of as the “server stub”. 2-16

20. Example: Java RMI • In Java, distributed objects are integrated into the language proper. • This affords a very high degree of distribution transparency (with exceptions, where it makes sense, perhaps to improve efficiency). • Java does not support RPC, only distributed objects. • The distributed object’s state is stored on the server, with interfaces made available to remote clients (via distributed object proxies). • To build the DS application, the programmer simply implements the client proxy as a class, and the server skeleton as another class.

21. DCE: An Example RPC • The Open Group’s standard RPC mechanism. • In addition to RPC, DCE provides: • Distributed File Service. • Directory Service (name lookups). • Security Service. • Distributed Time Service.

22. DCE: “Binding” a Client to a Server Client-to-server binding in DCE. A “directory service” provides a way for the client to look-up server. 2-15