Developing Application in Distributed Computing Environment (DCE)

1. Developing Application in Distributed Computing Environment (DCE)

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 Steps involved in doing remote computation through RPC.

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

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. General Terms • 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. 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. 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. 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. Writing a Client and a Server 2-14

18. Writing Client • /* arithmetic client */ • #include<stdio.h> • #include<dce/rpc.h> • #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. 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. 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. 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. Writing Server (Cont.) • #include<stdio.h> • #include<dce/rpc.h> • #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, 2nd and 3rd for more than one i/f

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