On 7/4/07, skaller <skaller@xxxxxxxxxxxxxxxxxxxxx> wrote:
On Wed, 2007-07-04 at 12:34 +0200, Eric Dumazet wrote: > On Wed, 04 Jul 2007 19:56:29 +1000 > skaller <skaller@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > I wonder if someone can tell me what Linux does here. > > > > First: it seems to me Posix specification are such that > > the behaviour on closing a socket is unspecified, except > > if the socket is blocking and SO_LINGER is used to specify > > a timeout. In that case the close blocks until written data > > is sent down the wire or the nominated timeout expires. > > > > IMHO this specification is unacceptable because it makes > > reliable non-blocking socket operations impossible. > > However I may misunderstand the spec. > > > > Second: I have observed that in non-blocking mode, > > Linux discards written data without sending it down the wire. > > As above: this seems unacceptable, although it conforms to > > Posix 'in vaccuuo' :) > > > > Can anyone tell me what Linux *actually* does? > > > > In my understanding, the behavior at close() time depends if > you still have data in receive queue. > > If you dont have data wating in receive queue > (but possibly some data in output queue), then stack sends > data and FIN, no loss of data. > > However, If you have some unread data, then a RST is sent > (and data in output queue is lost). > So maybe your app is actually closing a socket with > unread data (this would be an application error) There is *definitely* unread data in the receive queue in our test case. Looks like, after reading what it wants, the application (a brain dead web server) should do a shutdown on input. (A shutdown on the output IS being used). Otherwise the RST is sent, triggering the client to close its READER, and send a RST back to the server, which then shuts down its writer. Is that right? [I can't see why the kernel would flush the output queue just because the application hasn't shutdown the input side of the link]
Closing on input didn't help me. I think we're dealing with a fundamental tcp ambiguity here. That would explain why every web server out there has a function called "lingering_close". I think it's the only portable way to close an http socket... I'll try implementing a version for the flx web server. - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
