developing application in distributed computing environment dce n.
Skip this Video
Download Presentation
Developing Application in Distributed Computing Environment (DCE)

Loading in 2 Seconds...

play fullscreen
1 / 27

Developing Application in Distributed Computing Environment (DCE) - PowerPoint PPT Presentation

  • Uploaded on

Developing Application in Distributed Computing Environment (DCE). 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 ).

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Developing Application in Distributed Computing Environment (DCE)' - lance

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
rpc remote procedure call
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).
how rpc works part 1
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).

Local Procedures



Main Body



Remote Procedures



Main Body





conventional local procedure call
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.
how rpc works part 2
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.
client and server stubs
Client and Server Stubs

Principle of RPC between a client and server program.

the 10 steps of a rpc
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
passing value parameters
Passing Value Parameters

Steps involved in doing remote computation through RPC.

rpc runtime in dce
RPC Runtime in DCE

User Code

Source Code

RPC Run time

RPC Run time

Server Stub

Client Stub

dce binding a client to a server
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.


general terms
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?
interface definition language idl
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 …
interface definition
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
data types
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
writing client
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
writing client cont
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
writing client cont1
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);
writing server
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
writing server cont
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
writing server cont1
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.
writing server cont2
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
writing server cont3
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);
writing server cont4
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);
binding executables
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.