Re: socket close

[skaller]

On Wed, 2007-07-04 at 15:35 +0200, Eric Dumazet wrote:

> > 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]
> 
> You may take a look at RFC 1122 ( http://www.faqs.org/rfcs/rfc1122.html )
> section 4.2.2.13  Closing a Connection: 
> 
> "A host MAY implement a "half-duplex" TCP close sequence, so
>             that an application that has called CLOSE cannot continue to
>             read data from the connection.  If such a host issues a
>             CLOSE call while received data is still pending in TCP, or
>             if new data is received after CLOSE is called, its TCP
>             SHOULD send a RST to show that data was lost."
> 
> If your app is doing a close() on a socket where incoming data is in 
> receive queue or expected to come after the close() (and this is where 
> the problem really is : depending on timing, if your app is really fast, 
> it could close the socket before the 'extra data' really hit you), 
> so the answer (RST or not) could depend on timing.
> 
> sending an RST if data is in receive queue is just to respect 
> RFC spirit : notity the other peer that data was lost.

That all seems OK to me .. but the problem is losing
data in the transmit queue, not the receive queue.



-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-
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