A complete RPC implementation enforcing the 'exactly once' call semantics.

An RPC implementation based on a unreliable message passing mechanism can exhibit different type of behaviours and guarantee different objectives, depending on which type of call semantics was chosen by the designer:

• the maybe call semantics does not offer any guarantees about the result of the call; if the request message from the client or the reply message from the server should get lost, there is no way to successfully complete the call;
• the at least once call semantics guarantees about that, upon return from call, at least one reply was received from the server and that the remote called routine was executed at least once. To enforce this semantics some additional modifications are required, we have to provide a limited amount of intelligence on board of the client, in order to keep it sending (in association with a timeout) request messages until a reply message manages to successfully reach the client. The main advantage of this call semantics is that, when control is yielded back to the caller on the client side, at least one successful execution is guaranteed to have taken place; the main disadvantage, on the opposite side, is that the called server routine could have been executed many times, thus rendering this semantics safe only for idempotent procedures. One could argue that by using a pure functional programming style, everything could be implemented by using idempotent procedures only (the procedures are thought as stateless machines that, given an input, yield an output and have no side-effects at all) but I would like instead to put emphasis on the fact that when implementing a client-server database application, the side-effects are the core of what we are interested in and the functional aspect of the remote procedures is almost unimportant. Let us consider as an example the case of 'deposit', a remote procedure that allows to deposit a given amount of money on a given bank account: The actual update of the account record in the database is the side-effect and practically there is no output, if we do not consider some completion status as output. The database itself is a result of side-effects, therefore refusing the possibility of side-effects means in this case refusing the feasibility of a database application.

  Once stated that we indeed need non-idempotent procedures, we also need to find a suitable call semantics that allows us to execute them remotely in full safety;

• the exactly once call semantics guarantees that, upon return, the called procedure was executed once and once only. I will not need to explain why it is not desirable that functions like the 'deposit' are executed multiple times when their execution is desired only once, it seems to me quite self-evident. To enforce the exactly once call semantics, additional intelligence is required on both the client and the server side, basically the client has got to number each request message with a progressive identifier so that the server has the ability to recognize multiple repeated messages that correspond to the same original request (and therefore have the same identifier): In this case the server avoids repeating the execution and instead replies to the client with the result of the procedure unique execution which was stored.