Transcript Week3_4_2011

Two Approaches
Communication-Oriented Design
Begin with the communication protocol. Design a message
format and syntax. Design the client and server
components by specifying how each reacts to incoming
message and how each generates outgoing messages.
Application-Oriented Design
Begin with the application. Design a conventional
application program to solve the problem. Build and test a
working version of the conventional program that operates
on a single machine. Divide the program into two or more
pieces, and add communication protocols that allow each
piece to execute on a separate computer.
Communication in Distributed System


Interprocess communication is at the heart of all
distributed systems. It makes no sense to study
distributed systems without carefully examining
the ways that processes on different machines
can exchange information.
To understand the communication in the
distributed system, two main topics should be
discussed:


Protocols governing the rules that communicating processes must
adhere to.
Models for communication: Remote Procedure Call (RPC), Remote
Method Invocation (RMI), Message-Oriented Middleware (MOM), and
streams.
Layered Protocols (1)
Figure 4-1. Layers, interfaces, and protocols
in the OSI model.
Layered Protocols (2)
A typical message as it appears on the network.
Middleware Protocols
 An adapted reference model
for networked communication.
Middleware layers
Applications
RMI, RPC and events
Request reply protocol
External data representation (XDR)
Operating System
Middleware
layers
Types of Communication
 Viewing middleware as an intermediate (distributed) service in
application-level communication.
 Persistent communication vs. Transient communication
 Asynchronous communication vs. Synchronous Communication
Outcomes: RPC
What is RPC?
The difference between conventional procedure call
and RPC?
Understand the function of client and server stubs
How many steps could happen for a RPC?
How RPC deals with the parameter passing?
How to write a client and server using DCE RPC?
Outcomes: Remote Object Invocation
What is so called distributed objects?
How to bind a client to an object?
Implementation of object references
Static vs dynamic remote method
invocations
Definition of Remote Procedure Call
 Principle of RPC between a client and server program.
 When a process on machine A calls a procedure on machine B, the calling
process on A is suspended, and execution of the called procedure takes place
on B. Information can be transported from the caller to the callee in the
parameters and can come back in the procedure result. No message passing
at all is visible to the programmer. This method is known as Remote
Procedure Call.
RPC - Conventional Procedure Call
a)
b)
1.
The stack before the call is shown in (a)
2.
To make call, the caller pushes the parameters
onto the stack in order, last one first, as shown in
(b)
3.
After the read procedure has finished running, it
puts the return value in a register, removes the
return address and transfers control back to the
caller.
4.
The caller then removes the parameters from the
stack, returning the stack to the original state it
had before the call.
Parameter passing in a local procedure call: the
stack before the call to read (fd, buf, nbytes)
The stack while the called procedure is active
Client and Server Stubs
 Traditional Procedure call: The programmer
puts a call to read in the code to get the
data. The read routine is extracted from the
library by the linker and inserted into the
object program. It is a short procedure,
which is generally implemented by calling an
equivalent read system call.
 RPC: It achieves its transparency in an
analogous way. When read is actually a
remote procedure, a different version of read
called client stub, is put into the library. Like
the original one, it too, does a call to the
local OS. Only unlike the original one, it does
not ask the OS to give it data. Instead, it
packs the parameters into a message and
request that message to be sent to the
server. Following the call to send, the client
stub calls receive, blocking itself until the
reply comes back
Figure 5.7
Role of client and server stub procedures in RPC
client process
server process
Request
client stub
procedure
client
program
Communication
module
Reply
server stub
procedure
Communication
dispatcher
module
service
procedure
 The function of stub is that, instead of asking operating to give it data, it packs
the parameters into message and requests the message to be sent to the
server. After client stub calls send, it calls receive, block itself until the reply
comes back.
Client and Server Stubs
2-8
 Steps involved in doing remote computation through RPC
Steps of a Remote Procedure Call
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
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
a)
b)
c)
Original message on the Pentium (number their bytes from right to left)
The message after receipt on the SPARC ( number their bytes left to right)
The message after being inverted. The little numbers in boxes indicate the
address of each byte
Files interface in Sun XDR
const MAX = 1000;
typedef int FileIdentifier;
typedef int FilePointer;
typedef int Length;
struct Data {
int length;
char buffer[MAX];
};
struct writeargs {
FileIdentifier f;
FilePointer position;
Data data;
};
struct readargs {
FileIdentifier f;
FilePointer position;
Length length;
};
program FILEREADWRITE {
version VERSION {
void WRITE(writeargs)=1;
Data READ(readargs)=2;
}=2;
} = 9999;
1
2
Passing Reference Parameters
 Passing the reference parameter is very difficult:
