l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reliability of RPC services


From: Bas Wijnen
Subject: Re: Reliability of RPC services
Date: Tue, 25 Apr 2006 16:47:29 +0200
User-agent: Mutt/1.5.11+cvs20060403

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.

> 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.  Lock the capability after a certain timeout, and
really drop it after a second timeout.  If the connection is reestablished in
between, they have to negotiate what state they are in.  If for any side the
second timeout has expired, the capability is really lost.  Care must be taken
that the second timeout on one machine cannot expire before the first timeout
on the other machine has certainly expired as well.

> *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.
?

That sounds like an incredibly bad idea to me.

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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]