Re: Reliability of RPC services

[Jonathan S. Shapiro]

On Tue, 2006-04-25 at 16:47 +0200, Bas Wijnen wrote:
> On Tue, Apr 25, 2006 at 10:07:03AM -0400, Jonathan S. Shapiro wrote:
> > A caution about "send-exactly-once": there is no such thing.
> 
> Well, call it send-exactly-once-successfully then.  The object may be locked
> after receiving one reply.  And if you have move-only, it is even possible to
> enforce that no other send can take place, given trusted network partners.

Both "send exactly once" and "send at most once" are "send once
successfully", so this does not differentiate them.

Yes, single-copy (please let us use precise terms!) can give you "send
at most once", but single copy is not necessary in order to achieve
this.

> > One of the things that we should try to preserve is the possibility of
> > extending capabilities across a network. It is well known that (1)
> > "send-exactly-once" cannot be implemented across a network, and (2) if a
> > watchdog terminates a connection, there is a fundamental race: the server
> > will not know that the session is gone until it tries to reply, which may be
> > after it completes the operation. All of this is true because of network
> > partitions.
> 
> You mean the cable is cut, and the computers can no longer communicate, and
> therefore the watchdog times out but it cannot notify the other computer due
> to the broken cable?
> 
> I could think of some schemes involving a wall clock where even then
> send-exactly-once will work.

No you cannot. It has been formally proven that this is impossible. Your
proposal is to use a watchdog, which is not what is meant by "send
exactly once".

> > *Because* we want to preserve this possibility, I think that this is
> > also the correct baseline architecture for local failures. If we
> > introduce a cancellation mechanism, we must understand that cancellation
> > is best-effort, and not guaranteed.
> 
> Wait, let me rephrase this.  Do you mean:
>       We want to be able to use the system on crappy hardware, therefore we
>       aren't going to use the full capacity of normal (and hardly any
>       capacity of really good) hardware when it is available to us.

No. I mean "We want to design a system that respects the fundamental
laws of physics, and we should not delude ourselves about what is
technically possible." I am not sure how you inferred "crappy hardware"
from "network transparency".

shap