1 / 27

CSS434 Distributed Objects and Remote Invocation Textbook Ch5

CSS434 Distributed Objects and Remote Invocation Textbook Ch5. Professor: Munehiro Fukuda. Outline. RPC/RMI Model Implementation Issues Parameter-passing semantics Invocation semantics Stateless/stateful server Server creation semantics SunRPC Java RMI. Why RPC/RMI.

adamdaniel
Download Presentation

CSS434 Distributed Objects and Remote Invocation Textbook Ch5

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline • RPC/RMI Model • Implementation Issues • Parameter-passing semantics • Invocation semantics • Stateless/stateful server • Server creation semantics • SunRPC • Java RMI CSS434 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 • Ease of use • Compiled-time argument type checking • Automatic stub generation CSS434 RMI

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

  5. remote object Data remote interface m4 { m1 implementation m5 m2 m6 of methods m3 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 */ 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

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

  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 Java) • Performance much slower than local calls. CSS434 RMI

  8. class objA { objB b; objC c; } class objB { } class objC { } 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. Server Client CSS434 RMI

  9. Invocation Fault tolerance measures 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 Invocation Semantics CSS434 RMI

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

  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

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

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

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

  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

  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; 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 ) = %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); } int main (int argc, char *argv[]) { char *host; if (argc < 2) { exit (1); host = argv[1]; example_prog_1 (host); exit (0); } CSS434 RMI

  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

  18. SunRPC v.s. Java RMI CSS434 RMI

  19. server client remote skeleton object A proxy for B object B & dispatcher Request for B’s class Reply Remote reference Communication Communication Remote module reference module module module RMI Mechanism Find the corresponding remote object, unmarshal arguments, and invoke the object. Convert object/method/arguments in a TCP message. 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

  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

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

  22. RMIRemote 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

  23. RMIServer Implementation 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 CSS434 RMI

  24. RMIClient Implementation 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 CSS434 RMI

  25. RMICompilation 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

  26. Exercises (No turn-in) • 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. • 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? • Discuss the similarities and differences among the following parameter passing: • Call-by-object-reference • Call-by-move • Call-by-visit • Discuss about the pros and the cons of dynamic binding in RPC. • 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. • 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? CSS434 RMI

  27. Exercises (No turn-in) • 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? • 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

More Related