Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Block 3 - Unit 2 IPC in Non Shared Memory (II) There are TWO sections in this Unit. i. RPC and Java’s RMI Mechanism ii. Using Java’s RMI Mechanism Bacon Chapter 16 required Section 1: RPC and Java’s RMI Mechanism RPC – Remote Procedure Calls Objectives: On completion of this section you should be able to: 1. Describe how issues related to concurrency can be separated from issues related to distribution; 2. Distinguish between message passing and RPCs; 3. Describe the RRA protocol for an RPC implemented on an unreliable transport service; 4. Describe the problems that arise when a client, server or network crashes and when the network becomes congested, and explain how the RPC protocol deals with the problems; 5. Explain the difference between a transparent and non-transparent approach to integrating RPCs into a programming language; 6. Explain why an RPC is not a sensible mechanism for all types of communication; 7. Explain the issues related to the naming of objects in a distributed IPC system. 8. Explain Java’s RMI mechanism for implementing an RPC system of distributed IPC; 9. Describe the important classes in Java’s RMI packages; 10. Compare the RMI model of distributed IPC with the client–server model. Procedures and Procedures Calls Points to be noted 1. An application can consist of several procedures (or methods , in OO terminology). 2. There is a single thread of control as one procedure calls another. The calling process stops when the invoked process starts execution. Only after the completion of the later which includes returning data results, the former resumes. In OOP, Typically, variables hold references to objects rather than the objects themselves, but hold the values of primitive data types directly. Passing of arguments in procedure are passed by reference , while the values of primitive data types are passed by value . RPC–language integration (replaces Bacon, Section 15.8) The advantage of an RPC system is that, when integrated into a conventional programming language that uses procedure calls, the system developer can use the familiar procedural calling mechanisms to program in a distributed setting. In other words, the system developer does not need to know the details of how the (remote) call being made in the local application is sent to a process on another machine, carried out on that machine, and the result returned to the local application. All this is automatically carried out by the underlying implementation. Distribution transparency means should it be indistinguishable from a local call as far as the application program is concerned. If it is to be indistinguishable, the compiler needs to detect that the call is remote and produce the code that will find the target of the call, and then use the underlying mechanisms that carry out the communication with the remote machine. These underlying mechanisms usually involve the use of a stub on both the local (client) and remote (server) machines. This involves the marshalling and unmarshalling of arguments and return values. Marshalling arguments is the activity of transforming the arguments of a procedure call into a form suitable for transmission via a network. The arguments of a procedure call are structured within the main memory and can consist of data values of various types and references to them. Since network communication is usually the transmission of a stream (sequence) of bytes, the procedure’s arguments have to be ‘flattened’ or marshalled into a stream of bytes. On arrival, the stream of bytes must be reformed (i.e. unmarshalled ) into their original structure, and, to do this, information about the original structure must be transmitted in addition to the data. The alternative to distribution transparency recognizes that remote calls are likely to take longer than local calls and also involve additional types of failure (e.g. network failure). Some languages, therefore, provide special syntax for a remote call so that the application programmer can take such eventualities into account. 2 Security managers - Similar to the security systems that control applets, RMI security managers control what remote objects and their clients can do. The developer of RMI applications needs to know about them since both client and server applications must start by creating and installing a security manager: System.setSecurityManager(new RMISecurityManager()); Q. In what sense are concurrency and distribution issues separated when processes can be created dynamically? Concurrency is achieved by having two processes: the parent and the child it creates using the '02, primitive. Distributed programming is achieved through the child process that invokes the remote operation. Such a child process is called a distributed sequential process . Q. What is a remote procedure call RPC ? A remote procedure call (RPC) is a call to a procedure located on a machine that is different (remote) from the machine from which the call was made. Q. How does a remote procedure call differ from a message passing scheme? A message passing scheme may be asynchronous. An RPC is always synchronous, in the sense that the calling procedure, having invoked a procedure on a remote machine, waits for the result before continuing with its processing. RPA Request–reply–acknowledge protocol and RARA protocol RRA is where one process (the caller process) sends a message ( request) to another process (the receiver process), the called system (server) sends a reply (which also acts as an acknowledgement that the original message was received), and the calling system (client), on receipt of the reply, sends an acknowledgement to confirm receipt of the reply. RARA is similar to RRA but an additional explicit acknowledgement of the receipt of the original message is sent by the called system. An orphan An orphan is a remote procedure call whose client (i.e. the node making the call) crashes after the request has been sent. That is, there has been client failure with the result that the client is not able to deal with any reply generated by the orphan. The major problem is that there may have been state changes in the server (i.e. the node containing the called procedure) or other nodes as the result of acting on the original request. On restart, the client is likely to retry the RPC with the state of the server different from its state when the original request was made. When the client restarts, it will be the application that decides whether or not to retry the RPC. The RPC service sees only a request for a remote procedure call to be made and does not know that this is a repeat request. Therefore, it will view this request as a new one and generate a new RPC identifier. Difference between the client–server model and an object model like RMI The object model works within the OO paradigm, in which services are obtained by sending messages (method invocations) to objects. In the client–server model also works on the basis of a client sending messages to a server. However, in this case the messages are not in the form of method invocations, but conform to another protocol agreed between client and server, such that the server can invoke methods on its encapsulated objects on behalf of the client. This does mean, however, that the client and the server have to include code to transform method invocations into data streams and vice versa in order to communicate. Q. Why is RPC communication not particularly well suited to real-time systems requiring massive amounts of data to be transferred (e.g. video streams)? (Study Question 8) RPC communication requires all the data to be received before the operation commences and is likely to have some maximum data size well below that required by the application. Also, for some systems in which the data to be transferred is simply a (large) stream of bytes, there is no requirement for sophisticated argument marshalling and, indeed, to have such a mechanism would slow up the transmission. Section 2: Using Java’s RMI Mechanism Objectives On completion of this section you should be able to: 1 explain Java’s RMI mechanism for implementing an RPC system of distributed IPC; 2 describe the important classes in Java’s RMI packages; 3 describe the main components of a small application which uses RMI; 4 compare the RMI model of distributed IPC with the client–server model; 5 use the IDE to run RMI applications; 6 explain the role of the security manager. The Remote Object One of the fundamental ideas about Java objects is that, when defining a class, it is often a good idea to do so in two parts: an interface and an implementation. A Java interface contains the signatures of the public methods that can be invoked on an object of the class. The implementation contains the bodies of the public methods together with any fields and private methods that may be required. This separation into interface and implementation has many advantages. One of these is that a client (a user of a remote object) needs only to know about the interface of the remote object’s class whereas the server (the implementor of the remote object) needs to know about both the interface and the implementation of the class. The second idea is that an object is created only when a Java program (strictly, a Java thread) is executed. An object exists in main memory until either it is no longer referenced (in which case the garbage collector reclaims the storage it occupied) or the thread that created it ceases execution. Thus, there must be a thread in existence if an object is to exist. Thus, when there is a remote object, the client must be aware of the object’s interface (to ensure that the remote method invocations made by the client can be checked by the compiler). Of course, the implementations of these methods must be known to the server because it is the server host that executes the methods. This means that we shall develop classes for remote objects in the form of an interface plus an implementation. Both are required by the server (you can’t have an implementation without the associated interface) but only a copy of the interface is required by the client. The RMI Registry The RMI registry is a Java program named rmiregistry, which when it is executing, maintains a list of references to objects that have been registered with it. An object is registered by a server using the rebind method from the class Naming (part of the java.rmi package). The first argument of the rebind method is a String that specifies: 1 where the registry is located — by quoting the IP address of its host ( localhost can be used when the registry is on the same host as the server) and the port on which the registry listens for communications (by default this is 1099, and can be omitted); 2 a programmer defined name by which clients can gain access to the object. The second argument is a reference to the object itself. There is an alternative method to rebind known as bind. The difference between them depends upon whether or not an object with the same string name already exists within the registry when these methods are invoked. If an object already exists, rebind will replace its reference with a reference to the new object whereas bind will throw an exception. It is important to recognize that the RMI registry is a non-persistent scheme. The registry forgets all its contents when the rmiregistry program stops. The stub object An important point to note is that the client process does not communicate directly with the remote object. Instead, there is a stub object on the client's host that acts as a proxy for the remote object. Therefore, whenever the client invokes a method on the remote object, the message is sent to the stub, which is responsible for marshalling the arguments and converting the message into a stream object capable of being transmitted to the remote host using Java’s socket and stream client–server mechanism. Once the message reaches the remote host, it is transformed into a normal method invocation applied to the remote object. Any response (return value) from the remote object follows the reverse procedure. The stub on the client converts the return message into a value that is returned to the object that made the original remote call. Summary of Unit 2 You have now seen two models of IPC: the client–server model (in the previous unit) and the object model (in this unit). In Section 1 you learned about synchronous remote procedural calls (RPC). In Section 2 you learned how to use Java’s version of RPC, called RMI (remote method invocation), and that RMI is of a higher level of abstraction than the client–server mechanism using sockets and data streams. You also saw that RMI falls a little short of the complete object model. Please Read all study material, exercises, SAQs, Bacon and block material.