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().
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.
Bruce
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
