RPCs Steps in one RPC an early middleware model. Its an extension - - PowerPoint PPT Presentation

1

RPCs

an early middleware model. It’s an extension of local

procedure calling.

Programs are organized as a set of modules. Each module

defines its interface: procedures variables.

Advantage of communicating through interface, is that

programmer can update the implementation, keep its interface, and don’t need to update the implementation in

• ther modules.

Direct variable access is not allowed in distributed situation. RPC vs. LPC:

Error handling: In RPC, failures of the remote server and

failures of network.

Performance: RPCs operate much slower than LPCs. Authentication: insecure networks, authentication is

necessary.

RPC uses client/server model Service interface response-based transient synchronous communication Remote procedures appear local through stub functions. Two stubs: client stub and server stub. In RPC, stubs are compiled and linked with the applications.

Steps in one RPC

Before call a remote procedure, client initiates a connection to

server.

When client process calls a remote procedure, client stub:

Retrieves the required parameters from the client address space. Translates the parameters into a standard network data

representation (NDR) format for transmission over the network.

Calls functions in the RPC client run-time library to send the

request and its parameters to the server.

At the server side,

The server RPC run-time library functions accept the request

and call the server stub procedure.

The server stub retrieves the parameters from the network buffer

and converts them from the network transmission format to the format the server needs.

The server stub calls the actual procedure on the server. After the remote procedure returns its data to the server stub, the

server stub converts return value to the network message and call the RPC run-time library functions.

The server RPC run-time library functions transmit the reply

message to the client computer.

At the client side,

The client RPC run-time library receives the return values and

returns them to the client stub.

The client stub converts the data into the format used by the

• client. The stub returns the result to the calling program.

The calling procedure continues.

2

Sun RPC Version 2

A server may support more than one version of a remote

program in order to be compatible with changing protocols.

Transport protocols

RPC is transport independent and RPC does not try to

implement any kind of reliability.

The application may need to know the type of transport

protocol underneath RPC: message size, semantics.

The client and server must agree on their transport

protocol choices.

Requirement of RPC protocol:

Unique specification of a remote procedure. Matching reply messages to call messages. Authenticating the client to server and authenticating

server to client.

Failure reasons:

• RPC protocol mismatches.
• Remote program protocol version mismatches.
• Misspecification of a procedure's parameters.
• Reasons why remote authentication failed.
• Other reasons why the desired procedure was not

called.

RPC message

written in Interface definition language (IDL), also called

RPC language

transaction identifier, xid.

used for client RPC layer to matching reply messages

with call messages, and may be used by server process to detect retransmissions.

Body of an RPC call message:

RPC version number: always equal to 2 here. Remote program number: (in hexadecimal)

• 0 - 1fff,ffff defined by Sun
• 2000,0000 - 3fff,ffff defined by user
• 4000,0000 - 5fff,ffff transient.
• 6000,0000 – ffff,ffff reserved.

Remote program version number Remote procedure number two authentication fields: the credential and verifier the procedure parameters

Body of a reply message

Requirement: contain enough information to distinguish

different error conditions

accepted reply message or rejected reply message

3

struct accepted_reply {

• paque_auth verf;

union switch (accept_stat stat) { case SUCCESS: /* * procedure-specific results start here */ case PROG_MISMATCH: struct { unsigned int low; unsigned int high; } mismatch_info; default: /* * Void. Cases include PROG_UNAVAIL, PROC_UNAVAIL, * and GARBAGE_ARGS. */ void; } reply_data; }; enum accept_stat { SUCCESS = 0, /* RPC executed successfully */ PROG_UNAVAIL = 1, /* remote hasn't exported program */ PROG_MISMATCH = 2, /* remote can't support version # */ PROC_UNAVAIL = 3, /* program can't support procedure */ GARBAGE_ARGS = 4 /* procedure can't decode parameters */ };

enum reject_stat { RPC_MISMATCH = 0, /* RPC version number != 2 */ AUTH_ERROR = 1 /* remote can't authenticate caller */ }; union rejected_reply switch (reject_stat stat) { case RPC_MISMATCH: struct { unsigned int low; unsigned int high; } mismatch_info; case AUTH_ERROR: auth_stat stat; };

enum auth_stat { AUTH_BADCRED = 1, /* bad credentials (seal broken) */ AUTH_REJECTEDCRED = 2, /* client must begin new session */ AUTH_BADVERF = 3, /* bad verifier (seal broken) */ AUTH_REJECTEDVERF = 4, /* verifier expired or replayed */ AUTH_TOOWEAK = 5 /* rejected for security reasons */ };

4

Other Uses of RPC Protocol

Batching:

a client sends a large sequence of call messages to a server. The

client doesn’t wait for a reply from the server, and the server does not send replies to batch calls. A sequence of batch calls is terminated by a simple remote procedure call operation. And server will send a reply message to that last call message.

Broadcast:

the client sends a broadcast call to the network and waits for

numerous replies. Servers that support broadcast protocols only reply when the call is successfully processed, and not reply if some error happens. Broadcast calls use the Port Mapper RPC service.

DES Authentication Verifiers

Content: an encrypted timestamp Rules:

The server can decrypt this timestamp If it is close to the real time, then the client must have

encrypted it correctly.

The only way the client could encrypt it correctly is to

know the "conversation key“ K.

If the client knows K, then it must be the real client.

K is generated by the client, and client sends it to the server in

its first RPC call, using a public key scheme. (Diffie-Hellman with 192-bit keys, next week)