read(fd, buf, nbytes) example
 One solution is to forbid pointers and reference parameters in
general.
 Strategy : In read example, the client stub knows the buf points
to an array and the array length.
Client stub copies the array into message and send it to the server
Server stub call the server with a pointer to this array
When server (procedure) finishes, the original message can be sent back
to the client stub
Client stub copies buf back to the client (procedure).
 Example ONC RPC call functions:
callrpc(host, prog, progver, procnum, inproc, in, outproc, out);
handle = clan_create (host, prog, vers, proto);
Example: DCE RPC
Services DCE RPC has:
The distributed file service is a world wide file system that
provides a transparent way of accessing any file in the
system in the same way
The directory service is used to keep track of the location
of all resources in the system
The security service allows resources of all kinds to be
protected
The distributed time service is a service that attempts to
keep clocks on the different machines globally
synchronized
Writing a Client and a Server
2-14
 The steps in writing a client and a server in DCE RPC.
Binding a Client to a Server
2-15
 Client-to-server binding in DCE.
 To allow a client to call a server, the server must be registered first
 The steps to locate the server and bind to it:
 Locate the server’s machine
 Locate the server (i.e. the correct process) on that machine
Remote Object Invocation
What is so called distributed objects?
How to bind a client to an object?
Implementation of object references
Static vs dynamic remote method
invocations
Remote and local method invocations
local
remote
invocation
A
B
C
local E
invocation
invocation
local
invocation
D
remote
invocation
F
Distributed Objects
2-16
 Common organization of a remote object with client-side proxy.
1.
2.
Proxy is analogous to a client stub in RPC system. Its work is to marshal method invocation into messages or unmarshl reply messages to return result to client.
Skeleton is analogous to server stub. It works the similar way as proxy.
Binding a Client to an Object
Distr_object* obj_ref;
obj_ref = …;
obj_ref-> do_something();
//Declare a systemwide object reference
// Initialize the reference to a distributed object
// Implicitly bind and invoke a method
(a)
Distr_object objPref;
Local_object* obj_ptr;
obj_ref = …;
obj_ptr = bind(obj_ref);
obj_ptr -> do_something();
//Declare a systemwide object reference
//Declare a pointer to local objects
//Initialize the reference to a distributed object
//Explicitly bind and obtain a pointer to the local proxy
//Invoke a method on the local proxy
(b)
a)
b)
An example with implicit binding using only global references
An example with explicit binding using global and local references
Implementation of Object References
 Object reference must contain enough information to allow a
client to bind to an object. It would include the network address
of the machine where the actual object resides, along with an
endpoint identifying the server that manages the object, plus an
indication of which object.
 To avoid the reassignment of the object reference, for example
the endpoint for the recovery of server from crash, each
machine should have a local daemon to listen to a well-known
endpoint and keep track of the server-to-endpoint assignments
in an endpoint table.
 Using the location server to keep track of the machine where
an object’s server is currently running.
Static versus Dynamic Remote Method Invocations
 Difference between RPC and RMI:
RPC only have general-purpose client-side and server side stubs available.
RMI generally support system wide object references.
 Static Invocation: using predefined interface definitions. It requires
that the interfaces of an object are known when the client
application is being developed. If interfaces change, application
must recompile.
 Dynamic invocation: able to compose a method invocation at
runtime. It takes the form such as:
Invoke(object, method, input_parameters, output_parameters);
 Example: Appending an integer int to a file object fobject:
Static invocation: fobject.append(int)
Dynamic invocation: invoke(fobject, id(append), int)
Figure 5.5
Invocation semantics
Fault tolerance measures
Retransmit request
message
Duplicate
filtering
Invocation
semantics
Re-execute procedure
or retransmit reply
No
Not applicable
Not applicable
Maybe
Yes
No
Re-execute procedure
At-least-once
Yes
Yes
Retransmit reply
At-most-once
Figure 5.11
Java Remote interfaces Shape and ShapeList
import java.rmi.*;
import java.util.Vector;
public interface Shape extends Remote {
int getVersion() throws RemoteException;
GraphicalObject getAllState() throws RemoteException;
1
}
public interface ShapeList extends Remote {
Shape newShape(GraphicalObject g) throws RemoteException; 2
Vector allShapes() throws RemoteException;
int getVersion() throws RemoteException;
}
Figure 5.12
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 next slide, 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.
Figure 5.13
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());}
}
}
1
2
Figure 5.14
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 { ... }
}
Figure 5.15
Java client of ShapeList
import java.rmi.*;
import java.rmi.server.*;
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());}
}
}
1
2
Figure 5.16
Classes supporting Java RMI
RemoteObject
RemoteServer
Activatable
UnicastRemoteObject
<servant class>