In distributed programming, when doing an RPC or a RMI, network exceptions may
be raised
during the transmission of a message. There exists this famous undecidability
result in
distributed programming known as the “byzantine general’s problem” which
says that it is
impossible for both sending and receiving parties to know with absolute
probability that a
message was successfully transmitted. For example, the sender which received an
exception
does not know whether the message had actually already been successfully
transmitted or not.
He also does not know whether the network connection died or the remote host
crashed.
In distributed computing, an “orphan” is a computation that was triggered
by a received message
of which the sender does not know for sure that it arrived. Orphans are
dangerous because they
might fool the sender into thinking that a message has not been executed while
it actually has.
For example, if the sender receives a network fault while transmitting a
message, he may try to
resend the message which may lead to executing the corresponding method twice.
The first
execution would be the orphan.
These kinds of problems can occur in AmbientTalk, because remote references by
default re-
enqueue failed messages. We could solve it at the implementation level by
tagging each message
with an increasing integer ID. The receiver can then filter out messages
received twice (such a
receiver is called “idempotent”). The only problem is: how long does the
receiver have to store
the last received message ID? The answer: indefinitely! because the receiver
does not know when
the sender will return. So, either we do not provide support for this but allow
the AmbientTalk
programmer to deal with failed message transmission explicitly, or we provide
system support
and then we have to put an upper bound on the connectivity of far references.
Original issue reported on code.google.com by tvcut...@gmail.com on 16 Sep 2008 at 1:30
Original issue reported on code.google.com by
tvcut...@gmail.comon 16 Sep 2008 at 1:30