On 10/25/22 19:04, Zebediah Figura (@zfigura) wrote:
Of course, there's a good reason for TIME_WAIT existing, but, well, Windows :-/
Do you know which is the reason it exists on Linux on the listening port with the same timeout value (it is clear why it is on accepted socket / port)? I could not deduce that from specs. The only mention of that I know about is BSD _REUSEADDR manual page which suggests that some implied timeout might be there, and that the Linux kernel keeps listen port busy for the same time as accept port and not going to change that. I am not entirely sure that Windows is violating any specific TCP rule by relaxing the timeout on listening port.
Should we add tests for the TIME_WAIT part as well?
I don't know how to do that 100% reliably for a non-flaky test, the way I use locally is creating child processes which connect to each other and killing them. But that results in different TCP connection states on ports and sometimes (rarely) they may get lucky and not hit the longest timeout. Should I maybe attach a local program which reproduces that?