This document provides an overview of distributed objects and remote invocation. It discusses RPC/RMI models and implementation issues like parameter passing semantics and invocation semantics. It also covers stateless/stateful servers, server creation semantics, SunRPC, and Java RMI. SunRPC is described in more detail including interface definition, client and server code examples. Java RMI is compared to SunRPC and its mechanism involving proxies, skeletons, and the RMI registry is outlined.

1. Distributed Objects and Remote
Invocation
Unit-3
Prof. Mayank Jain
CSS434 RMI 1

2. CSS434 RMI 2
Outline
 RPC/RMI Model
 Implementation Issues
 Parameter-passing semantics
 Invocation semantics
 Stateless/stateful server
 Server creation semantics
 SunRPC
 Java RMI

3. Why RPC/RMI
Calling a function/method at a remote server:
 Advanced form of communication
 Sockets and MPI: data transfer
 RPC/RMI: control transfer
 Transparency in function calls
 No distinguish between local and remote calls (in
theoretical)
 Also applied to IPC on the same machine
CSS434 RMI 3
 Ease of use
 Compiled-time argument type checking
 Automatic stub generation

4. Remote and Local
Method/Function Invocation
invocation invocation
remote
invocation
CSS434 RMI 4
remote
invocation
local
local
local
invocation
A
B
C
D
E
F

