Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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?
                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, 2009 at 20:31
                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, 2009 at 22:28
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.
                How is the time between each retry set? It seems to increase exponentially with each retry. Where is this set?
– Kevin
                Jun 25, 2009 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, 2009 at 21:31
                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 1, 2009 at 5: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 2, 2009 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  stackoverflow.com/questions/47861767/…
– Parul Chauhan
                Dec 18, 2017 at 5:40
                I think SO_TIMEOUT applies to read but not connect, so that might be why.  I can't seem to find verification of this at the moment though.
– Samuel Edwin Ward
                Dec 1, 2011 at 16:18
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.
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.
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.