[cap-talk] RPC failure (was: Re: Notes from Butler...)

[Jed Donnelley]

At 09:31 PM 4/9/2008, Jonathan S. Shapiro wrote:
>On Wed, 2008-04-09 at 19:13 -0700, Jed Donnelley wrote:
>...
> > He says that RPC has been a failure because the
> > basic idea of it was to mask the fact that the
> > call is remote and 'that turns out to be a mistake'.
>
>I think that is absolutely right. Crossing a failure domain is
>semantically significant. The problem is not the "remoteness" but the
>presence of unhandled exceptions.
>
>Note, however, that this is much less serious in a language that
>provides integrated exception handling, and Butler's evaluation is being
>driven by experience in C and in pre-working-exceptions C++.

The above got me thinking a bit about systems like DCCS and
cross-vat E and contrasting with systems where message
semantics are more explicit (e.g. NLTSS).

If you listen to the rest of Butler's argument in this
area he says something to the effect that communicating
remote processes ultimately 'need' the full capabilities
of "TCP".  This discussion starts at:

13:41 in: http://www.usenix.org/events/usenix06/tech/mp3/lampson.mp3

for anybody who wants to listen in full.  Literally:

"The basic reason is that if you do run into trouble its
very difficult to do anything about it, because you don't
have any control over what's going on.  If you cooked up
your request/response communication yourself by hand over
TCP, then you can go in there and hack it when it turns
out that you didn't do it quite right.  (But) If you used
RPC then you're stuck with what the RPC system wants,
and its unlikely to be what you need.  Very sad but true."

This is puzzling to me because I think all you get
with TCP at the transport level is:

open, close, how much data was sent, and how much
data was received.

I personally don't believe that open and close
contribute anything.  That might be an interesting
point of discussion, but perhaps not on cap-talk?

The addition of how much was sent or received
seems rather thin semantically.  How important
do others feel that is?  For example, are the E
message passing semantics rich enough to add back
whatever value Butler or Jonathan or others feel
is missing in "RPC"?  Do they include how much
got through?  It seems to me that if neither side
gets any "how much" indications (either all or
nothing or undetermined failure) then the "how much"
wouldn't be missed.  I guess you can't do partial
buffer processing, but does that add anything
semantically important?

The NLTSS system had message semantics essentially
equivalent to TCP.  I believe the only real value
it contributed over RPC was the ability to deliver
long bit strings (yes, in NLTSS we dealt with bits
rather than bytes - we had some 36 bit systems to
deal with) in partial buffers, such as writing
a lot of data to a file with one write but multiple
data buffers.

I have to admit that this seems a rather minor
point to me.  I can accept that there needs to
be some sort of "exception" for a failed invocation.
I think that its also sometimes important to be
able to control sending/receiving long strings
of bits/bytes with partial buffers.  Is more needed
beyond that?  Do others feel this is an important
point (failure of RPC because more TCP semantics
aren't exposed)?

--Jed  http://www.webstart.com/jed-signature.html