1 / 31

Remote Procedure Call and Remote Object Invocation

Remote Procedure Call and Remote Object Invocation. TANENBAUM-Chapter 2. Remote Procedure Call RPC. Conventional Procedure Call. Read(fd,buf,nbytes). Parameter passing in a local procedure call: the stack before the call to read The stack while the called procedure is active.

asbury
Télécharger la présentation

Remote Procedure Call and Remote Object Invocation

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. Remote Procedure CallandRemote Object Invocation TANENBAUM-Chapter 2

  2. Remote Procedure CallRPC

  3. Conventional Procedure Call Read(fd,buf,nbytes) • Parameter passing in a local procedure call: the stack before the call to read • The stack while the called procedure is active

  4. Client and Server Stubs • Principle of RPC between a client and server program.

  5. Steps of a Remote Procedure Call • 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 • Client Stub unpacks result, returns to client

  6. Passing Value Parameters (1) 2-8 • Steps involved in doing remote computation through RPC; a shadow remote procedure call stub is put ın the client’s library to make the remote procedure call transparent. At server site server stub is required.

  7. Passing Value Parameters (2) • Marshalling is required between two end machines: e.g. • Pentium uses Little Ending, Sun uses Big Ending • Original message on the Pentium • The message after receipt on the SPARC • The message after being inverted. The little numbers in boxes indicate the address of each byte. The integer 5 is marshaled correctly but the string is incorrectly inverted…

  8. Parameter Specification and Stub Generation • A n RPC call with different type parameters • The corresponding message with special format (IEEE #754).

  9. Interface Definition • Interfaces can be defined using an Interface Definition Language (IDL) • The coded interface can then be translated into client stub at the client side and server stub at the server side. • Once the stubs are ready, the transmission with the remote counterpart can be achieved based on the available protocol, eg. TCP/IP

  10. Extended RPC models: Doors • Original RPC assume remote communication. • If client and server are on the same machine, then more efficient communication may be used, based on IPC system call library. • So called door is used for colocated client server process communication… • In this case, server is registered with a named door, so that it can be uniquely identified by the operating system when named by the clients • In Solaris, door is associated a file name and treated as such.

  11. Extended RPC models: Doors-2 • Used when both client and server are in the same address space. Few additional system calls are used to implement this: create, fattach, open, door_call, door_return to register with the door and call the door.

  12. Asynchronous RPC (1) 2-12 • The interconnection between client and server in a traditional RPC: block client until response is received. • The interaction using asynchronous RPC: block client until request received response is received.

  13. Asynchronous RPC (2) 2-13 • A client and server interacting through two asynchronous RPC calls: client is interrupted by the server to deliver the response for the previous request…

  14. Example: Distributed Computing Environment(DCE: RPC) • DCE RPC is a middleware system between OS and application, developed by so called Open Group. • Services: • Distributed file service • Directory service • Security service • Distributed time service • Goal: to provide transparency in all above services, including binding, communication, data type conversion, and language differences… Client and servers can run on different architecture and implemented using different programming languages… • The DCE RPC includes a number of components including languages, libraries, daemons, and utility programs

  15. Writing a Client and a Server(1) 2-14 • The steps in writing a client and a server in DCE RPC. Uuidgen-Unique user interface identifier, never generated again by Uuidgen. Uniqueness is guaranteed by encoding location and the time of the day into 128 bit binary number. Client and server can not share the global variables…

  16. Writing a Client and a Server(2) • UUIDGEN generates a unique user identifier and an IDL file with that identifier • The identifier is 128-bit binary number, so that it can never be reused • Interface Definition Language (IDL) file is than allowed to be updated compiled to produce the stubs and the header file • Server and client codes are then written and compiled with corresponding stub and the header file to be linked with the DCE RPC library, to produce the binaries to be run • DCE daemon maintains a table for server endpoints • A directory server maintains the address of the registered servers with their network addresses. • Client get the network address of the machine running the server from the Directory Service and asks the Daemon for the endpoint of the server to send a request…

  17. Binding a Client to a Server 2-15 • Client-to-server binding in DCE. • RPC performs operation with “at most once” principle. THIS MEANS RPC CALLS ARE NOT REPEATED BY THE CLIENTS, EVEN IN CASE OF SERVER FAILURES… this is done to avoid multiple requests… • A server can be marked as idempotent, i.e. to allow repeated access…

  18. Remote Object Invocatıon (1) • Expansion of idea of RPC to method invocations on remote objects to enhance distributed transparency • This desire is fueled by the concept of the object, in which its internals can be hidden from the outside world by means of well-defined interfaces: • state or data is accessible by the methods that can be accessed through interfaces…

  19. Remote Object Invocatıon (2) • Principles of RPC can also be applied to objects • Distribution aspects can be hidden behind the object’ interface • CORBA is an industry defined standard for distributed application development • DCOM is Microsoft counterpart for CORBA, as middleware for the Windows domain of operating systems • Separation between the interface and the object implementation can be explored for distributed applications, so that interface is in one machine while object is on another. • In object based RPC model, counter parts of client stub in conventional RPC is proxy, that of the server is the skeleton to conduct marshalling and un-marshalling, to each others. Note that the object state may or may not be distributed, but if distributed it can be transparent to the application.

  20. Remote Object Invocatıon (3): Distributed Object based organization 2-16 • Common organization of a remote object with client-side proxy, ie. interface on the client machine, server on another…. State is not distributed..

  21. Remote Object Invocatıon (4): Compile time vs Runtime Objects • The objects implemented using Java and C++ are compile time objects, where the objects are instances of classes. • Compile time objects depend on the particular programming language used. It is easier to built such applications. • Alternatively, the distributed objects can be created during the runtime and made programming language independent, wrapped by a rapper so that the implementation appears as an object. • A common approach is to use Adapters in runtime to allow an interface to be converted to what the clients expect.

  22. Remote Object Invocation (5): Object Persistence • Persistent object continues to exists even if the server cease to exist. • A persistent object is saved on the secondary storage by a server and retrieved into the scope of the server, whenever needed. • Transient objects cease to exist as soon as the servers cease to exist...

  23. Remote Object Invocatıon (6): Object binding • In distributed objects case, a system wide object reference is common. • Object references can even be passed as parameters in method invocations. • A process must first be bound to an object’s reference before invoking any of its methods, perhaps using a proxy. • The binding can be implicit, just like local reference; or it can be explicit in which it needs to find the object before being bind.

  24. Remote Object Invocatıon (7): Implementation of Object References • Object reference depicts the address of the server object which include the machine it resides, the server identification, and the object identification • The transparency can be improved by using server location servers that keep track of the machine where the servers are and their endpoints on those machines • As a further transparency, an object reference may have additional information, such as the protocols implemented by the object • This may lead to use of an implementation handle, which dynamically loads the object specific proxy to provide binding: • So clients need not to worry about the details of the implementation.

  25. Remote Object Invocatıon (8): Binding a Client to an Object Distr_object* obj_ref; //Declare a systemwide object referenceobj_ref = …; // Initialize the reference to a distributed objectobj_ref-> do_something(); // Implicitly bind and invoke a method (a) Distr_object obj_ref; //Declare a systemwide object referenceLocal_object* obj_ptr; //Declare a pointer to local objectsobj_ref = …; //Initialize the reference to a distributed objectobj_ptr = bind(obj_ref); //Explicitly bind and obtain a pointer to the local proxyobj_ptr -> do_something(); //Invoke a method on the local proxy (b) • An example with implicit binding using only global references • An example with explicit binding using global and local references

  26. Remote Object Invocation (9): Static vs Dynamic RMI • Static remote method invocation implies imbedding the object interfaces into the program, thus requires recompilation if the object interface changes. • In dynamic invocation, the method to invoke is selected at run time. • Examples from th book: • static rmi, appending an integer to a file object: • fobject.append (int) • dynamic rmi, first acquiring an identifier for the method append, before binding the integer int: • invoke(fobject, id(append),int), d) where id(append) returns an identifier for the method append.

  27. Remote Object Invocatıon (10): Parameter Passing is a problem 2-18 • The situation when passing an object by reference or by value. The distinction in local and global parameters is visible even in object oriented languages. Ref to O1 is by value(L1), reference to O2 is by reference (R1).

  28. Example: The DCE Distributed-Object Model (1) • DCE advocates have to prove that DCE can actually be object based! • DCE objects may be accepted as refinement of RPC, with a shift from procedure call to remote method invocation. • DCE distributed objects are specified in IDL and implemented in C++, created by the server making methods available to the clients • Distributed dynamic objects are created by the server only, on clients request and associated with it • Distributed named object is created and registered with a directory service to be shared by more clients • Each remote object invocation is done by an RPC , with all the details required as parameters to the object server which maintains an object table with their identifiers and interface identifiers to dispatch the requested methods…. • Binding is done by a handle (in the form of an identifying string), there is no system wide transparent object referencing mechanism. • This makes parameter passing in DCE object model harder, as the implementation is some sort of refinement of the RPC parameter passing

  29. The DCE Distributed-Object Model (2) • Distributed dynamic objects in DCE. • Distributed named objects 2-19

  30. Java Distributed Object Model(2) • In Java, distributed objects are imbedded into the language. • Java remote object is a distributed object whose state is kept on one machine, but the interface is made available to remote processes. • Cloning remote and local objects is not the same. • Java allows each object to be constructed as a monitor, by declaring a method as synchronized. • If two clients simultaneously call a synchronized method one has to wait…However synchronization may be implemented on the local stub (proxy) or the server stub • RMI seems to restrict synchronization, ie. blocking, to the client side proxies, rather than server side blocking. • This may not prevent simultaneous access to the remote object, which means explicit distributed locking techniques are required.

  31. Java Distributed Object Model(2) • With RMI, any serializable object can be passed as parameter (platform dependent objects such as file or socket descriptors cannot be serializable). • Local objects are passed by value, remote objects are passed by reference, as in case of DCE objects. • Client and server stubs are generated from the interfaces implemented by the respective classes. • Although, the stubs are serializable objects and they can be marshaled and passed over to servers as remote references, RMI implements stub implementation handlers which are smaller in size as they replace the marshaled code…. • It is also possible to arrange for servers to pass over (downloaded by the clients) marshaled client side code whenever a client binds to the object, which is not possible in DCE object model. • Dynamic changes to the state of a proxy object needs to refreshed to reflect the changes in the server… • Passing proxies as parameter is possible only because the JVM is the same everywhere.

More Related