Re: Reliability of RPC services

[Bas Wijnen]

On Tue, Apr 25, 2006 at 12:23:42PM -0400, Jonathan S. Shapiro wrote:
> > > 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.

I'd like to see that proof then. :-)

> Your proposal is to use a watchdog, which is not what is meant by "send
> exactly once".

Well, a watchdog combined with send-on-destroy.  I didn't mention this, but I
was still talking about move-only-send-exactly-once capabilities, which must
have send-on-destroy (otherwise they are send-at-most-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."

Even though strictly speaking it is correct that also inside a CPU or on a
motherboard a signal might get lost, the chance that you still have a
functioning system when that happens is minimal.  Compared to a network where
a broken cable doesn't actually break the system, this is a very different
situation.  I think on one machine it is reasonable to assume that wires
aren't broken, and signals don't get lost.  If they do, the computer should be
replaced (or at least a part of it).

> I am not sure how you inferred "crappy hardware" from "network
> transparency".

When I think about writing an OS, I think about writing it on one computer.
That means, as I wrote above, that I assume that things work.  On a network
that is much less likely to be a valid assumption, and people expect recovery
if something fails there.  This is not the case (or at least not to the same
degree) inside one computer.

So what I'm saying is that if you consider a network as the "machine" to write
an OS for, then the failure-rate of that machine is very high, so the hardware
is crappy compared to "usual" computers.

You wrote you want to be able to expand the system to a network "machine", and
therefore you don't want to use certain constructs which perhaps cannot handle
the fragility of such a machine.  Or at least that's how I understood it, but
please correct me if I'm wrong. :-)

That sounds to me as if you want to design the system in a way that it can
handle broken wires on the memory bus.  That would be a pretty useless feature
IMO, and (if there are high costs to it, which is likely) very unwanted, too.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature