Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows.

Julian Elischer wrote this message on Mon, Jun 25, 2007 at 10:17 -0700:
Bruce Evans wrote:
On Fri, 22 Jun 2007, Julian Elischer wrote:

If one has an event-driven process that accepts tcp connections, one
needs to set eh non-blocking socket option and use kqueue or similar
to schedule work.

This is ok for data transfers, however when it comes to the close()
call there is a problem. The problem in in the following code in
so_close()


if (so->so_options & SO_LINGER) {
if ((so->so_state & SS_ISDISCONNECTING) &&
(so->so_state & SS_NBIO))
goto drop;
...
drop:
[ continues on to destroy socket ]


because SS_NBIO is set, the socket acts as if SO_LINGER was set, with
a timeout of 0.
the result of this, is the following behaviour:

[ patckets in flight get lost ]

This seems to be the correct behaviour. The application doesn't care
about its data and/or wants to close the descriptor without blocking,
so it doesn't turn off the blocking flag and/or wait for i/o to complete
(so that it can see if the i/o actually worked) before calling close().

It's not the correct behaviour if the only packet coming back is an Ack of
the FIN (and a FIN) because in the real world, making IE7 throw an error
screen is not an acceptable option. This is the sort of thing
that gets FreeBSD thrown out on favour of "anything else".
Believe me, our customers are "NOT HAPPY" about this.
Instead of getting an "authorization required" page along with
the opportunity to log in, they get an error, and no opportunity
to log in, which makes the system unusable.
Yes, Blame Microsoft, but we are breaking the TCP spec, not them.
We need to fix this some how.

As bde mention, the bug is in the application... Even SUSv2 says:
When all file descriptors associated with a pipe or FIFO special file are closed, any data remaining in the pipe or FIFO will be discarded.

Our own close(2) says:
on the last
close of a socket(2) associated naming information and queued data are
discarded

So, failure of the application to ensure that all data is sent is the
application's fault... bde alluded to a simple work around of clearing
the non-blocking flag which will return close to the "expected" (but
apprently broken) behavior of keeping the tcp socket around till all
remaining data has been sent...

I must note that the code you quoted has been in FreeBSD since 2.0.

I implemented this behaviour for tty drivers in FreeBSD. Old BSD tty
drivers didn't check the nonblocking flag and didn't have a timeout,
so close() on tty devices tended to hang forever (normally at long
weekends) even for closes that should have been nonblocking.

--
John-Mark Gurney Voice: +1 415 225 5579

"All that I will do, has been done, All that I have, has not."
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages