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
