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) ?