Re: Reliability of RPC services

[Marcus Brinkmann]

At Sun, 23 Apr 2006 00:31:14 +0200,
Bas Wijnen <address@hidden> wrote:
> - A capability can be given a "send-once" flag on creation.
> - When this capability is copied, the sender's capability is invalidated.
> - When the capability is used, it is invalidated.
> - When any capability is destroyed or overwritten, AND it has the send-once
>   flag set, AND it is still valid, a death notification will be attempted.

Yes, this is what I meant with "send-once capabilities".

> AFAICS this will work fine.  The cost will not be as high as you seem to think
> either.  It can still be too high, I cannot judge that.  However, I do have an
> other solution to the problem, which will be familiar to Marcus (and it has
> been rejected before, but I don't remember why, so that may not apply here.)
> 
> On L4.X2, we planned to have a task server doing several things.  One of the
> things it had to do was managing death notifications.  For this, a task server
> capability had to be retrieved.  The only way to destroy a task was via the
> task server, so there was no way that a destruction could be missed.  Whenever
> the task server would destroy a task, it would send notifications to every
> thread which held a task server capability to it.  Also, it would not reuse
> the global thread ID until these notifications had successfully been
> delivered, but that is irrelevant here.

First, we must avoid global management like the plague.  It does
horrible things to SMP performance, for example.  See the experience
with Tornado and K42.  Maximizing locality is important.

However, in a system where process dependencies and resource
distribution are hierarchical, like ours, you can actually localize
task management, and also session management (your proposal basically
boils down to introducing user-managed sessions of some sort).  It is
unclear if a clever hierarchical structure with cheap parent-managed
sessions is feasible or not.  It's worth thinking about.

> I do agree with Marcus that UDP-style RPC operations suck, and we want
> something better.  To make clear what I (and I think Marcus) want:
>       It should be possible to design an application in such a way that it
>       can handle potentially malicious servers, other than by not talking to
>       them at all.  When the server is found to be malicious, it is the
>       user's responsibility to shoot it down.  When that happens, the
>       application should be able to recover.  A condition for that is that
>       it gets notified about the situation.

This is a good description of my initial motivation.  I agree with
Jonathan however that we must be careful not to jump to conclusions.
It is worth thinking about a system design that does not make such
guarantees, especially consider the other failure modes that exist,
even if doing so can be quite mind-boggeling.  :) Garbage collection
may be another solution.  The session based model is another option
that is at least worth pondering, if only for the intellectual
insights.  Finally, I think it is worth to look at how other systems
address this, for example systems which use thread migration or depend
on real time guarantees.
 
More thinking deemed necessary...

Marcus