[muscle] Re: Client killed

  • From: Jeremy Friesner <jaf@xxxxxxxxxxxx>
  • To: muscle@xxxxxxxxxxxxx
  • Date: Fri, 14 Jan 2005 11:29:27 -0800

Hi Julien,

It depends on how the client dies.  If the client dies "nicely" (i.e. the=20
client process exits or crashes, but its operating system and physical=20
network connection to the server continue to operate correctly) then the=20
client PC will send a TCP_DISCONNECT type packet to the server and the serv=
er=20
will know to immediately close the connection.  (This is the behaviour you=
=20
should see if you control-C the client... almost instantaneously the server=
=20
should know about it)

If, on the other hand, the client dies "unexpectedly", in such a way that=20
there is no chance for it to send a TCP_DISCONNECT packet to the server (i.=
e.=20
someone yanked the power cable or network cable out of the client PC, or th=
e=20
client's OS crashed, or the client's ISP's router crashed, etc), then the=20
server has no good way of knowing that the client has gone away.

If the server is trying to send data to the client when that occurs, the TC=
P=20
packets will start timing out, and eventually (usually after several minute=
s)=20
the server will give up, assume the client is dead and close the TCP=20
connection.  If the server is not trying to send any data to the client (i.=
e.=20
the TCP connection is completely idle) then it could be a long time before =
it=20
notices the client has gone away... possibly several hours.

If it is important to know quickly when a client has gone away (even in the=
=20
case where the client crashed) then way to do that is by having the client=
=20
and server send "Hi, I'm still alive" type Messages to each other every so=
=20
often -- in my own muscle-based app I implemented a system where these=20
keepalive Messages are sent every few seconds, but you can pick a rate that=
=20
is appropriate based on your application's needs.

Note that just sending some data back and forth is enough to get the TCP=20
protocol to "notice" that a client is not responding (due to too many=20
packet-ack-timeouts) after a few minutes... if you need quicker response ti=
me=20
than that, you will need to add logic to your server that force-disconnects=
=20
the client if the server hasn't received any data from the client within th=
e=20
timeout period you specify.  Of course, the downside of this is that if you=
=20
make the timeout period too small, you risk disconnecting clients that are=
=20
still alive, just slow for some reason.

As far as Qt signals go, I've only implemented Qt on the client side, but o=
n=20
the client side you would see the=20
QMessageTransceiverThread::SessionDisconnected(const String &) signal emitt=
ed=20
when the TCP connection is broken.

Hope that helps,
Jeremy

On Friday 14 January 2005 09:10, Julien Torr=E8s wrote:
> I have an application with one server and several clients. Is there a=3D20
> way to detect (by the server and by the other clients) if a client is=3D20
> killed ? Is there a QT signal emitted (this does not seems to be) ?

Other related posts: