Hi Bernd and Alan, I had initially the same question about the socket connects, especially since it works so much better on Unix’s.
The reason why Windows can’t change the implementation is app compatibility. They have implemented an ECN (Explicit Congestion Notification) related mitigation in the stack for handling RSTs sent in response to SYNs. They tried to exempt loopback from this mitigation because ECN doesn’t really apply. However, this resulted in various apps breaking, because those apps have made assumptions that loopback connect failure will actually take longer on Windows. It appears that this timeout has become an undocumented contract in various Windows apps and a change of behavior breaks multiple of them :(. The team responsible for the network stack attempted to change the default behaviour, but were unable to after receiving pushback from various app owners. I'm working on the suggested changes to the webrev. If it makes sense, I can include a comment in the code itself on the history of the timeout? Thanks! Nikola From: Alan Bateman <alan.bate...@oracle.com> Sent: July 16, 2020 2:59 AM To: Bernd Eckenfels <e...@zusammenkunft.net>; net-dev@openjdk.java.net; Nikola Grcevski <nikola.grcev...@microsoft.com> Subject: Re: RFR(s): Improving performance of Windows socket connect on the loopback adapter On 16/07/2020 05:37, Bernd Eckenfels wrote: Hello Nikola, Can you explain why timeouts play a role here at all? Normally when connecting to a non existing socket it should immediately respond with a TCP RST and that should not cause a retry or delay. Nikola mentioned that he is in contact with someone working on Windows networking and it would be useful to know why this isn't changed in Windows and it would avoid a workaround in the JDK or anywhere else that attempt to establish a connection to the loopback. We initially started to see issues on Windows 10, Michael has more on this in JDK-8234823 [1]. I should say that I have no objection to Nikola's proposal, I think it's great to know that there is an ioctl to change this. I suspect we might have to do the equivalent in the JDWP socket transport although probably low priority as the shared memory transport is the default there. -Alan [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8234823&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cdc732e9b27df4c8d6a6c08d829560ced%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304796845600565&sdata=QemEEB2koJBLaeOtPZqJDzOmhsz7GV2CYqzOG6sEqVc%3D&reserved=0
