Lecture 5:
RPC and Distributed Objects
Haibin Zhu, PhD.
Assistant Professor
Department of Computer Science
Nipissing University
© 2002
Contents
 RPC (Remote Procedure Calling)
 Distributed objects
 RMI (Remote Method Invocation)
2
Remote Procedure Call (RPC)




Paradigms in building distributed applications
The RPC model
Primitives
Issues
3
Building Distributed Programs: Two Paradigms
 Communication-Oriented Design
– – Start with communication protocol
– – Design message format and syntax
– – Design client and server components by specifying how they react to
incoming messages
 Application-Oriented Design
– – Start with application
– – Design, build, test conventional implementation
– – Partition program
 Problems
–
–
–
–
• Protocol-design problems
• Application components as finite state machines !?
• Focus on communication instead of application!
• Concurrency
4
5
RPC Properties





Uniform call structure
Type checking
Full parameter functionality
Distributed binding
Recovery of orphan computations
6
RPC Primitives
 Invocation at caller side
– call service (value_args; result_args);
 Definition at server side
– declaration
 remote procedure service (in value_pars; out result_pars);
 begin body end;
7
8
RPC Issues
 Parameter passing
– value parameters
– reference parameters?
 Marshalling
– simple data types
– complex data structures
 Exception handling
– language dependent
– need to deal with asynchronous events
9
Locating Servers
 Broadcast requests
– – broadcast call and
process incoming replies
 Name servers
– – server registers with name server
 Combination: publish/subscribe
10
Communication Protocols for RPC
Complicated Call
• long gaps between requests
• acknowledge each message

transmission separately
– Simple Call
or
• periodically send “I-am-alive”
message and use simple-call
scheme.
• long messages (don’t fit into
•Client times out and retransmits request. packet)
• segment message
•Three cases:
• segment-relative seq #’s
•request lost
• retransmission scheme for
•server still executing
segments
•ack lost


Reliable protocols: e.g. TCP
Unreliable datagram protocols: e.g.
UDP
Specifically designed protocols:
Example
11
RPC in Heterogeneous Environments





Compile-time support
Binding protocol
Transport protocol
Control protocol
Data representation
12
Case Study: SUN RPC
• Defines format for messages, arguments, and results.
• Uses UDP or TCP.
• Uses XDR (eXternal Data Representation) to represent
procedure arguments and header data.
• Compiler system to automatically generate distributed
programs.
• Remote execution environment: remote program.
• Mutually exclusive execution of procedure in remote program.
13
Identifying Remote Programs and Procedures
 • Conceptually, each procedure on a computer is identified by
 pair :
 (prog, proc)
– – prog: 32-bit integer identifying remote program
– – proc: integer identifying procedure
 • Set of program numbers partitioned into 8 sets.
–
–
–
–
0x00000000 - 0x1fffffff assigned by SUN
0x20000000 - 0x3fffffff assigned by local system manager
0x40000000 - 0x5fffffff temporary
0x60000000 - 0xffffffff reserved
 • Multiple remote program versions can be identified:
– (prog, version, proc)
14
Communication Semantics











• TCP or UDP ?
• Sun RPC semantics defined as function of underlying
transport protocol.
– RPC on UDP: calls can be lost or duplicated.
• at-least-once semantics if caller receives reply.
• zero-or-more semantics if caller does not receive reply.
• Programming with zero-or-more semantics: idempotent
procedure calls.
• Sun RPC retransmission mechanism:
– non-adaptive timeouts
– fixed number of retransmissions
15
16
17
Message Dispatch for Remote Programs
18
Specification
for rpcgen
Specify:
• constants
• data types
• remote programs,
their procedures,
types of parameters



















/* rdict.x */
/* RPC declarations for dictionary program */
const MAXWORD = 50;
const DICTSIZ = 100;
struct example { /* unused; rpcgen would */
int exfield1; /* generate XDR routines */
char exfield2; /* to convert this structure.*/
};
/* RDICTPROG: remote program that provides
insert, delete, and lookup */
program RDICTPROG { /* name (not used) */
version RDICTVERS { /* version declarat.*/
int INITW(void) = 1;/* first procedure */
int INSERTW(string)= 2;/* second proc.... */
int DELETEW(string)= 3;
int LOOKUP(string) = 4;
} = 1; /* version definit.*/
} = 0x30090949; /* program no */
/* (must be unique)*/
19
20
Distributed object model
 Remote object reference: an identifier that can be
used throughout a distributed system to refer to a
particular unique remote object.
21
Distributed object model
Figure 5.3
local
remote
invocation
A
B
C
local E
invocation
invocation
local
invocation
D
remote
invocation
F
 each process contains objects, some of which can receive remote
invocations, others only local invocations
 those that can receive remote invocations are called remote objects
 objects need to know the remote object reference of an object in another
process in order to invoke its methods. How do they get it?
 the remote interface specifies which methods can be invoked remotely
