1. 1 Developing Application in Distributed Computing Environment (DCE)

2. 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. 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. 4 Local Procedures Application Main Body Procedure

5. 5 Remote Procedures Main Body Procedure Application ClientServerNetwork

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

7. 7 How RPC Works: Part 2 The procedure is “split” into two parts: 1.The CLIENT “stub” – implements the interface on the local machine through which the remote functionality can be invoked. 2.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. 8 Client and Server Stubs Principle of RPC between a client and server program.

9. 9 The 10 Steps of a RPC 1.Client procedure calls client stub in normal way 2.Client stub builds message, calls local OS 3.Client's OS sends message to remote OS 4.Remote OS gives message to server stub 5.Server stub unpacks parameters, calls server 6.Server does work, returns result to the stub 7.Server stub packs it in message, calls local OS 8.Server's OS sends message to client's OS 9.Client's OS gives message to client stub 10.Stub unpacks result, returns to client

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

11. 11 RPC Runtime in DCE User Code Source Code Client Stub RPC Run time Server Stub

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

13. 13 General Terms 1.Binding Information: Client should know which servers are offering interface and how to connect to one of those servers. Server End Point (SEP): stored in database called End Point Map (Name Server) and maintained by End Point Mapper Service of dced ( daemon process) To access this information we have a data structure called binding handler. How to define interfaces?

14. 14 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 …

15. 15 Interface Definition /* arith.idl */ [ uuid(C9B5A380-295B-61C0-A51B-38502A0ECDF9) Version(1.9) ] interface arith { –typedef name char[80]; –const int arith_ok = 0; –const int arith_err = -1; –void sum_num([in] int a, [in] int b, [out] int *c); } idl arith.idl : arith.h, arith_cstub.o, arith_sstub.o

16. 16 Data Types Basic: integer, float, boolean, void, byte, error_status_t (error reporting), handler_t (binding handler). Complex: structures, unions, arrays, emun, pipes (huge data), strings. Three types of pointers: –Reference: minimal support, non null –Full: all the functionality –Unique

17. 17 Writing a Client and a Server 2-14

18. 18 Writing Client /* arithmetic client */ #include #include “arith.h” main(){ int a, b, sum; rpc_ns_habdle_t import_context; //contact name server error_status_t status; //set to exit code

19. 19 Writing Client (Cont.) // importing the binding handle rpc_ns_binding_import_begin (rpc_c_ns_syntax_default, “/.:/arith_group”, arith_v1_9_c_ifspec, NULL, &import_context, &status); // start interaction with name server rpc_ns_binding_import_next (import_context, binding_handle, &status); // returns binding handle rpc_ns_binding_import_done (&import_context, &status); //completion/freeing

20. 20 Writing Client (Cont.) // call the RPC a = 1; b = 2; sum_num (a, b, &sum); //call remote procedure printf (“the sum of %d and %d is %d \n”, a, b, sum);

21. 21 Writing Server Primary Operations: –Registering the interface with RPC Runtime Library –Creating binding information –Exporting the interface to name servers –Registering server endpoints –Listening for RPCs –Clean Up

22. 22 Writing Server (Cont.) #include #include “arith.h” main(){ // registering the interface rpc_server_register_if (arith_v1_9_c_ifspec, NULL, NULL, &status); //rpc runtime must know about the i/f that server supports, 2 nd and 3 rd for more than one i/f

23. 23 Writing Server (Cont.) // Creating binding information rpc_server_use_all_postseqs (rpc_c_postseq_max_calls_default, &status); rpc_server_inq_bindings (&binding_vector, &status); // contains all the info req. to cantact server.

24. 24 Writing Server (Cont.) // Exporting the interface rpc_ns_binding_export (rpc_c_ns_syntax_default, “/.:/arith_konark”, arith_v1_9_c_ifspec, binding_vector, NULL, &status); rpc_ns_group_mbr_add (rpc_c_ns_syntax_default, “/.:/arith_group”, rpc_c_ns_syntax_default, “/.:/arith_konark”, &status); // adding into server database

25. 25 Writing Server (Cont.) // Registering server endpoints rpc_ep_register(arith_v1_9_c_ifspec, binding_vector, NULL, “Arithmetic Interface”, &status); // Listening for RPCs rpc_server_listen(2, &status);

26. 26 Writing Server (Cont.) // Clean Up rpc_server_inq_bindings (&binding_vector, &status); rpc_ep_unregister(arith_v1_9_c_ifspec, binding_vector, NULL, &status); rpc_binding_vector_free (&binding_vector, &status);

27. 27 Binding Executables cc –o client client.c arith_cstub.o –ldce –lcma cc –o server server.c arith_sstub.o –ldce –lcma dce and cma are DCE libraries.