From: "Banerjee, Debabrata" <dbane...@akamai.com> Date: Sat, 19 May 2018 22:57:48 +0000
> It does the same thing the application would do, but with much less > overhead. The application called close() because it no longer cares > about new data, but it still expected send() prior to close() to > actually send. It's not the same. If you just sink the data in the protocol stack, the sender has no way whatsoever to know that the application did not see the data. The sender must have a way to know that the application at the other end received the data, whether they used it or not. And what breaks the ambiguity is that reset. This is critcially important. > Well if the intersection with the definition of the close() spooks > you something similar could be implemented as a > setsockopt(TCP_SINK_DATA) around shutdown(), to instruct the socket > to immediately dump data, but with higher resource usage. However as > above, I don't currently believe this patch violates the protocol. The SHOULD you quoted in RFC 1122 is explicitly listed in a another RFC as an explicitly recommended behavior. I know, because that text is what led me to implement the current behavior. Please see RFC 2525, section 2.16: Failure to send a RST after Half Duplex Close.