🚀 go-pugleaf

In article <48u7ft$26o@epos.demon.co.uk> clive@epos.demon.co.uk (Clive Messer) writes:
> And anyway, at least there is the option of hacking tcp.[h,c] in the kernel
> source, or using sendmail 8.7.1 which adds an option to define a timeout to
> avoid 12 min hangs.

altering application sources won't help at all. It is the kernel
trying to complete the three way handshake to establish the
connection: it's received a SYN, and is trying to reply with SYN+ACK.

This is before the application gets to accept() the connection. The
sending application could timeout, but again it has no way of saying
'hey, ignore that SYN packet I sent you - i've shut that connection'
short of sending a RST in response to receiving a SYN+ACK (which we've
already decided it isn't getting).

As correctly stated, you need to alter the kernel's TCP source. But
what is the impact upon changing some timeout values in that code? How
can it be known whether it will affect interaction with other TCP
implementations? Not easy questions to answer.

The actual timeout, in my experience, isn't a problem. What is a
problem is the never-ceasing SYNs as the sending client keeps
attempting to initiate new connections (the resent SYN isn't a
problem): and the client is beyond the control of those operating the
server.

One proposed 'fix' to this problem, by others that have considered
it, is to store the backlog connection queue in a better structure
that would allow for these problems.

James.