David, Thanks for responding. David S. Miller wrote: > Once you close a connection with pending receive data, TCP's reliable > data transfer attribute has been compromised so the whole connection > is reset and killed. When the app closes with unread receive data, TCP's reliable data transfer attribute has been compromised *only in the receive direction*, because the kernel has nowhere to deliver the rx data. But at that point the transmit direction is still entirely intact and there's no reason the kernel can't still deliver queued tx data. It's when Linux decides to send a RST before it has tried to do so that the tx side is corrupted, too. > This is even mentioned specifically in the RFC on known TCP > implementation errors (most stacks don't reset properly in this > case, Linux does). Yes, rfc2525 (Known TCP Implementation Problems) says that when the app closes with unread receive data then you must send a RST. But it doesn't say you have to process the CLOSE immediately. And rfc793 (TCP) says you *shouldn't* process the CLOSE until all preceding SENDs have been dealt with. I'm proposing that when the app calls close(), Linux should wait until the tx data is cleared out by normal means, as rfc793 suggests, and only then do the things it does in tcp_close (flush the rx queue and send either a FIN or a RST). Jim - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
