From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 17:46:45 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60E7B16A468 for ; Mon, 25 Jun 2007 17:46:42 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 30F1E13C447 for ; Mon, 25 Jun 2007 17:46:42 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gurtj6ev04js16fg@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l5PHkepB083241; Mon, 25 Jun 2007 10:46:40 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l5PHkdPp083240; Mon, 25 Jun 2007 10:46:39 -0700 (PDT) (envelope-from jmg) Date: Mon, 25 Jun 2007 10:46:39 -0700 From: John-Mark Gurney To: Julian Elischer Message-ID: <20070625174639.GC1221@funkthat.com> Mail-Followup-To: Julian Elischer , Bruce Evans , FreeBSD Net References: <467C727D.4060703@elischer.org> <20070626023944.M82078@besplex.bde.org> <467FF8BB.1040507@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467FF8BB.1040507@elischer.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: FreeBSD Net Subject: Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 17:46:45 -0000 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."