Discuss the invocation semantics that can be achieved when the request-reply protocol is implemented over a TCP/IP connection
- 1. Page | 1 MADURAI KAMARAJ UNIVERSITY University with potential for excellence ASSIGNMENT ON DISTRIBUTED SYSTEM Team No: 10 Team members:- a. Ram Narayan Kumar.(B244038) b. Pawan Kumar Singh.(B244033) c. Vikash Kumar Dubey.(B244060).
- 2. Page | 2 5:- The Election interface provides two remote methods: vote: with two parameters through which the client supplies the name of a candidate (a string) and the‘voter’s number’ (an integer used to ensure each user votes once only). The voter’s numbers are allocated sparsely from the range of integers to make them hard to guess. result: with two parameters through which the server supplies the client with the name of a candidate and the number of votes for that candidate.Which of the parameters of these two procedures are input and which are output parameters? vote: input parameters: name of candidate, voter’s number; result: output parameters: name of candidate, number of votes 5.2 QUESTION: 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? Ans: In the first case, the implementor assumes that if the client observes an omission failure it cannot tell whether it is due to loss of the request or reply message, to the server having crashed or having taken longer than usual.
- 3. Page | 3 Therefore when the request is re-transmitted the client may receive late replies to the original request. The implementation must deal with this. the implementor assumes that if the client observes an omission failure it cannot tell whether the omission is because of loss of the request or reply message, or because of the server having crashed or having taken longer than usual. Therefore when the request is re- transmitted the client may receive late replies to the original request. The implementation must deal with this. In the second case, an omission failure observed by the client cannot be due to the server taking too long. Therefore, when the request is re-ransmitted after time T, it is certain that a late reply will not come from the server. There is no need to deal with late replies. In this way, the implementation is simplified. an omission failure observed by the client cannot be due to the server taking too long. Invocation semantics • Local invocations are executed exactly once • Remote invocations cannot achieve this. Why not? – the Request-reply protocol can apply fault-tolerance measures Fault tolerance measures Invocation semantic Retransmit message Duplicate filtering Re-execute or retransmit reply No Yes Yes Not No Yes Not applicable Re-execute Retransmit reply At-most-once At-least-once Maybe
- 4. Page | 4 Remote and local method invocations Therefore when the request is re-transmitted after time T, it is certain that a late reply will not come from the server. There is no need to deal with late replies. Asynchronous communication is typically performed on channels. Communication is used both to synchronize operations of the concurrent system as well as to pass data. A simple channel typically consists of two wires: a request and an acknowledge. In a '4-phase handshaking protocol' (or return-to-zero), the request is asserted by the sender component, and the receiver responds by asserting the acknowledge; then both signals are de-asserted in turn. In a '2- phase handshaking protocol' (or transition-signalling), the requester simply toggles the value on the request wire (once), and the receiver responds by toggling the value on the acknowledge wire. Channels can also be extended to communicate data. invocation invocation remote invocation remot local local local invocation invocation A B C D E F
- 5. Page | 5 Asynchronous datapaths are typically encoded using several schemes. Robust schemes use two wires or 'rails' for each bit, called 'dual-rail encoding'. In this case, first rail is asserted to transmit a 0 value, or the second rail is asserted to transmit a 1 value. The asserted rail is then reset to zero before the next data value is transmitted, thereby indicating 'no data' or a 'spacer' state. A less robust, but widely used and practical scheme, is called 'single-rail bundled data'. Here, a single-rail (i.e. synchronous-style) function block can be used, with an accompanying worst-case matched delay. After valid data inputs arrive, a request signal is asserted as the input to the matched delay. When the matched delay produces a 'done' output, the block guaranteed to have completed computation. While this scheme has timing constraints, they are simple, localized (unlike in synchronous systems), and one-sided, hence are usually easy to validate. Client-side implementation of minimum execution time Akeeba Backup splits the backup process into smaller chunks, called backup steps, to prevent backup failure due to server time-out or server protection reasons. Each backup step has a minimum and maximum duration defined by the Minimum Execution Time, Maximum Execution Time and Execution Time Bias parameters in this Configuration page. If the step takes less time to complete than the minimum duration Akeeba Backup will have to wait. When this box is unchecked (default) Akeeba Backup will have the server wait until the minimum execution time is reached. This may cause some very restrictive servers to kill your backup. Checking this box will implement the waiting period on the browser, working around this limitation.