Re: Reliability of RPC services

[Jonathan S. Shapiro]

On Tue, 2006-04-25 at 18:10 +0200, Marcus Brinkmann wrote:
> At Tue, 25 Apr 2006 11:29:54 -0400,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > Here is an enumeration of the properties that people have talked about.
> 
> I want to extend by one term:
> 
>       receive exactly once: A caller will get exactly one reply
>       message, eventually.
> 
> My motivation is that this, combined with notice of non-reference,
> _is_ compatible with network transparency.  Considering only a local
> machine, send exactly once and receive exactly once are identical.

I agree. However, since you have now stated that receive exactly once
can be constructed from other cases that we have already defined, let us
try to avoid multiplying terms while we are untangling the discussion.

> Just for the record: My current position has not changed from the very
> first mail I wrote that started this thread, where I asked:
> 
>  1) Is RPC robustness desirable/required, or is an alternative model
>     feasible where machine-local RPC is as unreliable as IP/UDP network
>     communication?
> 
> The question is as open as before.

Oh. This can be answered:

  Yes, it is feasible, but no, this is not the question you mean to ask.

I think that the question you intend should probably be broken into two
parts:

  1. Given that an unreliable local IPC (similar to network IDP/UDP
     packet delivery reliabiliry) is feasible, can we live with it?
     What would this mean?

  2. If not, and remembering that we would like to preserve as much
     transparency across the network as possible, what additional
     mechanism(s) should we consider adding in the local case?

  3. Remember caution: applications will come to rely on these local
     mechanisms, and will then fail when the abstraction is violated
     by interposition of a network. Therefore, it is important that
     these mechanism can be simulated "well enough" that such
     applications behave "reasonably" in the rare situation that
     the network fails and transparency is (necessarily) violated.

> I have also said a lot about how I would define reply capabilities if
> I were to implement them similar to Mach, with which we have some
> experience.  But this should not be confused with a decision that
> these are the semantics I want to have.

Thank you for clarifying this. I lost sight of this during the exchange.

shap