Unlike normal procedure calls, there may be situations that may go wrong with RPC. A client will send a request; the server will execute the request and then return a response to the client. The possible appropriate semantics for server or network failures are listed as follows:
1. Endless waiting for the reply that will never come. This is a model of a regular procedure call. When a normal procedure goes into an infinite loop, the caller will not be able to find it out.
2. Time out and raise an exception or report failure to the client. Because finding an appropriate timer value is difficult. If the remote procedure takes a long time to execute, a timer might time-out too quickly.
3. Time out and retransmit the request.
The final possibility seems the most reasonable; it may lead to problems. Let’s consider the following: …show more content…
The client transmits a request; the server executes it, but then crashes before sending a response. If we don't get a response, is there any way of knowing whether the server acted on the request?
2. The server restarts and the client retransmit the request. What happens? Now, the server will reject the retransmission because the supplied unique identifier no longer matches that in the server's export table. At this point, the client can decide to rebind to a new server and retry, or it can give up.
3. Suppose the client rebinds to the server, retransmits the request, and gets a response. How many times will the request have been executed? At least once, and possibly twice. We have no way of knowing.
4. Operations that can safely be executed twice are called idempotent. For example, fetching the current time and date, or retrieving a particular page of a