<link href="//maxcdn.bootstrapcdn.com/bootstrap/3.3.0/css/bootstrap.min.css" rel="stylesheet" id="bootstrap-css"> <script src="//maxcdn.bootstrapcdn.com/bootstrap/3.3.0/js/bootstrap.min.js"></script> <script src="//code.jquery.com/jquery-1.11.1.min.js"></script> <!------ Include the above in your HEAD tag ----------> <div class="container"> <div class="row"> <p>REMOTE INVOCATION PARADIGMS I. Request-reply protocols represent a pattern on top of message passing and support the two-way exchange of messages as encountered in client-server computing. o Such protocols provide relatively low-level support for requesting the execution of a remote operation, and also provide direct support for RPC and RMI. II.The Remote Procedure Call, or RPC model represents an earliest example of a more programmer-friendly model o the extension of the conventional procedure call model to distributed systems. 4</p> <p>REMOTE INVOCATION PARADIGMS o RPC allows client programs to call procedures transparently in separate server processes and generally in different computers from the client. III. In the 1990s, the object-based programming model was extended to allow objects in different processes to communicate by means of Remote Method Invocation (RMI). o RMI is an extension of Local Method Invocation (LMI) that allows an object in one process to invoke the methods of an object in another process.</p> <p</p> <p>Request-Reply Protocols
This form of communication is designed to support the roles and message exchanges in typical client-server interactions.
In the normal case, request-reply communication is synchronous because the client process blocks until the reply arrives from the server.
It can also be reliable because the reply from the server is effectively an acknowledgement to the client.
Asynchronous request-reply communication is an alternative that may be useful in situations where clients can afford to retrieve replies later.
The client-server exchanges are described in the following slides in terms of the send and receive operations in the Java API for UDP datagrams, although many current implementations use TCP</p> <p>Request-Reply Protocols
A protocol built over datagrams avoids unnecessary overheads associated with the TCP stream protocol.
In particular: a) acknowledgements are redundant, since requests are followed by replies. b) Establishing a connection involves two extra pairs of messages in addition to the pair required for a request and a reply. c) Flow control is redundant for the majority of invocations, which pass only small arguments and results. The request-reply protocol Based on a trio of communication primitives, o doOperation, o getRequest and o sendReply, as shown in Figure 2. </p> <p>Request-Reply Protocols Message identifiers
Any scheme that involves the management of messages to provide additional properties o such as reliable message delivery or request-reply communication o requires that each message have a unique message identifier by which it may be referenced.
A message identifier consists of two parts:-
1. a requestId, which is taken from an increasing sequence of integers by the sending process;
2. an identifier for the sender process, for example, its port and Internet address.
The first part makes the identifier unique to the sender, and the second part makes it unique in the distributed system.
(The second part can be obtained independently – for example, if UDP is in use, from the message received.)</p> <p>Request-Reply Protocols
When the value of the requestId reaches the maximum value for an unsigned integer (for example, 232 – 1) it is reset to zero.
The only restriction here is that the lifetime of a message identifier should be much less than the time taken to exhaust the values in the sequence of integers. Failure model of the request-reply protocol
If the three primitives doOperation, getRequest and sendReply are implemented over UDP datagrams, then they suffer from the same communication failures. That is: a) They suffer from omission failures. b) Messages are not guaranteed to be delivered in sender order.
In addition, the protocol can suffer from the failure of processes.
We assume that processes have crash failures. </p> <p>Request-Reply Protocols
That is, when they halt, they remain halted –they do not produce Byzantine behavior.
To allow for occasions when a server has failed or a request or reply message is dropped, doOperation uses a timeout when it is waiting to get the server’s reply message.
The action taken when a timeout occurs depends upon the delivery guarantees being offered. Timeouts
There are various options as to what doOperation can do after a timeout.
The simplest option is to return immediately from doOperation with an indication to the client that the doOperation has failed.
Not the usual approach – the timeout may have been due to the request or reply message getting lost and in the latter case, the operation will have been performed.</p> <p>Request-Reply Protocols
To compensate for the possibility of lost messages, o doOperation sends the request message repeatedly until either it gets a reply or o it is reasonably sure that the delay is due to lack of response from the server rather than to lost messages.
Eventually, when doOperation returns, it will indicate to the client by an exception that no result was received. Discarding duplicate request messages
In cases when the request message is retransmitted, the server may receive it more than once.
For example, the server may receive the first request message but take longer than the client’s timeout to execute the command and return the reply.
This can lead to the server executing an operation more than once for the same request. </p> <p>Request-Reply Protocols
To avoid this, the protocol is designed to recognize successive messages (from the same client) with the same request identifier and to filter out duplicates.
If the server has not yet sent the reply, it need take no special action – it will transmit the reply when it has finished executing the operation. Lost reply messages
If the server has already sent the reply when it receives a duplicate request it will need to execute the operation again to obtain the result, unless it has stored the result of the original execution.
Some servers can execute their operations more than once and obtain the same results each time.
An idempotent operation is an operation that can be performed repeatedly with the same effect as if it had been performed exactly </p> <p>Lost reply messages (cont’d)
For example, an operation to add an element to a set is an idempotent operation because it will always have the same effect on the set each time it is performed,
whereas an operation to append an item to a sequence is not an idempotent operation because it extends the sequence each time it is performed.
A server whose operations are all idempotent need not take special measures to avoid executing its operations more than once. </p> <p>Styles of exchange protocols
Three protocols, that produce differing behaviors in the presence of communication failures are used for implementing various types of request behavior.
They were originally identified by Spector [1982]: o the request (R) protocol; o the request-reply (RR) protocol; o the request-reply-acknowledge reply (RRA) protocol.
The messages passed in these protocols are summarized in Figure below.
In the R protocol, a single Request message is sent by the client to the </p> <p> The R protocol may be used when there is no value to be returned from the remote operation and the client requires no confirmation that the operation has been executed </p> <p> Request-Reply Protocols
The client may proceed immediately after the request message is sent as there is no need to wait for a reply message.
This protocol is implemented over UDP datagrams and therefore suffers from the same communication failures.
The RR protocol is useful for most client-server exchanges because it is based on the request-reply protocol.
Special acknowledgement messages are not required, because a server’s reply message is regarded as an acknowledgement of the client’s request message.
Similarly, a subsequent call from a client may be regarded as an acknowledgement of a server’s reply message.
As we have seen, communication failures due to UDP datagrams being lost may be masked by the retransmission of requests with duplicate filtering and the saving of replies in a history for retransmission. </p> <p>Request-Reply Protocols
The RRA protocol is based on the exchange of three messages: request-replyacknowledge reply.
The Acknowledge reply message contains the requestId from the reply message being acknowledged.
This will enable the server to discard entries from its history.
The arrival of a requestId in an acknowledgement message will be interpreted as acknowledging the receipt of all reply messages with lower requestIds, so the loss of an acknowledgement message is harmless.
Although the exchange involves an additional message, it need not block the client, as the acknowledgement may be transmitted after the reply has been given to the client.
However it does use processing and network resources</p> <p>Use of TCP streams to implement the request-reply protocol
It is often difficult to decide on an appropriate size for the buffer in which to receive datagrams.
In the request-reply protocol, this applies to the buffers used by the server to receive request messages and by the client to receive replies.
The limited length of datagrams (usually 8 kilobytes) may not be regarded as adequate for use in transparent RMI or RPC systems, since the arguments or results of procedures may be of any size.
The desire to avoid implementing multi-packet protocols is one of the reasons for choosing to implement request-reply protocols over TCP streams, allowing arguments and results of any size to be transmitted.</p> <p>In particular, Java object serialization is a stream protocol that allows arguments and results to be sent over streams between the client and server, making it possible for collections of objects of any size to be transmitted reliably.
If the TCP protocol is used, it ensures that request and reply messages are delivered reliably, so there is no need for the request-reply protocol to deal with retransmission of messages and filtering of duplicates or with histories.
In addition the flow-control mechanism allows large arguments and results to be passed without taking special measures to avoid overwhelming the recipient.
Thus the TCP protocol is chosen for request-reply protocols because it can simplify their implementation. </p> <p>If successive requests and replies between the same client-server pair are sent over the same stream, the connection overhead need not apply to every remote invocation.
Also, the overhead due to TCP acknowledgement messages is reduced when a reply message follows soon after a request message.
However, if the application does not require all of the facilities offered by TCP, a more efficient, specially tailored protocol can be implemented over UDP.
e.g., Sun NFS does not require support for messages of unlimited size, since it transmits fixed-size file blocks between client and server.
In addition to that, its operations designed to be idempotent, so it doesn’t matter if operations executed more than once to retransmit lost reply messages, making it unnecessary to maintain a history. </p> <p></p> </div> </div>