11

When creating a Socket in Java:

new Socket(host, port);

The Socket constructor will try to connect to host:port before returning. On Windows, this fails almost immediately for unreachable hosts but for Linux it can take up to 5 minutes for the Socket to timeout.

I'm aware that if I have control over creating the Sockets, I can do:

Socket s = new Socket();
s.bind(..);
s.connect(.., timeout);

but I'd rather have the OS use a reasonable default value. Is there a way to change this setting on Linux?

Chenmunka
  • 685
  • 4
  • 21
  • 25
Kevin
  • 30,111
  • 9
  • 76
  • 83
  • I think it's better to configure this timeout in an each application basis. Otherwise, all other applications that runs in this machine will be affected by this setting. – Reginaldo Jun 25 '09 at 20:31
  • 1
    Agreed, I'd still like know what the setting is should I wish to change it. – Kevin Jun 25 '09 at 20:39
  • 1
    If you insist on changing the OS settings then I think this is not a programming related question any more and belongs to Server Fault. – akarnokd Jun 25 '09 at 22:28

4 Answers4

14

I think you want /proc/sys/net/ipv4/tcp_syn_retries. The default is usually 5 or 6 which comes out to around 3 minutes.

Note that these are system-wide.

Vishesh Handa
  • 1,830
  • 2
  • 14
  • 17
Duck
  • 26,924
  • 5
  • 64
  • 92
  • How is the time between each retry set? It seems to increase exponentially with each retry. Where is this set? – Kevin Jun 25 '09 at 21:00
  • The intervals do increase, at least up to a point. My memory is failing me here. I don't remember if that is BSD thing or TCP and I am not sure if Linux gives you a way to control it. – Duck Jun 25 '09 at 21:31
  • 6
    The intervals are controlled by values called rtoMin,rtoMax and rtoInitial where rto stands for Round Trip Timeout. Basically, it denotes the time it would take for a packet to do a round trip. So, if when TCP sends the first msg, it would wait for rtoInitial time. If it fails to get a response, it will double the rto (and add some jitter value) and then try again. This will continue till maxRetries. The current rto value will never go past rtoMax. – Aditya Sehgal Jul 01 '09 at 05:25
  • @Aditya Thanks for the clarification. I couldn't remember if the TCP algorithms came into play during the connect phase or if the OS was setting arbitrary timers. – Duck Jul 02 '09 at 18:35
  • @Duck i've set my connection timeout and read timeout at application level for my SOAP client. this works on windows however the timeout value is not working on linux. Can you please help me with this https://stackoverflow.com/questions/47861767/http-connect-timeout-and-read-timeout-for-urlstreamhandler-with-saaj-working-fo – Parul Chauhan Dec 18 '17 at 05:40
4

I would advise against changing OS settings as it might affect other applications unexpectedly. The Socket.setSoTimeout() method might help you too.

akarnokd
  • 69,132
  • 14
  • 157
  • 192
2

It is BTW not entirely correct, that Linux and Windows behave here differently. Besides the initial SYN retries (which can be configured on Linux and Windows) the neighbour state as well as other routers sending RST packets also play a role.

If a connection attempt on Windows fails immediatelly it is likely that it was eighter RSTed by a router or the neighbour was recognized as unreachable on ARP level. Try the arp -a -v command on Windows to see the unreachable hosts - which get rejected quickly.

For Linux you would use ip neigh to list the reachability state of stations on your local network.

eckes
  • 10,103
  • 1
  • 59
  • 71
0

It's my understanding that this depends on the system's TCP/IP default timeout (240 seconds by default?)... one option is to try tweaking those, however this could affect any other programs on the same machine which rely on the timeout value. In which case, it might be safer to simply lower the "timeout" value in your Java connect() call, instead.

DreadPirateShawn
  • 8,164
  • 4
  • 49
  • 71