Re: [Fresco-devel] Pinging stopped clients

On Mon, Dec 09, 2002 at 03:15:08PM -0500, Stefan Seefeld wrote:
> I there any way for the server to find out what causes
> the client not to reply to pings any more ?

I think the only way is if the client makes sure to tell the server,
from a signal handler or something.  I worry that this is extremely
fragile and error-prone.

In particular, you can't make a CORBA call directly from a signal
handler; you have to have some elaborate system where you set a flag
in a signal handler saying "we should be reacting to a signal ___
now", then the program's main loop (hopefully it has one!) has to be
ready to notice that flag in a timely fashion, and then notify the
server, disable the signal handler, and re-raise the signal...

And even this won't help for all signals, because, in the wise words
of libc.info:
   - Macro: int SIGSTOP
     The `SIGSTOP' signal stops the process.  It cannot be handled,
     ignored, or blocked.

(Nor, I think, is it particularly desirable for our protocol to assume
a finite set of process states (those achievable in UNIX) are all the
ones that are possible.  That's a bit too much coupling for my taste.)

So what can we do?  I don't think there's a way using CORBA to properly
distinguish those clients that have fallen into a black hole and those
that are merely stopped.  That leaves two options:
  1) don't try; use some elaborate CORBA tricks to at least make the
     server robust (timeouts, once supported; otherwise,
     thread-per-ping or the like.  ick.)
  2) use something besides CORBA -- eg, create a secondary TCP
     connection to the client, and use its status to monitor the
     client's health (and perhaps allow the client to monitor the
     server's health in a parallel manner).  Of course, one has to
     actually send data down this connection to keep it alive, meaning
     the other end has to be prepared to handle this incoming data,
     which adds extra complexity to the client side (since no longer
     can the client simply assume that its ORB will take care of all
     networking stuff for it).  Ick.

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould

This email may be read aloud.