How to know when client socket is down ?

[Tim Howell]

Thanks again - I did try that originally,

ret = select(listenfd+1, &readfds, NULL, NULL, &timeout);

but still no luck...

[rick jones · Accepted solution]

use tusc to make sure that the parameters to the select() call are what you think they are - try adding a -v to tusc.

[Biswajit Tripathy]

Tim,

May be I don't understand the problem
completely, but if the remote host is shutdown by
an operator "nicely", the remote TCP/IP MUST
send a FIN and terminate the connection (which
means, you will NOT have connections in
ESTABLISHED state in the server hanging
around for days).

The only 2 conditions under which the server
shows the ESTABLISHED state for connections
whose peers are down would be (1) if the peer
machine crashed, or (2) the route between client
and server goes down. In both the cases, you
could write a separate heartbeat mechanism
(may be a script) that would just ping the client
system and kill all the local applications that you
want killed when the remote system is not
ping'able. This would be much easy to do than
modifying the source code.

- Biswajit

[rick jones]

Biswajit - IIRC he said that the client is a scale on a factory floor that someone just powers-down. That is the classic sort of situation which would leave connections in ESTABLISHED on servers. "Back in the day" it was people doing that with their PCs - just hitting the power switch. These days that is less common since even PC OSes prefer to be shutdown gracefully for other reasons.

I could easily see someone just powering-down a scale.

Now...

It would be good to suggest to the scale manufacturer that they start thinking about a graceful shutdown of the device when someone hits the power switch. Afterall, their "scale" isn't just a scale any more, but a remote, weight-reporting computer :)

[Tim Howell]

Thanks to all - the issue is still open for suggestions for now while I am still persuing Rick's suggestion.

[Biswajit Tripathy]

Thanks, Rick, for explanation. I did not realise
the peculiar situation here.

Thinking aloud, I can probably see a _potential_
solution involving IPFilter system firewall here,
though I have never tried this. IPFilter system
firewall on HP-UX provides a kernel tunable
"fr_tcpidletimeout" that can be set to as small
as 5 minutes. This will remove connections in
ESTABLISHED state that are idle for more than
5 minutes. Interesting point is, it would close
only those connections that are tracked by
IPFilter (i.e that has an IPFilter rule set). For all
other connections, the system wide timeout
value should work. So, potentially, you could
set specific IPFilter rules for IP addresses of the
scales that is creating the mess and set the
"fr_tcpidletimeout" to 5 minutes that will
be applied to only those connections.

- Biswajit

[Tim Howell]

Thanks to all. Rick's solution solves my problem!

Rick,
great job - the tusc program was most helpful in troubleshooting!

Biswajit,
The IPFilter system firewall you describe is most interesting. While it doesn't solve my overall problem in this case, it is something worth studying for future needs...

Thanks again!