Developing application in distributed computing environment dce
Sponsored Links
This presentation is the property of its rightful owner.
1 / 27

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

  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Developing Application in Distributed Computing Environment (DCE)

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

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

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

  • 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

  • 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

Principle of RPC between a client and server program.

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

Steps involved in doing remote computation through RPC.

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

Client-to-server binding in DCE.

A “directory service” provides a way for the client to look-up server.


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)

  • 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

  • /* 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

  • 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 a Client and a Server


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

  • // 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 (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

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

  • #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 (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 (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 (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 (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

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

  • Login