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

In response to Julian Elischer <julian@xxxxxxxxxxxx>:

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.

Correct me if I'm wrong, but I took Bruce's explanation to mean that the
problem is not in FreeBSD, it's the fault of the application not using
non-blocking IO in the manner it was intended.

If you want properly closed connections, you turn of non-blocking before
you close the connection. If you want fast close that's not contingent on
anything, you close non-blocking and accept that some data may be lost and
some errors may result.

If you tell the OS to drop packets and it drops them, the OS isn't in error
for following orders.

Or did I misunderstand?

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@xxxxxxxxxxxxxxxxxxxxxxx
Phone: 412-422-3463x4023
_______________________________________________
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

  • Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows.
    ... Yes, Blame Microsoft, but we are breaking the TCP spec, not them. ... A TCP socket isn't the same thing as a named pape or FIFO. ... Using non-blocking I/O does not mean one can suddenly shortcut the FINWAIT-1 and FINWAIT-2 states before going into TIME_WAIT, nor the 2 * MSL timeout before the TCP control block is allowed to go away. ... Otherwise, you might end up sending a RST to a dup'ed packet like a stray ACK, which seems to be almost exactly the problem at hand. ...
    (freebsd-net)
  • Trying to learn Non-Blocking sockets on Solaris 8, please help! ready to fork() it.
    ... how to setup a non-blocking socket. ... I've found limited information on ... opening a socket and using the ioctlto set it to non-blocking ... Whats the differance between fcntl and ioctl? ...
    (comp.unix.programmer)
  • Re: java socket i/o with callback/non-blocking
    ... Basically I want to have some subroutine to be called whenever there is data available to read on a socket object without having to poll it. ... Note also that the technique described is blocking, not non-blocking, as indeed is the technique you described even if the channel is in non-blocking mode. ... For just one socket, you are probably much better off to dump all the NIO stuff, and simply use blocking I/O in its own thread. ...
    (comp.lang.java.programmer)
  • Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows.
    ... Yes, Blame Microsoft, but we are breaking the TCP spec, not them. ... A TCP socket isn't the same thing as a named pape or FIFO. ... Using non-blocking I/O does not mean one can suddenly shortcut the FINWAIT-1 and FINWAIT-2 states before going into TIME_WAIT, nor the 2 * MSL timeout before the TCP control block is allowed to go away. ... Otherwise, you might end up sending a RST to a dup'ed packet like a stray ACK, which seems to be almost exactly the problem at hand. ...
    (freebsd-net)
  • Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows.
    ... needs to set eh non-blocking socket option and use kqueue or similar ... to schedule work. ... This seems to be the correct behaviour. ...
    (freebsd-net)