Re: [Fresco-devel] Pinging stopped clients

On Mon, 2002-12-09 at 10:03, Nathaniel Smith wrote:
> Oh, sure, it could do all those things.  I'm confused because it
> doesn't do any of them -- it doesn't even time out.  The remote call
> just sits there waiting indefinitely for the client to start running
> again.

What about if you then kill it with SIGKILL? Does the connection time
out then? Surely the (TCP/unix) connection doesn't time out because the
OS knows the process is still there. Perhaps the ORB relies on the
transport to give timeout errors.

> The somewhat obscure point I was making with the above comment,
> though, is that all these methods will screw up with a client that is
> stopped but not yet dead.  A stopped client cannot respond to pings;
> therefore, a correct implementation of pinging will detect that they
> are not responding to pings, and infer that they must be dead, and
> kick them off the server.  So killing stopped clients is correct
> behaviour for a ping-based solution.  It's not exactly an optimal
> solution overall, though :-(.

One way is to dedicate a thread to each client (server context), and use
that to make all calls into the client. That way, if a client is going
slow or whatever, it doesn't affect anything else. I have used this
model before for IPC at my work experience. The downside is that you
have to either make the calls asynchronous, or accept a timeout.

It works by having an "active object": an object with a worker thread
waiting on an event queue, and executing events in that thread. There
are methods to add events to the queue from any thread and wake up the
worker thread if it is sleeping. Events can either be functors, or a
struct including an enum which is switched on. (Obviously the functor is
more maintainable, but you end up writing a dozen functors which is bad
for other reasons). The add-event methods can take timeouts for waiting
for the worker thread to finish an event, and you could even maintain
some kind of state (eg: client slow, client stopped, etc as per Sean's
idea.)

This would work well for Command-type callbacks. Not so well for
traversals though - what happens to the drawingkit calls after the
timeout? Some kind of proxy for that will be needed that can unwind the
DK stack on a timeout and then ignore further calls from the client
until the next traversal. It may also require changes to the API
(Fresco) so that it is clear which client owns the Command, which client
owns the Graphic, etc.

As an aside, though I think it was alluded to before, killing a stopped
client is not good (I occasionally ^Z a gui program run from a terminal
for a while, expecting it to still be there half an our later!). But
handling a stopped client is not easy though - what if the user is
hammering on the GUI in the server, queuing up events to a stopped
client. What is the sensible thing to do with those events (queue,
discard) if the client has been stopped for 5 seconds? 5 minutes? an
hour?

-- 
  //------=[ Chalky aka Stephen Davies -- [email protected] ]=------\\
 //----=[ B.App.Sci(Comp.Sci) B.Eng(Comp.Sys.Eng)(Hons) RMIT ]=----\\
//--=[ Programmer Python/C++/Java/C# - Project: Synopsis.sf.net ]=--\\