5. Service Interface and Remote
Interface
RPC: an service interface defined with an XDR file
struct doubles { double a; double b; };
program EXAMPLE_PROG {
remoteobject
CSS434 RMI 5
remote
interface
m
1m2
m3
m4
m5
m6
Data
implementation
{ of methods
RMI: a remote interface defined by extending the “Remote” interface
Interface MyRmoteInterface extends Remote {
ReturnClass1 m1( ArgClass1 arg ) throws RemoteException;
ReturnClass2 m2( ArgClass2 arg ) throws RemoteException;
ReturnClass3 m3( ArgClass3 arg ) throws RemoteException;
}
version EXAMPLE_VERS {
int FACT( int ) = 1; /* procedure number = 1 */
double POWER( doubles ) = 2; /* procedure number = 2 */
} = 1; /* version number = 1 */
} = 0x31234567; /* program number = 0x31234567 */

6. RPC/RMI Model
Caller (Client) Callee (Server)
RPC and wait Request message
including arguments
Reply message
Including a return value
CSS434 RMI 6
Suspended
Resume execution
Request message accepted
Execution environment created
Execution of function body
Send reply and wait for the next
request

7. Implementation Issues
CSS434 RMI 7
 Transparency property
 Syntactic transparency
 Semantic transparency
 Analogy in semantics b/w local and remote procedure calls
 Caller capable of passing arguments (Automatic marshalling)
 Caller suspended till a return from a function
 Callee capable of returning a value to caller
 Difference in semantics b/w local and remote procedure calls
 No call by reference and no pointer-involved arguments
 Error handling required for communication (Ex. RemoteException in
Java)
 Performance much slower than local calls.

8. Parameter-Passing Semantics
 Call by Value
 Most PRCs take this semantics.
 Voluminous data incurs copying overhead.
 Call by Reference
 Passing pointers and references are
meaningless.
 Then, how about object-based systems?
 The value of a variable is a reference
to an object
 Call by object reference
 Additional remote object invocations
 Call by visit: all related objects moved
to a server every RPC.
 Call by move: all related objects moved
and left to a server upon the first RPC.
CSS434 RMI 8
Client Server
class objA {
objB b;
objC c;
}
class objB {
}
class objC {
}

9. Invocation Semantics
Fault tolerance measures Invocation
semantics
Maybe
At-least-once
CSS434 RMI 9
Retransmit request
message
Duplicate
filtering
Re-execute procedure
or retransmit reply
No
Yes
Yes
Not applicable
No
Yes
Not applicable
Re-execute procedure
Retransmit reply At-most-once

10. Stateful/Stateless Servers
CSS434 RMI 10
 Stateful servers:
 Servers keep track of client information.
 RPC/RMI reply depends on that client information.
 Pros: Simplify client design
 Cons: A server crash loses client information. A client crash leaves
old client information at server.
 At-most-once invocation semantics (Java RMI takes this design.)
 Stateless servers:
 Clients must maintain Inter-call information.
 RPC/RMI reply is always the same.
 At-least-once invocation semantics (Some RPC implementations
take this design.)

11. Server Creation Semantics
CSS434 RMI 11
 Instance-per-Call Servers
 A new server process launched every call
 Statelss servers only
 OS resource allocation/de-allocation involved every call
 Instance-per-Session Servers
 A server process maintained for the entire session with a client
 Stateful servers: inter-call state maintained for a single client
 OS resource allocation/de-allocation involved every session
 Persistent Servers
 A server process remains in existence indefinitely.
 Stateful and shared servers: concurrency control required
 OS resource allocation/de-allocation involved only once.
 SunRPC/Java RMI take instance-per-call servers, while a thread but not
a process is created per a call. (The server process must remain active
to accept a new call and thus can still be stateful.)

12. RPC Mechanism
Interface Definition Language
File
Client Program Server Program
(5) Exception?
(4) Invalid arguments?
(3) Invalid procedure?
RPC Runtime (Dispatcher)
(2) Unauthorized client?
CSS434 RMI 12
Return Call
Receive Send
Define arguments
Register remote functions
Client Stub
IDL Compiler
Message
Decoding Encoding
marshaling
RPC Runtime
Retransmission
acknowledgments
Routing
encryption
Return Call
Server Stub
Message
Decoding Encoding
Receive Send
(1) Intelligible messages?
msg id
type
(call)
args PRC id client id
type
(reply)
reply
status
fesults
failur
msg id

13. Client-Server Binding
(SunRPC)
Client Machine Server Machine
(2) Locating server
(3) Server port (xxx)
write(), read(),
Sendto(), recvfrom()
TCP or UDP Transport level or below TCP or UDP
 (1) pmap_set(prognum, versnum, protocol, port)
 (2) and (3) pmap_getport(addr, prognum, versnum, protocol)
 To check the status of portmap, rpcinfo
CSS434 RMI 13
Client
Portmap
Daemon
Server
Network (LAN/WAN)
write(), read(),
Sendto(), recvfrom()
(1) register
(4) RPC with port xxx
port: 111
port: xxx

14. example_client.o
Modify by yourself
CSS434 RMI 14
SunRPC
example_client.c
rpcgen –a example.x Your client
example_clnt.c
Client stub
example_h.c
example_xdr.c
example_svc.c
example_server.c
example_clnt.o
example_xdr.o
example_svc.o
example_server.o
example.x
example_client
example_server
Marshalling
Server stub
Your server
gcc –c -o
Header ld -o
Modify by yourself
Interface
descriptions
Client program
Server program

15. Sun RPC (Interface definition)
/*
* example.x - Speicification of some arithmetic/string service.
* Define 2 procedures:
* fact( int n ) returns n!.
* power( double x, double y ) returns x^^y.
* strconc( struct strings ) concatenates src to dest.
*/
CSS434 RMI 15
const BUFFER_SIZE = 1024;
struct doubles {
double a;
double b;
};
struct strings {
char src[BUFFER_SIZE];
char dst[BUFFER_SIZE];
};
program EXAMPLE_PROG {
version EXAMPLE_VERS {
int FACT( int ) = 1; /* procedure number = 1 */
double POWER( doubles ) = 2; /* procedure number = 2 */
string STRCONC( strings ) = 3; /* procedure number = 3 */
} = 1; /* version number = 1 */
} = 0x31234567; /* program number = 0x31234567 */

16. Sun RPC (Client)
CSS434 RMI 16
#include "example.h"
void example_prog_1(char *host)
{
CLIENT *clnt;
int *result_1;
int fact_1_arg;
double *result_2;
doubles power_1_arg;
char * *result_3;
strings strconc_1_arg;
clnt = clnt_create (host, EXAMPLE_PROG, EXAMPLE_VERS, "udp");
if (clnt == NULL) {
clnt_pcreateerror (host);
exit (1);
}
fact_1_arg = 10;
result_1 = fact_1(&fact_1_arg, clnt);
if (result_1 == (int *) NULL) {
clnt_perror (clnt, "call failed");
}
printf( "fact( 10 ) = %dn", *result_1 );
power_1_arg.a = 2.0;
power_1_arg.b = 6.0;
result_2 = power_1(&power_1_arg, clnt);
if (result_2 == (double *) NULL) {
clnt_perror (clnt, "call failed");
}
printf( "power( 2.0, 6.0 ) = %fn", *result_2 );
strncpy( strconc_1_arg.dst, "xyz0", BUFFER_SIZE );
strncpy( strconc_1_arg.src, "abc0", BUFFER_SIZE );
result_3 = strconc_1(&strconc_1_arg, clnt);
if (result_3 == (char **) NULL) {
clnt_perror (clnt, "call failed");
}
printf( "strconc( "xyz", "abc" ) = %sn", *result_3 );
clnt_destroy (clnt);
}
int
main (int argc, char *argv[])
{
char *host;
if (argc < 2) {
exit (1);
host = argv[1];
example_prog_1 (host);
exit (0);
}

17. Sun RPC (Server)
CSS434 RMI 17
#include "example.h"
#include <math.h>
#include <string.h>
int *
fact_1_svc(int *argp, struct svc_req *rqstp)
{
static int result;
int i;
result = 1;
for ( i = *argp; i > 0; i-- )
result *= i;
return &result;
}
double *
power_1_svc(doubles *argp, struct svc_req *rqstp)
{
static double result;
result = pow( argp->a, argp->b );
return &result;
}
char **
strconc_1_svc(strings *argp, struct svc_req *rqstp)
{
static char * result;
result = strcat( argp->dst, argp->src );
return &result;
}

18. SunRPC v.s. Java RMI
SunRPC Java RMI
Advantages Template generation
Dynamic port assignment
High performance
Automatic serialization
Manual IP port handling
Good security
Disadvantages Manual serialization
CSS434 RMI 18
Weak to hackers
Low performance

19. RMI Mechanism
skeleton
Convert object/method/arguments in a TCP
message.
object A object B
Request
& dispatcher
for B’s class
CSS434 RMI 19
proxy for B
Reply
Remote Communication Communication Remote reference
reference module module module module
remote
client server
Exchange a request and a replay in TCP.
Maintain a table of local objects and their
remote object references (i.e., object proxies).
Find the corresponding remote object,
unmarshal arguments, and invoke the object.

20. Java RMIregistry
void rebind (String name, Remote obj)
This method is used by a server to register the identifier of a remote object by
name, as shown in Figure 15.13, line 3.
CSS434 RMI 20
void bind (String name, Remote obj)
This method can alternatively be used by a server to register a remote object
by name, but if the name is already bound to a remote object reference an
exception is thrown.
void unbind (String name, Remote obj)
This method removes a binding.
Remote lookup(String name)
This method is used by clients to look up a remote object by name, as shown
in Figure 15.15 line 1. A remote object reference is returned.
String [] list()
This method returns an array of Strings containing the names bound in the
registry.

21. RMI
Programming Procedure
(2) Program a Server.java class
(4) Program a Client.java class
(5) javac Client.java
(7) Run Server with java Server
(8) Run Client with java Client
Application Layer: Client .java Server.java
(implements remote interface)
Stub/Skeleton: Stub Skeleton
(1) Define a remote interface
(3) javac Server.java
rmic Server
Server_Stub.class Server_Skel.class
(6) Invoke a rmiregistry
Remote Reference: rmiregistry [port#]
(object manager/name service)
request and result
Transport Layer: TCP/IP
CSS434 RMI 21

22. RMI
Remote Interface & Return Object
// Remote interface: A server must implements this interface in its class define
import java.rmi.*
public interface ServerInterface extends Remote {
public ReturnObj get( ) throws RemoteException; // A server returns a ReturnObj to a client
CSS434 RMI 22
}
// Define the class of a object returned from a server to a client (ReturnObj)
import java.io.*
import java.util.*
public class ReturnObj implements Serializable { // A return object must be serializable.
private id;
SubObject subObj;
public ReturnObj( int i, SubObject s ) {
id = i;
subObj = s;
}
public void print( ) throws IOException { System.out.println( “ReturnObj: id=“ + id ); }
}

23. RMI
Server Implementation
CSS434 RMI 23
import java.io.*;
import java.util.*;
import java.rmi.*;
import java.rmi.server.*;
public class Server extends UnicastRemoteObject implements ServerInterface {
static private int i = 0;
public Server( ) throws RemoteException{
}
public static void main( String args[] ) {
try {
Server server = new Server( );
Naming.rebind( “server”, server );
} catch ( Exception e ) {
System.err.println( “Exception: “ + e );
System.exit( 1 );
}
}
public ReturnObject get( ) throws RemoteException {
ReturnObject f = new ReturnObject( i++, new SubObject( i ) );
return f;
}
}
(1) Implement a remote interface
(2) Inherit a RemoteObject
(3) Define a constructor
(4) Instantiate a RemoteObject
(5) Implement all methods declared in a remote interface

24. RMI
Client Implementation
CSS434 RMI 24
Import java.rmi.*;
Import java.io.*;
public class Client {
public static void main( String[] args ) {
try {
ServerInterface si = (ServerInterface)Naming.lookup( “rmi://adonis1/server” );
ReturnObject f = si.get( );
f.print( );
f.subObj.print( );
} catch ( RemoteException re ) {
System.out.println( “Exception : “ + re );
System.exit( 1 );
} catch ( IOException ie ) {
System.out.println( “Exception : “ + ie );
System.exit( 1 );
} catch ( NotBoundException nbe ) {
System.out.println( “Exception : “ + nbe );
System.exit( 1 );
}
}
}
(1) RMI registry returns a reference to RemoteObject
(2) Call a method of this RemoteObject
(3) Exception handling for RMI
(4) Exception handling for I/O
(5) Exception handling for Naming

25. RMI
Compilation and Execution
% javac ReturnObject.java // Compile a return class
% javac Server.java // Compile a server class
% rmic Server // Create a stub and a skelton
% javac Client.java // Compile a client class
% ls
ReturnObject.java ReturnObject.class Server.java
Server.class Server_Stub.class Server_Skel.class
% rmiregistry& // Invoke RMI registory
% java Server& // Invoke a server
% java Client // Invoke a client
ReturnObject id = 0
SubObject id = 1
% java Client // Invoke a client again
ReturnObject id = 2
SubObject id = 3
%
CSS434 RMI 25

26. Exercises (No turn-in)
1. The caller process of an RPC/RMI must wait for a reply from the callee process after
making a call. Explain how this can actually be done.
2. Which types of server did you implement for the programming assignments 3 and 4, a
stateful or a stateless server? Then, why did you implement such a type of server?
3. Discuss the similarities and differences among the following parameter passing:
CSS434 RMI 26
1. Call-by-object-reference
2. Call-by-move
3. Call-by-visit
4. Discuss about the pros and the cons of dynamic binding in RPC.
5. Textbook p227, Q5.12: Discuss the invocation semantics that can be achieved when the
request-reply protocol is implemented over a TCP connection, which guarantees that data
is delivered in the order sent, without loss or duplication. Take into account all of the
conditions causing a connection to be broken.
6. Textbook p227, Q5.14: The Election service must ensure that a vote is recorded
whenever any user thinks they have cast a vote. Discuss the effect of maybe call
semantics on the Election service. Would at-least-once call semantics be acceptable for
the Election service or would you recommend at-most-once call semantics?

27. Exercises (No turn-in)
7. Textbook p227, Q5.15: A request-reply protocol is implemented over a communication
service with omission failures to provide at-least-once RMI invocation semantics. In the
first case the implementor assumes an asynchronous distributed system. In the second
case the implementor assumes that the maximum time for the communication and the
execution of a remote method is T. In what way does the latter assumption simplify the
implementation?
8. Textbook p228, Q5.22: A client makes remote procedure calls to a server. The client
takes 5 milliseconds to compute the arguments for each request, and the server takes 10
milliseconds to process each request. The local operating system processing time for each
send or receive operation is 0.5 milliseconds, and the network time to transmit each
request or reply message is 3 milliseconds. Marshalling or unmarshalling takes 0.5
milliseconds per message.
Calculate the time take by the client to generate and return from two requests:
(i) if it is single-threaded, and
(ii) if it has two threads that can make requests concurrently on a single processor.
You can ignore context-switching times.
CSS434 RMI 27