On Thu, 05 Jul 2007 01:09:54 +1000 skaller <skaller@xxxxxxxxxxxxxxxxxxxxx> wrote: > 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. RST is full-duplex, and forbids further data transmit. If you receive data after a socket was closed(), *then* you SHOULD lose data in transmit queue, since the stack "SHOULD send a RST to show that data was lost". - 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
