Distributed Processing Systems (InterProcess Communication) (Remote Procedure Call) Distributed Processing Systems (InterProcess Communication) (Remote

Distributed Processing SystemDistributed Processing Systemss

(InterProcess Communication)(InterProcess Communication)(Remote Procedure Call)(Remote Procedure Call)

오 상 규오 상 규

서강대학교 정보통신 대학원서강대학교 정보통신 대학원

Email : [email protected] : [email protected]

Page 2

InterProcess Communication - RPC

서강대학교 정보통신 대학원

Concept of Remote Procedure CallConcept of Remote Procedure CallConcept of Remote Procedure CallConcept of Remote Procedure Call

Concept of remote procedure call The procedures and the main form two separate executable entities. Need to have a communication substrate connecting these entities.

Main Program A

Addition

Procedure

Multiplication

Procedure

Addition

Procedure

Multiplication

Procedure

middleware

< Traditional Processing Model > < Remote Procedure Call >

Main Program A

Page 3



Advantage of Procedure CallAdvantage of Procedure CallAdvantage of Procedure CallAdvantage of Procedure Call

Procedure Addition(x,y,total);Start…….End

Program A

Start

……..

Call Procedure Addition(1,2,result);

……..

Call Procedure Multiplication(1,2,result);

……..

End

Procedure Multiplication(x,y,total);Start…….End

Application code(main and procedure) remains unchanged, whether the procedures are distributed or not.

Application contains no code related to the communications system.

Page 4



Main Components of RPCMain Components of RPCMain Components of RPCMain Components of RPC

Activated by the main program,

Its work consists of transferring

the name of the procedure and its parameters

Receives data and locally activates the procedure designated by passing the

received parameters to it

Main Program A

Client Stub

Addition

Client Stub

Multiplication

Server

Stub

Addition

Procedure

Multiplication

Procedure

Client Machine Server Machine

Network

Contract Generated By Interface Definition Language

(IDL)

Physically transfer the data from the client to the server

after Marshalling.

It calls a procedure locally.

In fact, it calls a client stub.

Return the result parameters

Page 5



RPC ClientRPC Client RPC ClientRPC Client

RPC client contains the distributed main program.

Client Stubs

A procedure that has the name of the real procedure that it replaces in order to:

Give the impression to the main program that the procedure which it calls is really local.

Replace the code of the real procedure by other code. This new code will handle the connection with the middleware bus in order to send call parameters for the procedure that it replaces to the machine where the procedure actually resides and to collect the parameters returned from the procedure.

Page 6



RPC ServerRPC Server RPC ServerRPC Server

RPC server contains the distributed procedures.

Server Stubs

A main program must exist.

Allows the creation of an executable containing the procedures that form the server.

Handles communication with the client stub in order to receive the name of the procedure to be called, as well as its call parameters.

As a function of the name of the procedure that was received, the server stub activates the designated procedure by passing to it the received parameters.

Page 7



Contract (1)Contract (1) Contract (1)Contract (1) In the RPC communication model, a contract is established for the same un

derstanding of exchanges between client and server.

The characteristics of contract are:

Identified by uuid (universal unique identifier) : used in each request.

It contains the signature of the services that the client requires.

Defines and names the interface offered by the server to this client.

An interface is a set of procedure signatures whose parameters are characterized by their mode of use.

Written in a IDL (Interface Definition Language).

The client and the server each receive a copy of the contract.

One forms the client stub, and the other forms the server stub.

Client and server stubs are sequences of code (most often in C).

Page 8



Contract (2)Contract (2) Contract (2)Contract (2)

Contract

/* OSF IDL RPC code */

[ uuid(xxxxxxx-xxxx-xxxx-xxxx) version (N.n) ]

Interface mathematics_server

{

int Addition ([in]int x,

[in] int y,

[out]int *sum);

int Multiplication ([in]int x,

[in] int y,

[out]int *product);

}

IDL

Compiler

Program main()

{

. . . . .

}

Procedure Addition()

{

}

Procedure Multiplication()

{

}

Server stub

Client stub

Page 9



Construction of Client and Server (1)Construction of Client and Server (1)Construction of Client and Server (1)Construction of Client and Server (1)

Main Program A

Addition

Client Stub

ContractMain Program A

Addition

Multiplication

Executables

Client Stub

Multiplication

Client Stub

Server Stub

Multiplication

Procedure

Addition

ProcedureServer

Stub

Compiler, Linker Compiler, Linker

IDL Compiler

1

2

Page 10



Construction of Client and Server (2)Construction of Client and Server (2)Construction of Client and Server (2)Construction of Client and Server (2)

Requires the programmer to develop three components:

the client, the server, and contract.

Previous Figure shows how to proceed when the three components are

available.

Step1 : Generate the client and server stubs (by IDL compiler).

Step2 : Construct the client executable.

(Compile the main and the client stubs, and link the two

object modules)

Step3 : Construct the server executable.

(Compile the server stubs and the procedures, and link the two

object modules)

1

2

2

Page 11



MarshallingMarshallingMarshallingMarshalling

An important function of client stub to construct the message that will be

sent to the server.

In this message, all the data is encoded in a standard form.

Representation difference between server and client platform.

Different standards exist:

1. OSF DCE RPC uses NDR (Network Data Representation)

2. Sun RPC uses XDR (eXternal Data Representation)

Page 12



Marshalling - XDRMarshalling - XDRMarshalling - XDRMarshalling - XDR

The XDR standard defines a machine-independent representation.

Penalty of performance

00‘y’‘a’‘d’

‘s’‘e’‘u’‘T’

07000000

0000‘y’‘a’

‘d’‘n’‘o’‘M’

06000000

02000000

50000000

40000000

30000000

40302000

XDR RepresentationValue

0x203040

Array of 3 integers

{0x30, 0x40, 0x50}

Variable length array of strings

{

“Monday”,

“Tuesday”

}

Page 13



Binding Binding Binding Binding

Name Server

Client Server

Stub Stub5

43 1

2

Associates a logical name with an entity’s physical

address (e.g., server port)

Server registers with the name server to declare to the name server its

physical address and the interfaces

Request to the name server for the physical address of a server,Providing it

with the name of the server and the number of the interface

Page 14



Implementation Issue: Locating the BinderImplementation Issue: Locating the BinderImplementation Issue: Locating the BinderImplementation Issue: Locating the Binder Always run the binder on a computer with a well known host address

and compile this host address into all client programs. All client and server programs must be recompiled if the binder ever needs to be relocated.

Make the client and server operating systems responsible for supplying the current host address of the binder at run time, for example in UNIX, it may be supplied via an environment variable. Users running client and server programs need to be informed whenever the binder is relocated. This method allows occasional relocation of the binder.

When a client or server program starts executing, it uses a broadcast message to locate the binder. For example, in UNIX, the broadcast message will specify the port number of the binder and a binder receiving such as request will reply with its current host address. The binder can be run on any computer and can easily be relocated.

Page 15



Implementation Issue: FailuresImplementation Issue: Failures Implementation Issue: FailuresImplementation Issue: Failures Unlike the local calls, failures of clients and servers do not always happen

together. Possible scenarios:

The network was slow and the client did not wait long enough. The initial message was lost. The server received the message, performed the request, and then

crashed. The server performed the service, but the acknowledgement was lost.

Most RPC implementations have an associated timeout value. However, it is hard to distinguish between network failure and server failure. Need calling semantics under failure.

Maybe semantics At Least Once semantics At Most Once semantics

Page 16



RPC Call SemanticsRPC Call Semantics RPC Call SemanticsRPC Call Semantics Maybe

No fault tolerance measure. Not certain that the procedure has been executed or not in error conditions (e.g., lost

reply message, server crash,etc.) Generally not acceptable.

At Least Once Continues to retry the call until it gets a response. Server may receive and execute the request more than once. When the RPC is completed, the client will not know how may times the server code has

been called.

At Most Once Filtering of duplicates and retransmission of replies without re-executing operations. Sequence # solution: Keeps track of sequence # and result of last request, and resends

the result when the same request comes in. In case of server crash ? Idempotent request solution: Same request can be re-executed without changing the

results. Clients need to keep track of server state. Usually chosen for most of the RPC implementations.

Page 17



Delivery GuaranteesDelivery GuaranteesDelivery GuaranteesDelivery Guarantees

At-most-once Retransmit reply Yes Yes

At-least-onceRe-execute procedure No Yes

Maybe Not applicableNot applicable No

RPC Call SemanticsRe-execute Procedure

or Retransmit Reply

Duplicate

Filtering

Retry Request

Message

Delivery Guarantees

Page 18



Example – SUN RPCExample – SUN RPCExample – SUN RPCExample – SUN RPC

Follow these steps in converting local calls to remote calls :

1. Get the program to work using local functions.

2. Create a specification file(IDL) having a .x extension.

3. Call rpcgen(IDL compiler) with the –a and –C options.

4. Before making any changes to the generated files, use the generated

makefile to compile them.

5. Insert the calling program into the _client.c file generated by rpcgen.

6. Insert the local function code into the _server.c file generated by rpcgen.

7. Try compiling the programs using the generated makefile.

8. Fiddle with the _server.c and _client.c sources until they work.

Page 19



Program (Pseudo-Random NumberProgram (Pseudo-Random Number))Program (Pseudo-Random NumberProgram (Pseudo-Random Number))

#include <stdio.h>

#include <stdlib.h>

int myseed;

int iters, i;

myseed = 3243;

iters = 10;

srand48(myseed); //initialize starting value

for (i = 0; i < iters; i++)

printf( “%d : %f\n”,i ,drand48() );

//return successive random values

Page 20



Creating Local Service (Procedure)Creating Local Service (Procedure) Creating Local Service (Procedure)Creating Local Service (Procedure)

#include “rand.h”

void initialize_random (long seed){

srand48(seed);

}

double get_next_random(void){

return drand48();

}

Page 21



A Program that Calls a Local ServiceA Program that Calls a Local ServiceA Program that Calls a Local ServiceA Program that Calls a Local Service#include <unistd.h>

#include <stdio.h>


void main(int argc, char *argv[ ]) {

int iters, i;

long myseed;

if (argc != 3) {

fprintf(stderr,”Usage: %s seed iterations\n”, argv[0]);

exit(1);

}

myseed = (long) atoi (argv[1]);

iters = atoi (argv[2]);

initialize_random(myseed);

for ( i=0; i < iters; i++)

printf(“%d : %f\n”, i, get_next_random() );

exit(0);

}

Page 22



The rand.x specification file (IDL)The rand.x specification file (IDL)The rand.x specification file (IDL)The rand.x specification file (IDL)

/* rand.x */

Program RAND_PROG {

version RAND_VERS {

void INITIALIZE_RANDOM(long) = 1; // Service number 1

double GET_NEXT_RANDROM(void) = 2; // Service number 2

} = 1; // Version number, typically start at 1

} = 0x31111111; // Program number: 20000000 ~ 3FFFFFFF -> defined by user

Function name are the same as those of the local functions except that they are all in uppercase.

Function are numbered, so that the initialize_random is service number 1,

Get_next_random is service number 2 within the server.

Page 23



Rpcgen OptionRpcgen Option Rpcgen OptionRpcgen Option

rpcgen infile

rpcgen [ -a ] [ -A ] [ -b ] [ -C ] [ -D name [ = value ] ]

[ -i size ] [-I [-K seconds ] ] [ -L ]

[ -M ] [ -N ] [ -T ] [ -Y pathname ] infile

rpcgen [ -c | -h | -l | -m | -t | -Sc | -Ss | -Sm ]

[ -o outfile ] [ infile ]

rpcgen [ -s nettype ] [ -o outfile ] [ infile ]

rpcgen [ -n netid ] [ -o outfile ] [ infile ]

-C option indicates ANSI C is used,

And the –a option tells rpcgen to generate all of the supporting files.

Page 24



Files generated by Files generated by rpcgen –C –a rand.xrpcgen –C –a rand.xFiles generated by Files generated by rpcgen –C –a rand.xrpcgen –C –a rand.x

rand.x

rand_client.c

rand_clnt.c

makefile.rand

rand.h

rand_xdr.c

rand_svc.c

rand_server.c

rpcgen

Server files

common files

client files

Server Stub

Client Stub

XDR types

Makefile

XDR Routines

Client Skeleton

Server Services

Page 25



rpcgen –C -a rand.xrpcgen –C -a rand.xrpcgen –C -a rand.xrpcgen –C -a rand.x

rpcgen –C –a rand.x

Generates the client and server programs from the rand.x

To convert the local service to a remote service, follow these steps:

1. Execute rpcgen to generate the needed files from the rand.x.

2. Modify the rand_client.c file to contain the client code.

3. Modify the rand_server.c file to contain the functions to be called remotely.

Page 26



The rand_client.c generated by rpcgen (1)The rand_client.c generated by rpcgen (1)The rand_client.c generated by rpcgen (1)The rand_client.c generated by rpcgen (1)#include “rand.h”

void rand_prog_1(char *host)

{

CLIENT *clnt;

void *ressult_1;

long initialize_random_1_arg;

double *result_2;

char *get_next_random_1_arg;

#ifndef DEBUG

clnt = clnt_create(host, RAND_PROG, RAND_VERS, “netpath”);

if ( clnt == (CLIENT *) NULL ) {

clnt_pcreateerror(host);

exit(1);

}

result_1 = initialize_random_1 (&initialize_random_1_arg, clnt); // Call to remote procedure

if ( result_1 == (void *) NULL ) {

clnt_perror(clnt, “call failed”);

}

// Create socket and a client handle

Page 27



The rand_client.c generated by rpcgen (2)The rand_client.c generated by rpcgen (2)The rand_client.c generated by rpcgen (2)The rand_client.c generated by rpcgen (2)result_2 = get_next_random_1( (void *) &get_next_random_1_arg, clnt);

if (result_2 == (double *)NULL) {


}

#ifndef DEBUG

clnt_destroy(clnt);

#endif /* DEBUG */

}

main(int argc, char *argv[])

{

char *host;

if ( argc < 2 ) {

printf(“usage: &s server_host\n”, argv[0]);

exit(1);

}

host = argv[1];

rand_prog_1(host);

}

Page 28



Revised rand_client.c program (1)Revised rand_client.c program (1)Revised rand_client.c program (1)Revised rand_client.c program (1)

#include <stdlib.h>

#include <stdio.h>


void main(int argc, char *argv[ ])

{

int iters,i;

long myseed;

CLIENT *clnt;

void *result_1;

double *result_2;

char *arg;

if ( argc != 4 ) {

fprintf(stderr, “Usage: %s host seed iterations\n”, argv[0]);

exit(1);

}

clnt = clnt_create(arvg[1],RAND_PROG,RAND_VERS,”netpath”); // Create socket and a client handle

Page 29



Revised rand_client.c program (2)Revised rand_client.c program (2)Revised rand_client.c program (2)Revised rand_client.c program (2)

myseed = (long) atoi (argv[2]);

iters = atoi (argv[3]);

result_1 = initialize_random_1(&myseed, clnt); // Call to remote initialize_random procedure

if (result_1 == (void *) NULL) {


}

for( i=0; i<iters; i++) {

result_2 = get_next_random_1((void *)&arg, clnt);

if (result_2 == (double *) NULL) {


}else printf(“%d : %f\n”, I, *result_2);

}

clnt_destory(clnt);

exit(0);

}

Page 30



The Skeleton of rand_server.c by rpcgenThe Skeleton of rand_server.c by rpcgenThe Skeleton of rand_server.c by rpcgenThe Skeleton of rand_server.c by rpcgen


void *

initialize_random_1_svc(long *argp, struct svc_req *rqstp)

{

static char *result;

// insert server code here

return((void *) &result);

}

double *

get_next_random_1_svc(void *argp, struct svc_req *rqstp)

{

static double result;

//insert server code here

return (&result);

}

Page 31



The Server Program (Final Version)The Server Program (Final Version)The Server Program (Final Version)The Server Program (Final Version)

#include <stdlib.h>


void *

initialize_random_1_svc(long *argp, struct svc_req *rqstp) {

static char *result;

srand48(*argp);

result = (void *) NULL;

return (void *) &result;

}

double *

get_next_random_1_svc(void *argp, struct svc_req *rqstp){

static double result;

result = drand48();

return (&result);

}

Page 32



Producing ExecutablesProducing ExecutablesProducing ExecutablesProducing Executables

Use the makefile generated by rpcgen to produce executables for the client

and the server.

- make –f makefile.rand

The following command registers the pseudorandom-number server

- rand_server

After execution of the command above, rand_server service is registered on

the current host and ready to receive remote requests.

Documents

Distributed Processing Systems (InterProcess Communication) (Remote Procedure Call) Distributed Processing Systems (InterProcess Communication) (Remote