The Scarpaz.
The Scarpaz Site
:: Your unreliable online reference documentation on the Scarpaz. ::
:: Via malfidinda reta dokumento de referenco pri la Skarpac. ::

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

Note: what appears here is what I prepared as a project for the "Distributes Computing Systems", a course I attended at the University of Illinois at Chicago (course number EECS573) with Professor Sol Shatz as an instructor.

[Click here to download the paper (Postscript format)]
[The software is not available]


Fig. 1. The client user interface in detailed mode.

Fig. 1. The server user interface in detailed mode.


This paper is the description of both the results and the process of writing a simple but complete RPC implementation which enforces the 'exactly once' 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.
This paper will deal with this last type of call semantics and will explore with all the details that are required to have a functioning implementation enforcing it. .

MajaMaja is powered by the Tcl Language. [jump to top of page]

The above document was last modified on 2004-04-16 06:23:46; page last updated on 2010-07-02 at 21:22:36.
Document size: 5218 bytes, plus related data up to 1.13 Mbytes.

Contents: File : 667 kbytes 2000-11-27 File : 445 kbytes 2000-11-09
rpc1.gif File : rpc1.gif 18.3 kbytes 2000-11-11
rpc2.gif File : rpc2.gif 18.4 kbytes 2000-11-11

MajaMaja is powered by the Tcl Language. [jump to top of page]
This page was last updated on 2010-07-02 at 21:22:36.
This site was automagically generated by MajaMaja version 0.298, a simple and easy to use web content manager written in Tcl by scarpaz <>.