Created attachment 160881 [details] test for catch infinite freezing (on TCP-sockets by default) on GNU/Linux good day! please, very sorry me for your time. :-) [and sorry for my bad english]. big problem in that fact: *most* application-programmers think that if TCP-connection is already *broken* -- that timeout of TCP-socket will *NOT* be *infinite*. (default system timeout). I prepared example code: https://gist.github.com/polymorphm/0e057402c9fa82547d72 (and this file "to-test.c" -- in attachment). this example code ("to-test.c") -- shows that if TCP-connection *broken* -- that timeout will *never* be reached (for broken TCP-connection. EVEN AFTER SOME DAYS). program "to-test.c" -- becomes to infinite freezing -- after "[step 8]": $ gcc -Wall -Werror -o to-test to-test.c && sudo ./to-test ***** begin of test ***** [step 1] creating socket... ***** INFO: is used SO_KEEPALIVE by default for TCP-sockets? answer: 0 ***** [step 2] connecting socket... [step 3] time waiting (1s)... [step 4] breaking down network... [wlp1s0] # ip link set down dev wlp1s0 [step 5] time waiting (15s)... [step 6] reestablishing up network... [wlp1s0] # ip link set up dev wlp1s0 [step 7] time waiting (1s)... [step 8] waiting of socket timeout (or we are freezed *infinity*?)... (infinite freeze -- at this point) probably, this issue-ticket will be marked as WONTFIX (and again: very sorry me for your time!). but this issue-ticket -- need at least for official canonical URL-link for answer to problem of default timeout of *broken* TCP-connection on GNU/Linux. when I speek with some application-programmers -- they say me: if GNU/Linux freeze at broken-TCP-connections (with default settings of socket) than is *bug* of GNU/Linux. and I maked this issue-ticket. sorry.
TCP connection time is independent of link state, this is how BSD sockets work, the IP layer is independent of underlying link. The protocols are designed to retry. The default timeout for a TCP connection is determined by the number of retries and the retry timeout. This number of retries is controlled by the sysctl documented in kernel (Documentation/networking/ip-sysctl.txt) tcp_syn_retries - INTEGER Number of times initial SYNs for an active TCP connection attempt will be retransmitted. Should not be higher than 255. Default value is 6, which corresponds to 63seconds till the last retransmission with the current initial RTO of 1second. With this the final timeout for an active TCP connection attempt will happen after 127seconds.
> TCP connection time is independent of link state, this is how BSD sockets > work, the IP layer is independent of underlying link. The protocols are > designed to retry. yes, in my example ( https://gist.github.com/polymorphm/0e057402c9fa82547d72 ) -- we made some DOWN-and-UP of iface link-layer at localhost. but if we will breaking link on *router-cumputer* (not breaking link on localhost) -- than we will get same issue on localhost: infinite freeze after "[step 8]". and on router-computer: we may using (for example) iptables for temporary breaking TCP-socket-states (not necessarily physical link iface down\up): iptables -w -P FORWARD DROP; ip6tables -w -P FORWARD DROP sleep "${some_seconds_for_breaking_TCP_sessions}" iptables -w -P FORWARD ACCEPT; ip6tables -w -P FORWARD ACCEPT sorry, I can not write *fully-automated* example-code, that parallelly-manipulating actions on localhost and actions on router-computer. :-) > tcp_syn_retries ... if TCP-socket yet already transmitted all own data (successfully transmitted) and local-peer now only waiting data (or disconnection) from remote-peer... at this TCP-socket-state -- parameter "tcp_syn_retries" -- does not affect to this waiting. if (at this TCP-socket-state) TCP-session would be broken -- than on local-peer timeout never reached.