agree on the current time

Network Time Protocol a simple time request

1st transaction: the client sends an encrypted timestamp and

"window" to the server.

Additional check in 1st transaction: the client sends an

encrypted "window verifier", equal to the window minus 1.

For any other transaction, the server checks for two things: (1)

the timestamp is greater than the previous one. (2) compare current real time with the timestamp plus window.

The client check the verifier returned from the server: the

encrypted timestamp minus one second.

5

Portmapper program protocol

Broadcasting PMAPPROC_CALLIT: allows a client to call a remote

procedure without knowing its port number. broadcasting.

Its parameters are the program number, version number,

procedure number, and parameters of the remote procedure.

Note that:

• This procedure only sends a reply if the procedure was successfully

executed.

• The portmapper communicates with the remote program using

UDP only.

• The procedure returns the remote program's port number, and the

reply message from the remote procedure.

Steps for Sun RPC

Define the RPC Interface in a .x file. Such as MyRPCService.x Use rpcgen to compile the .x file: % rpcgen MyRPCService.x. Code the server implementation: you can use implementation template

and fill in the details.

Build the server: compile server stub, server implementation and link to

RPC library to build an executable file.

Write a client: establish a connection to corresponding server process

via clnt_create. Then, compile & link the client implementation and client stub.

Run server and client

struct mapping { unsigned int prog; unsigned int vers; unsigned int prot; unsigned int port; };

A mapping of (program, version, protocol) to port number const PMAP_PORT = 111; /* port number of port mapper */

const IPPROTO_TCP = 6; /* protocol number for TCP/IP */ const IPPROTO_UDP = 17; /* protocol number for UDP/IP */ program PMAP_PROG { version PMAP_VERS { bool PMAPPROC_SET(mapping) = 1; bool PMAPPROC_UNSET(mapping) = 2; unsigned int PMAPPROC_GETPORT(mapping) = 3; pmaplist PMAPPROC_DUMP(void) = 4; call_result PMAPPROC_CALLIT(call_args) = 5; } = 2; } = 100000;

Portmapper procedures

struct call_args { unsigned int prog; unsigned int vers; unsigned int proc;

• paque args<>;

}; struct call_result { unsigned int port;

• paque res<>;

}; How to broadcast messages to multiple instances of a service on different machines?

6

Object model, distributed object model

Program, object The state of an object: values of its instance

variables.

• bject references, Object interface

Actions: initiated by an object to invoke a

method in another object.

Three effects.

Garbage collection: to provide a way to free

the space occupied by unused objects.

RMI vs. Local method invocation Remote objects, remote object interface,

remote object reference.

Activation of remote objects

Active remote objects, passive remote objects

Java RMI

locate remote objects: obtain a reference to the object. two mechanisms

register its remote objects with RMI's simple naming

facility: rmiregistry

pass and return remote object references

java.rmi.Naming

bind(String name, Remote obj) lookup(String name): rmi://host:port/objectname

• default port: 1099

One difference between RPC stubs and RMI stubs:

In RPC, stubs are compiled and linked with the client

• application. RMI stubs need not be compiled into the

client; it can be downloaded at runtime.

Some advantages of Java RMI

Object oriented Mobile behaviour or dynamic invocation Safe and secure Distributed Garbage Collection

• reference-counting algorithm
• request-reply way with at-most-once invocation

semantics

Write once, Run Anywhere

7

Steps for use RMI to develop a distributed application

Design and implement the components of your

distributed application

Defining and implementing the remote

interfaces

Implementing remote objects Implementing the clients

Compile sources and generate stubs. Make classes network accessible. Start the application

To start the registry

• Windows users:-start rmiregistry (in java\bin

directory) ;

• Unix users:-rmiregistry &

To start the server:- java SumServiceServer To start the client: java SumServiceClient

localhost

Example: a service that calculate sum of two

integers.

import java.rmi.*; public interface SumService extends java.rmi.Remote{ // Calculate the sum of two integers public int sum ( int number1, int number2 ) throws RemoteException; } import java.rmi.*; import java.rmi.server.*; public class SumServiceServer extends UnicastRemoteObject implements SumService{ public SumServiceServer () throws RemoteException { super(); } // Calculate the sum of two integers public int sum ( int number1, int number2 ) throws RemoteException { return (number1 + number2); } public static void main ( String args[] ) throws Exception { // Create an instance of our sum service server ... SumServiceServer svr = new SumServiceServer(); // ... and bind it with the RMI Registry Naming.bind ("SumService", svr); } }

8

import java.rmi.*; import java.rmi.Naming; import java.io.*; // SumServiceClient public class SumServiceClient { public static void main(String args[]) throws Exception { PowerService service = (PowerService) Naming.lookup ("rmi://" + args[0] + "/PowerService"); DataInputStream din = new DataInputStream (System.in); for (;;) { System.out.println("1 - Calculate sum"); System.out.println("2 - Exit"); System.out.println(); System.out.print("Choice : "); String line = din.readLine(); Integer choice = new Integer(line); int value = choice.intValue(); switch (value) { case 1: System.out.print ("Value1 : "); line = din.readLine(); choice = new Integer (line); value = choice.intValue(); System.out.print ("value2 : "); line = din.readLine(); choice = new Integer (line); int power = choice.intValue(); System.out.println("Answer : " + service.sum(value1, value2)); break; case 2: System.exit(0); default : System.out.println ("Invalid option"); break; } // End of switch } // End of for loop } // End of main method } // End of SumServiceClient.