On Tue, 17 Jun 2025 09:26:17 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>> test/jdk/java/net/ServerSocket/LargeBacklogTest.java line 96: >> >>> 94: // do not attempt any more connections >>> 95: break; >>> 96: } >> >> hmm... interesting: so we don't need to leave the socket open to increase >> the backlog. I guess the server side has to accept the socket and read the >> FIN, so the backlog won't be decremented until the socket is accepted (even >> if it's already closed on the client side). > > That's a good question. The current behaviour (on Windows and *nix) is that, > closing the Socket which initiated the connection doesn't affect the number > of connections that were put into a pending queue (backlog) on the server > side. I will need to read up a bit to see if that is specified or if it is > merely an implementation detail. > hmm... interesting: so we don't need to leave the socket open to increase the > backlog. I guess the server side has to accept the socket and read the FIN, > so the backlog won't be decremented until the socket is accepted (even if > it's already closed on the client side). I couldn't find this specified anywhere, but I went through the Linux source code. In that implementation, the backlog is used to size the accept queue. When a connection is made by a client, the count is incremented and tracked against the backlog value. When a connection is `accept()` that count is decremented. So unless the server `accept()`s a connection, the counter keeps increasing and thus hitting the backlog limit. This behaviour matches what's being done in this test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2171963956