•
22
Figure 5.4
A remote object and its remote interface
remoteobject
remote
interface
{
Data
m1
m2
m3
implementation
of methods
23
m4
m5
m6
Invocation semantics
 Local invocations are executed exactly once
 Remote invocations cannot achieve this. Why not?
– the Request-reply protocol can apply fault-tolerance measures
Figure 5.5
Fault tolerance measures
Retransmit request
message
Duplicate
filtering
Invocation
semantics
Re-execute procedure
or retransmit reply
No
Not applicable
Not applicable
Yes
No
Re-execute procedure
At-least-once
Yes
Yes
Retransmit reply
At-most-once
24
Maybe
•
Invocation semantics: failure model
 Maybe, At-least-once and At-most-once can suffer from crash
failures when the server containing the remote object fails.
 Maybe - if no reply, the client does not know if method was
executed or not
– omission failures if the invocation or result message is lost
 At-least-once - the client gets a result (and the method was
executed at least once) or an exception (no result)
– arbitrary failures. If the invocation message is retransmitted, the remote object
may execute the method more than once, possibly causing wrong values to
be stored or returned.
– if idempotent operations are used, arbitrary failures will not occur
 At-most-once - the client gets a result (and the method was
executed exactly once) or an exception (instead of a result, in
which case, the method was executed once or not at all)
•
25
RMI (Remote Method Invocation)
 Communication Module
 Remote reference module
 RMI software
– Proxy: make RMI transparent
– Dispatcher: receives the request message from the communication
module, use methodId to select and pass the request
– Skelton: implements the methods in the remote interfaces.
 Generation of RMI software: by rmic
 Server and client programs
26
The architecture of remote method invocation
Figure 5.6
server
client
object A proxy for B
skeleton
& dispatcher
for B’s class
Request
remote
object B
Reply
Communication
Remote
reference module
module
Communication
module
Proxy - makes RMI transparent to client.
implements
carriesClass
out Requestremote interface. Marshals requests
andprotocol
unmarshals
reply
results. Forwards request.
translates
local
and remote
objectinterface.
Skeleton - between
implements
methods
in remote
references
creates
remote
object
Unmarshals
requests
and
marshals
results. Invokes
Dispatcher
- and
gets
request
from
communication
module and
references.
Uses
remote
methodmethod
in remote
object. object
invokes
in skeleton
(usingtable
methodID in message).
27
Remote reference
module
RMI software - between
application level objects
and communication and
remote reference modules
•
Representation of a remote object reference
32 bits
32 bits
Internet address
port number
32 bits
time
32 bits
object number
Figure 4.10
interface of
remote object
 a remote object reference must be unique in the distributed system and
over time. It should not be reused after the object is deleted. Why not?
 the first two fields locate the object unless migration or re-activation in
a new process can happen
 the fourth field identifies the object within the process
 its interface tells the receiver what methods it has (e.g. class Method)
 a remote object reference is created by a remote reference module
when a reference is passed as argument or result to another process
– it will be stored in the corresponding proxy
– it will be passed in request messages to identify the remote object whose
method is to be invoked
•
28
Shared whiteboard example (p 194)
 In the RMI and CORBA case studies, we use a
shared whiteboard as an example
– this is a distributed program that allows a group of users to share a
common view of a drawing surface containing graphical objects, each
of which has been drawn by one of the users.
 The server maintains the current state of a drawing
and it provides operations for clients to:
– add a shape, retrieve a shape or retrieve all the shapes,
– retrieve its version number or the version number of a shape
•
29
Java Remote interfaces Shape and ShapeList
• Note the interfaces and arguments
• GraphicalObject is a class that implements Serializable.
import java.rmi.*;
import java.util.Vector;
public interface Shape extends Remote {
int getVersion() throws RemoteException;
GraphicalObject getAllState() throws RemoteException;
}
public interface ShapeList extends Remote {
Shape newShape(GraphicalObject g) throws RemoteException;
Vector allShapes() throws RemoteException;
int getVersion() throws RemoteException;
•
}
30
The Naming class of 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.
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.
31
Java class ShapeListServer with main method
import java.rmi.*;
public class ShapeListServer{
public static void main(String args[]){
System.setSecurityManager(new RMISecurityManager());
try{
ShapeList aShapeList = new ShapeListServant();
Naming.rebind("Shape List", aShapeList );
System.out.println("ShapeList server ready");
}catch(Exception e) {
System.out.println("ShapeList server main " + e.getMessage());}
}
}
32
1
2
Java class ShapeListServant implements interface
ShapeList
import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
import java.util.Vector;
public class ShapeListServant extends UnicastRemoteObject implements ShapeList {
private Vector theList;
// contains the list of Shapes
1
private int version;
public ShapeListServant()throws RemoteException{...}
public Shape newShape(GraphicalObject g) throws RemoteException {
2
version++;
Shape s = new ShapeServant( g, version);
3
theList.addElement(s);
return s;
}
public Vector allShapes()throws RemoteException{...}
public int getVersion() throws RemoteException { ... }
}
33
Java client of ShapeList
import java.rmi.*;
import java.rmi.server.*;
Figure 5.15
import java.util.Vector;
public class ShapeListClient{
public static void main(String args[]){
System.setSecurityManager(new RMISecurityManager());
ShapeList aShapeList = null;
try{
aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList") ;
Vector sList = aShapeList.allShapes();
} catch(RemoteException e) {System.out.println(e.getMessage());
}catch(Exception e) {System.out.println("Client: " + e.getMessage());}
}
}
34
1
2
Summary
 PRC
– Interface
– Parameter passing
– Marshalling
 Distributed Objects
– Remote Object Reference
– Remote interface
 RMI
– each object has a (global) remote object reference and a remote interface that
specifies which of its operations can be invoked remotely.
– local method invocations provide exactly-once semantics; the best RMI can
guarantee is at-most-once
– Middleware components (proxies, skeletons and dispatchers) hide details of
marshalling, message passing and object location from programmers.
35