How to know if remote machine is down in TCP - TCP-IP

This is a discussion on How to know if remote machine is down in TCP - TCP-IP ; Hello , I want to get noticed at TCP when my remote machine is umplugged . There are 2 options available : 1.Heartbeat : both ends send a null request after some time and this resets a timer , if ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: How to know if remote machine is down in TCP

  1. How to know if remote machine is down in TCP

    Hello ,

    I want to get noticed at TCP when my remote machine is umplugged .
    There are 2 options available :
    1.Heartbeat : both ends send a null request after some time and this
    resets a timer , if after a certain time i dont get heartbeat i'll
    assume my remote machine is not availble .
    2. SO_KEEPALIVE option. ( I need to reduce keepalive value for my
    Linux system. )

    As the server / client logic is very complex i dont want to make a big
    change in that so i am planning to go for the #2 option
    (SO_KEEPALIVE) , please comment .

    Regards,
    Lokesh.


  2. Re: How to know if remote machine is down in TCP

    Lokesh Ranadive writes:
    > I want to get noticed at TCP when my remote machine is umplugged .
    > There are 2 options available :
    > 1.Heartbeat : both ends send a null request after some time and this
    > resets a timer , if after a certain time i dont get heartbeat i'll
    > assume my remote machine is not availble .
    > 2. SO_KEEPALIVE option. ( I need to reduce keepalive value for my
    > Linux system. )
    >
    > As the server / client logic is very complex i dont want to make a big
    > change in that so i am planning to go for the #2 option
    > (SO_KEEPALIVE) , please comment .


    I would go for #1. It's much easier to deal with over time and over
    change.

    In other words, when your users demand that certain TCP links be
    subject to different timeout rules, or you discover that you need to
    work on make-before-break failover or path-protection mechanisms, or
    when you find you want to port your application to some other system,
    you'll be in a much better place if you have a simple application-
    layer mechanism rather than reliance on TCP keepalive tweaking.

    The problems include:

    - How TCP keepalive operates varies from system to system. It's all
    too easy to get trapped by underlying OS assumptions.

    - The point of TCP keepalive isn't to protect your application.
    Instead, it's to protect the OS against stale connections that
    just linger "forever." It prevents a sort of long-term storage
    leak.

    - The behavior of TCP keepalive, when it works, is completely opaque
    to the application. If you ever need to expose status information
    either to a user or to some sort of monitoring application, then
    you'll be stuck.

    I think you're about to step into a trap ... one that's caught quite a
    few people before you.

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: How to know if remote machine is down in TCP

    On 31 May 2007, James Carlson wrote:

    > Lokesh Ranadive writes:
    >> I want to get noticed at TCP when my remote machine is umplugged
    >> . There are 2 options available :
    >> 1.Heartbeat : both ends send a null request after some time and
    >> this resets a timer , if after a certain time i dont get
    >> heartbeat i'll assume my remote machine is not availble .
    >> 2. SO_KEEPALIVE option. ( I need to reduce keepalive value for my
    >> Linux system. )
    >>
    >> As the server / client logic is very complex i dont want to make
    >> a big change in that so i am planning to go for the #2 option
    >> (SO_KEEPALIVE) , please comment .

    >
    > I would go for #1. It's much easier to deal with over time and
    > over change.


    [good reasons snipped]

    I second the motion for #1 with the added reason that the keepalive
    timeout value is usually a single system wide setting and quite long
    (often 2 *hours*). Depending on why you want the timeout, you might
    not want to wait nearly that long. I think an application level
    heartbeat is definitely the way to go.

    Dave

    --
    D.a.v.i.d T.i.k.t.i.n
    t.i.k.t.i.n [at] a.d.v.a.n.c.e.d.r.e.l.a.y [dot] c.o.m

  4. Re: How to know if remote machine is down in TCP

    In article ,
    James Carlson wrote:

    >> 1.Heartbeat : both ends send a null request after some time and this


    >> 2. SO_KEEPALIVE option. ( I need to reduce keepalive value for my
    >> Linux system. )


    >I would go for #1. It's much easier to deal with over time and over
    >change.


    >The problems include:
    >
    > - How TCP keepalive operates varies from system to system. It's all


    > - The point of TCP keepalive isn't to protect your application.


    > - The behavior of TCP keepalive, when it works, is completely opaque


    also

    - in some systems, changes to the SO_KEEPALIVE duration affect
    all TCP connections. What happens if various applications on the
    system have differing needs for the keepalive value? Would you
    be happy with change the keepalive timer from 2 or 3 hours to 5
    minutes for your application and so setting it to the 5 minutes
    for all other applications?

    >I think you're about to step into a trap ... one that's caught quite a
    >few people before you.


    yes.


    Vernon Schryver vjs@rhyolite.com

  5. Re: How to know if remote machine is down in TCP

    Lokesh Ranadive writes:

    > Hello ,
    >
    > I want to get noticed at TCP when my remote machine is umplugged .
    > There are 2 options available :
    > 1.Heartbeat : both ends send a null request after some time and this
    > resets a timer , if after a certain time i dont get heartbeat i'll
    > assume my remote machine is not availble .
    > 2. SO_KEEPALIVE option. ( I need to reduce keepalive value for my
    > Linux system. )
    >
    > As the server / client logic is very complex i dont want to make a big
    > change in that so i am planning to go for the #2 option
    > (SO_KEEPALIVE) , please comment .


    Hopefully you've already been convinced, but in case, here are a
    couple of other observations:

    First, KEEPALIVE insures that the TCP connection is OK, but it won't
    tell you if your application has hung. Although you say you only want
    to know if the remote machine is unplugged, you might as well
    implement what you really want, which is the knowledge that the client
    and server can still talk to each other. Unplugging is just one of
    uncountable many failure modes, although admittedly none of them are
    anywhere as common as power failure.

    Second, you use complex server/client logic as an excuse *not* to add
    a heartbeat, but it's really an argument in favor of it. The complex
    logic suggests a solution tailored to it. Furthermore, if you already
    have complex client/server interaction, you almost certainly already
    have some kind of "message type", so it should be trivial to add a
    heartbeat message.

    -don provan

    p.s. Back in the dialup days, a lot of gateway would avoid connection
    charges by falsifying TCP keep alive responses instead of letting the
    keep alive probes keep the dialup connection up. Does anyone know if
    anything ever do this any more in the modern Internet?

  6. Re: How to know if remote machine is down in TCP

    On May 31, 10:11 pm, don provan wrote:
    > Lokesh Ranadive writes:
    > > Hello ,

    >
    > > I want to get noticed at TCP when my remote machine is umplugged .
    > > There are 2 options available :
    > > 1.Heartbeat : both ends send a null request after some time and this
    > > resets a timer , if after a certain time i dont get heartbeat i'll
    > > assume my remote machine is not availble .
    > > 2. SO_KEEPALIVE option. ( I need to reduce keepalive value for my
    > > Linux system. )

    >
    > > As the server / client logic is very complex i dont want to make a big
    > > change in that so i am planning to go for the #2 option
    > > (SO_KEEPALIVE) , please comment .

    >
    > Hopefully you've already been convinced, but in case, here are a
    > couple of other observations:
    >
    > First, KEEPALIVE insures that the TCP connection is OK, but it won't
    > tell you if your application has hung. Although you say you only want
    > to know if the remote machine is unplugged, you might as well
    > implement what you really want, which is the knowledge that the client
    > and server can still talk to each other. Unplugging is just one of
    > uncountable many failure modes, although admittedly none of them are
    > anywhere as common as power failure.
    >
    > Second, you use complex server/client logic as an excuse *not* to add
    > a heartbeat, but it's really an argument in favor of it. The complex
    > logic suggests a solution tailored to it. Furthermore, if you already
    > have complex client/server interaction, you almost certainly already
    > have some kind of "message type", so it should be trivial to add a
    > heartbeat message.
    >
    > -don provan
    >
    > p.s. Back in the dialup days, a lot of gateway would avoid connection
    > charges by falsifying TCP keep alive responses instead of letting the
    > keep alive probes keep the dialup connection up. Does anyone know if
    > anything ever do this any more in the modern Internet?


    Thanks a lot for all the replies . i think Heartbeat is no doubt
    better than changing keep alive . Thanks a gain for all the help
    Lokesh .


+ Reply to Thread