Throw away streams in both directions on RST packet #18
Conversation
|
This PR breaks the common case for RST packets, where an application closes a socket while data is still pending. For example, a long download where the user clicks cancel. In that case a RST is sent by the client, but as the server was streaming packets some will still be arriving after the RST. With this PR those late packets would open a new stream with a few packets that the client probably has never seen. |
|
Good point; that wouldn't happen in our use case, but I can imagine it would have unwanted results in others. What would the expected reassembly behaviour be in that case? Set a timeout instead of closing the streams so the remaining packets are delivered to accept_tcp immediately and the streams are closed a minute later? Could it happen a new connection attempt is made on the same stream key before the timeout expires? |
No description provided.