A fellow co-worker asked me what could be done inside his application for
implementing a detection scheme for possible termination of an associated
TCP/IP socket communication server (more accurately he wanted
something that would immediately detect the termination of the other side). I
told him nothing could be done, unless he was prepared to write some
application level "heart-beat" protocol that instituted some sort of polling
protocol above and beyound TCP/IP behavior (we had already discussed the
SO_KEEPALIVE option and it's slow responsiveness). He obviousily did not
believe me and proceeded writing a simple server/client program (on HP-UX)
and now claims that (inside the server) when using the select() on the
listen socket (and all other established connections) he gets immediate
determination of a client disconnect, he says that the select() returns
immediately (I was shocked!); then he proceeds to do his read() on that
socket fd and it returns 0 (zero) bytes and that, he says, is the only
determinant needed to assure him that the client terminated. Thus he says I
was dead wrong. Can someone please tell me what might be going on here ?!
All of this time I thought that there was a mandatory TCP/IP time-out period
that ocurred before disconnect detection from either side (FIN_WAIT_1,
FIN_WAIT_2, and TIME_WAIT as per Richard Steven's defacto material) ?
Could it be true that the OS can indeed tell the application that the other
side (socket) has terminated, immediately ? And finally is it safe to assume
that a return of zero (0) bytes from the read() is always indication of the
other side's termination. Or could a zero (0) return on read() be a valid
occurance in regular processing/traffic flow where TCP/IP is concerned ?
Any help would be much appreciated !!
HAPPY NEW YEAR & Thanx!