06-Distributed Objects and Remote Invocation

1 .CSS434 Distributed Objects and Remote Invocation Textbook Ch5 Professor: Munehiro Fukuda CSS434 RMI 1 

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

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  Ease of use  Compiled-time argument type checking  Automatic stub generation CSS434 RMI 3 

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

5 . Service Interface and Remote Interface RPC: an service interface defined with an XDR file struct doubles { double a; double b; }; program EXAMPLE_PROG { 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 */ remoteobject remote Data interface m4 m implementation { m2 1 m3 of methods m5 m6 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; } CSS434 RMI 5 

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

7 . Implementation Issues  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 Ja va)  Performance much slower than local calls. CSS434 RMI 7 

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

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

10 . Stateful/Stateless Servers  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 lea ves old client information at server.  At-most-once invocation semantics (Java RMI takes this desig n.)  Stateless servers:  Clients must maintain Inter-call information.  RPC/RMI reply is always the same.  At-least-once invocation semantics (Some RPC implementatio ns take this design.) CSS434 RMI 10 

11 . Server Creation Semantics  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.) CSS434 RMI 11 

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

13 . Client-Server Binding (SunR PC) Client Machine Server Machine (2) Locating server Portmap port: 111 Daemon Client (3) Server port (xxx) (1) register port: xxx (4) RPC with port xxx Server write(), read(), write(), read(), Sendto(), recvfrom() Sendto(), recvfrom() TCP or UDP Transport level or below TCP or UDP Network (LAN/WAN)  (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 

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

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. */ 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 */ CSS434 RMI 15 

16 . Sun RPC (Client) #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; int clnt = clnt_create (host, EXAMPLE_PROG, EXAMPLE_VERS, "udp"); main (int argc, char *argv[]) if (clnt == NULL) { { clnt_pcreateerror (host); char *host; exit (1); } if (argc < 2) { fact_1_arg = 10; exit (1); result_1 = fact_1(&fact_1_arg, clnt); host = argv[1]; if (result_1 == (int *) NULL) { example_prog_1 (host); clnt_perror (clnt, "call failed"); exit (0); } } printf( "fact( 10 ) = %d\n", *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 ) = %f\n", *result_2 ); strncpy( strconc_1_arg.dst, "xyz\0", BUFFER_SIZE ); strncpy( strconc_1_arg.src, "abc\0", BUFFER_SIZE ); result_3 = strconc_1(&strconc_1_arg, clnt); if (result_3 == (char **) NULL) { clnt_perror (clnt, "call failed"); } printf( "strconc( \"xyz\", \"abc\" ) = %s\n", *result_3 ); clnt_destroy (clnt); } CSS434 RMI 16 

17 .Sun RPC (Server) #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; } CSS434 RMI 17 

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

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

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. 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. CSS434 RMI 20 

21 . RMI Programming Procedure (4) Program a Client.java class (5) javac Client.java (2) Program a Server.java class (7) Run Server with java Server (8) Run Client with java Client Application Layer: Client .java Server.java (implements remote interface) (1) Define a remote interface (3) javac Server.java Stub/Skeleton: Stub Skeleton 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 } // 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 ); } } CSS434 RMI 22 

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

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

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: 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 whe never any user thinks they have cast a vote. Discuss the effect of maybe call semantic s on the Election service. Would at-least-once call semantics be acceptable for the El ection service or would you recommend at-most-once call semantics? CSS434 RMI 26 

27 . Exercises (No turn-in) 7. Textbook p227, Q5.15: A request-reply protocol is implemented over a communicati on service with omission failures to provide at-least-once RMI invocation semantics. I n the first case the implementor assumes an asynchronous distributed system. In the second case the implementor assumes that the maximum time for the communicatio n 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 take s 10 milliseconds to process each request. The local operating system processing tim e for each send or receive operation is 0.5 milliseconds, and the network time to tran smit each request or reply message is 3 milliseconds. Marshalling or unmarshalling ta kes 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