Re: synchronous RPCs vs. asynchronous RPCs

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> On Fri, Sep 05, 2003 at 02:33:42PM +0200, Niels M?ller wrote:
> > I don't know about msync, for I care about poll. I think it is
> > important to be able to poll/select on thousands of objects, without
> > using thousands of threads.
> 
> As long as the thousands of objects are not provided by thousands of
> different servers, there is no problem.  Even in my synchronous model you
> would only use on thread per server, and combine all objects in a single
> RPC.

Ah, that might work. A common case is having a thousand open tcp
connections, but then they're all in pfinet.

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

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.

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

Regards,
/Niels