Very Computer

by **Christopher Bar** » Thu, 20 May 1999 04:00:00

I need a way of deciding if a socket is dead, and not idle. The problem I'm having is that on my windows client if I power off the machine (or unplug the network cable) while there is a socket open between it and my unix server, the unix server can't tell the that the socket is dead as opposed to idle (nothing is sent across the socket both ways, if I were lucky enough for the windows program to crash Windows would send we a message, but if my user manages to disconnect himself/herself or unplug their ne
twork connection my server assumes they are just idle).
I've looked at using SO_KEEPALIVE, but sends acknowledgements once every 2 hours by system default and I don't want to decrease that, actually I don't want to play with the system configuration if possible. Is there any other way of doing this? Is it possible (How can the server tell the difference between a dead connection and one with a _really_ bad lag)? Does R.Stevens book cover this?

--
Christopher Bark
4th Year Comp Sci
Carleton University

by **Andrew Giert** » Thu, 20 May 1999 04:00:00

Christopher> I need a way of deciding if a socket is dead, and not
Christopher> idle.
[usual tale of powered-off 'doze client]

Christopher> I've looked at using SO_KEEPALIVE, but sends
Christopher> acknowledgements once every 2 hours by system default
Christopher> and I don't want to decrease that, actually I don't want
Christopher> to play with the system configuration if possible. Is
Christopher> there any other way of doing this? Is it possible (How
Christopher> can the server tell the difference between a dead
Christopher> connection and one with a _really_ bad lag)?

The server can only detect that the client has gone away if it tries
to send some data to it, in which case the retransmit timer will
expire (though even this takes a few minutes to detect).

Another commonly-used approach is for the server to use an
application-level timeout (e.g. "if no request received from the
client for X minutes, drop the connection"). FTP, SMTP, etc. use this
approach.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>

by **John Burto** » Thu, 20 May 1999 04:00:00

> I need a way of deciding if a socket is dead, and not idle. The problem

I'm having is that on my windows client if I power off the machine (or
unplug the network cable) while there is a socket open between it and my
unix server, the unix server can't tell the that the socket is dead as
opposed to idle (nothing is sent across the socket both ways, if I were
lucky enough for the windows program to crash Windows would send we a
message, but if my user manages to disconnect himself/herself or unplug
their ne

Quote:>twork connection my server assumes they are just idle).
> I've looked at using SO_KEEPALIVE, but sends acknowledgements once every 2

hours by system default and I don't want to decrease that, actually I don't
want to play with the system configuration if possible. Is there any other
way of doing this? Is it possible (How can the server tell the difference
between a dead connection and one with a _really_ bad lag)? Does R.Stevens
book cover this?

You have to send your own "heartbeat" messages periodically. If you fail to
write one you know your client has died.

by **Bryan VanDeVe** » Sat, 22 May 1999 04:00:00

> I need a way of deciding if a socket is dead, and not idle. The problem I'm having is that on my windows client if I power off the machine (or unplug the network cable) while there is a socket open between it and my unix server, the unix server can't tell the that the socket is dead as opposed to idle (nothing is sent across the socket both ways, if I were lucky enough for the windows program to crash Windows would send we a message, but if my user manages to disconnect himself/herself or unplug their ne
> twork connection my server assumes they are just idle).
> I've looked at using SO_KEEPALIVE, but sends acknowledgements once every 2 hours by system default and I don't want to decrease that, actually I don't want to play with the system configuration if possible. Is there any other way of doing this? Is it possible (How can the server tell the difference between a dead connection and one with a _really_ bad lag)? Does R.Stevens book cover this?

Well you will have to pick some arbitrary time limit yourself, and from
Stenvens, section 13.2:

"There are three ways to place a timeout on an I/O operation involving a
socket.

1. Call alarm, which generates the SIGALRM signal when the specified
time has expired. ...

2. Block waiting for I/O in select, which has a time limit built in,
instead of blocking in a call to read or write.

3. Use the newer SO_RCVTIMEO and SO_SNDTIMEO socket options. ..."

Andjust glancing at section headings in chapter 5...

5.6 Normal Startup
5.7 Normal Termination
5.11 Conection Abort before accept Returns
5.12 Termination of Server Process
5.13 SIGPIPE signal
5.14 Crashing of Server Host
5.15 Crashing and Rebooting of Server Host
5.16 Shutdown of Server Host

Really, I can't imagine doing any kind of serious sockets programming
without UNP volume 1 within arm's reach.

--
Bryan Van de Ven
Applied Research Labs
University of Texas, Austin

Very Computer

idle tcp sockets and dead sockets

idle tcp sockets and dead sockets

idle tcp sockets and dead sockets

idle tcp sockets and dead sockets

idle tcp sockets and dead sockets