Determining whether a TCP connection is up

[Lars Magne Ingebrigtsen]

TCP connections may go AWOL in many different ways.  The most common
reasons are 1) changing IP address on a laptop, 2) the "router" changes
IP address when you're on a laptop tethered to a telephone, and 3) the
server dies.

In some cases (like in 1 and 2) you will perhaps get a TCP reset from
the server when you issue a command.  That's fine, and solves the
problem.

But, these days, most services are behind firewalls that just drop
packages that come on connections it doesn't know about.  So you get no
packets in return.  The same is true for 3).

So the only way to see whether a TCP connection is up is really to send
a command and see whether you get anything back.

Having to implement that kind of logic for all the network protocols is
tedious and can't be done generally.

For one, you have to establish reasonable timeouts, but there are none
that can be used generally.  For instance, when you send a DELETE
command to an IMAP server, it may take 20 seconds for it to remove the
message and re-create a big folder.  You don't want to wait 20 seconds
in general before saying "ok, we have a timeout and should reconnect".

So it would be fantastic if it was possible to do...  something...  to
make the following pseudo-code work:

(while (not done)
  (accept-process-output process 0 1)
  (when (and (absolutely-nothing-was-received)
             (> timeout two-seconds)
             (not (probe-for-connection-up)))
    (kill-process-and-reconnect process)
    (replay-commands)))

You get the drift.

So the problem is `probe-for-connection-up'.  Is there a general TCP way
to probe for a connection?  Can we (for instance) send a TCP KEEPALIVE
once and see whether we get anything back within (say) a second?

Or do something else that's clever?

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php