RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v2]

Mark Sheppard msheppar at openjdk.org
Wed Jun 11 12:17:30 UTC 2025


On Wed, 11 Jun 2025 11:47:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> FWIW:
>> Stating a typical value of 60 seconds timeout can lead to a misconception or set an expectation ... From from TCP standards and depending on which literature you read (OS docs or unix networking socket programming) then 75 secs should be a more typical default 
>> 
>> I think the 60 seconds comes from a perceived setting on linux. For example if a linux config of
>> net.ipv4.tcp_syn_retries = 6 is set and the RTO == 1 sec, with a backoff policy of doubling the timeout each retry, then the connect timeout would expect to be 63 secs
>> 
>> It would be better to say that, the value is OS dependent, influenced by OS network setting relating to syn receive timeouts and the number of syn retries, and governed by the TCP retransmission timer implementation, rather than stating a particular value.
>
> Hello Mark,
> Alan's thought was that it might be OK to have that sentence about the typical 60 second timeout. The primary guidance to developers here is that "The {@code timeout} specified to this method is typically a timeout value that is shorter than the operating system timeout." so that they set a lower value when appropriate.
> 
> Alan @AlanBateman, do you suggest we continue with this text or would any update be necessary?

I think it is an unnecessary quantification, is somewhat inaccurate, and set an expectation of a developer that this is gospel or axiomatic. Indicating that  it is OS dependent should be sufficient.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2139979786


More information about the net-dev mailing list