Re: socket close
Date: Wed Jul 04 2007 - 11:10:01 EST
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 126.96.36.199 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