CyberPeasant wrote:
> there's been an ongoing discussion on the freebsd-hackers list (I think) about
> these hanging sockets, which on a unix system can be induced by cutting
> your wire, but are the default for M$ clients. (Winsock). The bottom
> line is that M$ has twisted the RFCs, and leaves Unix servers
> hanging in a FIN_WAIT_2 state, whilst the M$ client wanders away.
> Some cynical types call this a DoS attack against Unix servers by
> M$. The debate is whether to break the RFC's and timeout these sockets,
> or to stay RFC compliant and put up with sockets that are hung "forever".
That sounds typically Microsoft. However, I don't think that this was
the issue being discussed. The question was about the client being
killed prematurely.
With TCP, this isn't an issue, although the problem of the client
system crashing is. In this case, the socket would be left in the
ESTABLISHED state, with the server waiting forever for more input
which will never arrive.
With UDP, there's the general issue that UDP servers which aren't
`stateless' (i.e. that retain resources until the client indicates
that they can be released) need some way to deal with premature
termination of the client.
> WIndoze NT servers, of course, implement a non-RFC-compliant hack to
> accommodate its "friendly" clients.
>
> This exhausts my knowlege of this subject, alas, but wanted to suggest
> the issue as a possible source of these sockets that look like
> the user just walked off. Question, then, is does Linux implement
> the hack (an 11 minute timeout?) to clear these turkeys out?
According to Stevens, some BSD derived sytems implement a timeout on
the FIN_WAIT_2 state. I would suspect that Linux does (although I
don't know), as I've never encountered an accumulation of sockets in
the FIN_WAIT_2 state.
The RFC-specified behaviour would seem to suffer from the problem that
if the remote end crashes, the local socket would be stuck in the
FIN_WAIT_2 state forever.
--
Glynn Clements <[EMAIL PROTECTED]>
