Find the answer to your Linux question:
Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Exclamation Detection of network cables getting unplugged

    Inherent problem with TCP/IP sockets is that any network cables unplugged along the route from one side to the other will cause a loss of connection without any notification. To address this issue at the socket level, one recommended approach is to use TCP keepalive mechanism to detect Dead Peers/Process crash/NW cable disconnect. It requires one to enable TCP/IP networking in order to use it. You also need procfs support and sysctl support to be able to configure the kernel parameters at runtime.
    In Linux system the following 3 system params needs to be overwritten with user defined values
    tcp_keepalive_time (/proc/sys/net/ipv4/tcp_keepalive_time)
    tcp_keepalive_intvl /proc/sys/net/ipv4/tcp_keepalive_intvl)
    tcp_keepalive_probes /proc/sys/net/ipv4/tcp_keepalive_probes

    With the sample prototype setting the above 3 params to 30, 10, 5 was able to detect NW disconnect in ~1.25 min (30s + 10 x 5 = 80s)

    ON Solaris platform
    To achive the same in Solaris adjusted the foll 2 params

    But results are not very satisfying, I’m not able to fine tune system parameters to have the disconnect happen after a specific time. I also noticed that Solaris does not have ‘tcp_keepalive_probes’ so how can one specify the number of re-tries before disconnecting? Basically If I need the socket disconnection to happen in about 80s/100s to what values should I set the Sol NW params?

    Thanks in Advance for your help


  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    TCP/IP is designed to handle temporary network problems like disconnected cables, etc. That is why the timeout parameters may not seem reasonable to you, but are in the context of how the system was designed/implemented. Consider that TCP/IP is intended to deal with catastrophic events, such as a nuclear attack, and still communicate after such an event... So, the system is functioning as designed.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts