Re: synchronous RPCs vs. asynchronous RPCs

[Marcus Brinkmann]

On Fri, Sep 05, 2003 at 10:27:56PM +0200, Niels M?ller wrote:
> > But they also suck in a requirement to take care of DoS attacks in a special
> > way, and I have not found any satisfactory policy for that.
> 
> That seems to be a general problem, that one can DoS all threads that
> should be able to receive messages send with a zero timeout.

Ah, this is not what I meant, but a good point!  The client must use a
closed wait, not an open wait, so it is not suspectible to DoS attacks by
other tasks.  But this means that the server must send its reply through a
special reply thread that is known to the client (can be the main server
thread, or some other thread), so that the client can doa  closed wait on
that reply thread!  This is something new I didn't think of before.

What I meant above is that you need a way to protect against a client thread
doing lots of RPC sends without any receive.

> I see no
> good solution either. The robust way is to let the server haev one
> thread per client task to send notifications (which can then be done
> with an arbitrary timeout), but perhaps that's too costly.

This is yet another issue, but yes, if the server had a thread to spare for
each client, it could do blocking sends.  But what is gained by that?  The
server still wouldn't know what to do if it has a notification and the
notifying thread is currently blocking on a previous send.  It would have
to queue them.

> Have we already ruled out having one dedicated server thread per
> client task? Such a thread could take care of all server jobs that
> rely on the client responding in a timely manner.

I never considered it.  It seems to violate the rule to make the client
responsible for resources.

This could be feasible if you arrange it in a way to have the client provide
the resources, ie, the thread and the memory needed to queue the
notifications, via special containers or something like that.  But this
would be a quite complex solution, and difficult to harden.

> > > One should use similar mechanisms for all of poll, file and directory
> > > notifications, waitpid, and the pthread function to wait for
> > > particular signals (don't remember the name), so that one can use a
> > > *single* hurd operation to wait for i/o on fd 7, changes to the directory
> > > /bar, death of process 17, or SIGWINCH, whichever occurs first.
> > 
> > Well, this is very dandy, but now you must really not any longer duck the
> > question but tell us how notifications are implemented in the server side.
> 
> Well, perhaps I'm naive, but on the server side I imagine a list of
> subscriptions attached to each served object. Each entry specifies a
> thread to be notified, and perhaps some information about what kind of
> notifications the client wants.
>
> Whenever anything interesting happens to an object, the server checks
> the subscription list and sends messages (with zero timeout) to each
> relevant subscriber.
> 
> To make the *protocol* robust seems to be the hard part, one start is
> to do like in my task server, to let the server keep a bit for each
> subscriber that is sent when sending a notification fails. Clients
> then have to poll the server regularly to recover from lost
> notifications.
>
> And then I don't fully understand how things will work if the thread
> to receive the notification is paged out.

Well, we really are at a stage where we need detailed complete proposals. 
That somehow the server would need to keep track of notifications, and
somehow would need to try to send them with a zero time out, and somehow
lost notifications would have to be retried or recovered, that was already
clear for a long time now.  But I did not succeed in convincing, easy
solutions that would properly balance the responsibilities between the
server and the client.  This is why I am now suggesting a more radical
approach where the need for notifications is simply eliminated in most
situations.

Now, I am not proud of this possible solution, nor am I 100% sure that it
can cover all possible client server interactions, but the lack is a
convincing alternative.  So far anything that as ever been suggested for
notifications has been at the level you mention it above, which is simply
not sufficiently thought through to be set into stone.

There is a paper on asynchronous IPC in a multiserver environment on the L4
web site, which I have yet to read, and then there are interfaces like
asynchronous I/O in POSIX which I have to read and understand, before I have
amore complete picture.  So, there is room for discussion, but any
discussion must be at a high level of concreteness now.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/