TCP/IP Detection of Disconnect

TCP/IP Detection of Disconnect

Post by kc » Mon, 01 Jan 1996 04:00:00



Hello,

 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!

Keith C.

 
 
 

TCP/IP Detection of Disconnect

Post by Rick Jon » Wed, 03 Jan 1996 04:00:00


: (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
: ...
: 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 ?!

There is termination, and then there is termination :) If the remote
application dies or exits or such, without going through the normal
TCP graceful shutdown, then the remote TCP will probably send a RST
(reset) segment, which will be received and notification given.

That RST is not retransmitted by the remote TCP, so it is possible for
the local system to "miss" it.

Also, if the entire remote *system* goes dead, then no RST segment
will be sent.

In either of the last two cases, one has to fall-back on keepalives or
application heartbeats.

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

Not quite. There is a mandatory time that should go by before another
TCP connection between the same machines, using the same port numbers,
can be established. This time is used to help insure that a "new"
connection does not accidentally receive old, slow, delayed segments
from the "old" connection - such segments cannot be determined to be
old, and so would be accepted and could cause some * data
corruption problems.

: Could it be true that the OS can indeed tell the application that
: the other side (socket) has terminated, immediately ?

Sometimes - as described above. Again, it is not guaranteed
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 ?

I believe that is generally correct, except in one (?) flavor of
non-blocking I/O. I'm pretty sure that is described in the manpage for
read(2) and/or recv(2).

rick jones

 
 
 

1. !!DDE to TCP/IP Real Time Data Pump,Connect NT/95 to UNIX or any TCP/IP host

DDE to TCP/IP Real Time Data Pump

DDE2TCP, is a Real Time Data Pump used as a data bridge
between DDE applications and ANY host system using
TCP/IP (SUN,HP,IBM,Apple, etc).  DDE2TCP runs in the
background, totally transparent between server and target
system.

DDE2TCP is perfect for use with any MMI system such as FIX,
WONDERWARE,GENESIS,LabTech for real time update of SQL
databases residing on other hosts.  DDE2TCP comes with it's
own configurator for fast and effective setup.  DDE2TCP runs
on WINDOWS 3.1,3.11,95 and NT.  Site licenses,volume discounts
and modifications are available.  For more information on this
product or our other porducts and custom services contact:

                Marshall Rowe
                Custom Technology
                640 N. LaSalle Ste 284
                (773) 384-4104

        VISIT our WEB
        site    WWW.CUSTOM-TECH.COM                      

2. EPSON USB KIT

3. TCP/IP over fibre channel

4. Stylus 800 and 100% Cotton Paper

5. TCP IP as Loadable STREAMS modules

6. 'Creatures'

7. Verify network (TCP/IP) adapter

8. Area code 999, what is it?

9. TCP/IP Socket Buffer size

10. Running tcp/ip ports

11. Finding local and remote TCP IP addresses from HPSTREAMS in HP-UX 11.0 and KGDB

12. Socket TCP/IP - Socket Unix

13. Making a a tcp/ip connection from a alias address