[KLUG Programming] tcp connection is alive

[Dirk H Bartley]

Hey gang

Just thought someone may be interested in the net results here.

SO_KEEPALIVE being a system wide thing just does not seem to be the
solution in this case because I need for a specific connection at about
30 sec to 5 minutes.,  I decided to use ICMP in the perl script.  Every
once in a while, perl supprises me.  It has exactly what will do the
trick with use Net::Ping;

The disadvantage here is that with what I have done it is based on an
assumtion that if the tcp connection goes down it is because the host
goes down and that the host went down for at least 5 seconds as oppesed
to is the connection dead or alive which would be preferable.

Dirk

On Mon, 2003-11-03 at 10:22, Adam Tauno Williams wrote:
> > I'm using netcat in a perl script with an open2 function call.  All is
> > working very well with netcat as long as connections are properly
> > completed.  All connections were properly completed until I started
> > using a 3com ethernet client bridge and the machine the bridge is
> > connected to is turned off.  (the whole fin ack connection completion
> > thing)
> 
> So don't turn it off! :)
> 
> > So here is my question.  I would like the vocabulary to start searching
> > for how I can modify netcat to perform a syn/ack or some type of
> > checking to see if the host at the other end is alive and answering. 
> > Then if the connection is not alive, I want netcat to close.
> 
> You want to enable some type of "keepalive".  TCP support this.
> http://www.itprc.com/tcpipfaq/faq-2.htm#crash-detection
> 
> Here is an interesting chunk from a text file I have -
> 
>   2.8.  Why does it take so long to detect that the peer died?
> 
>   From Andrew Gierth (andrew@erlenstar.demon.co.uk):
> 
>   Because by default, no packets are sent on the TCP connection unless
>   there is data to send or acknowledge.
> 
>   So, if you are simply waiting for data from the peer, there is no way
>   to tell if the peer has silently gone away, or just isn't ready to
>   send any more data yet. This can be a problem (especially if the peer
>   is a PC, and the user just hits the Big Switch...).
> 
>   One solution is to use the SO_KEEPALIVE option. This option enables
>   periodic probing of the connection to ensure that the peer is still
>   present.  BE WARNED: the default timeout for this option is AT LEAST 2
>   HOURS.  This timeout can often be altered (in a system-dependent
>   fashion) but not normally on a per-connection basis (AFAIK).
> 
>   RFC1122 specifies that this timeout (if it exists) must be
>   configurable.  On the majority of Unix variants, this configuration
>   may only be done globally, affecting all TCP connections which have
>   keepalive enabled. The method of changing the value, moreover, is
>   often difficult and/or poorly documented, and in any case is different
>   for just about every version in existence.
> 
>   If you must change the value, look for something resembling
>   tcp_keepidle in your kernel configuration or network options
>   configuration.
> 
>   If you're sending to the peer, though, you have some better
>   guarantees; since sending data implies receiving ACKs from the peer,
>   then you will know after the retransmit timeout whether the peer is
>   still alive. But the retransmit timeout is designed to allow for
>   various contingencies, with the intention that TCP connections are not
>   dropped simply as a result of minor network upsets. So you should
>   still expect a delay of several minutes before getting notification of
>   the failure.
> 
>   The approach taken by most application protocols currently in use on
>   the Internet (e.g. FTP, SMTP etc.) is to implement read timeouts on
>   the server end; the server simply gives up on the client if no
>   requests are received in a given time period (often of the order of 15
>   minutes). Protocols where the connection is maintained even if idle
>   for long periods have two choices:
> 
>   1. use SO_KEEPALIVE
> 
>   2. use a higher-level keepalive mechanism (such as sending a null
>      request to the server every so often).
> 
>   2.9.  What are the pros/cons of select(), non-blocking I/O and SIGIO?
> 
>   Using non-blocking I/O means that you have to poll sockets to see if
>   there is data to be read from them.  Polling should usually be avoided
>   since it uses more CPU time than other techniques.
> 
>   Using SIGIO allows your application to do what it does and have the
>   operating system tell it (with a signal) that there is data waiting
>   for it on a socket.  The only drawback to this soltion is that it can
>   be confusing, and if you are dealing with multiple sockets you will
>   have to do a select() anyway to find out which one(s) is ready to be
>   read.
> 
>   Using select() is great if your application has to accept data from
>   more than one socket at a time since it will block until any one of a
>   number of sockets is ready with data.  One other advantage to select()
>   is that you can set a time-out value after which control will be
>   returned to you whether any of the sockets have data for you or not.
> _______________________________________________
> Programming mailing list
> Programming@kalamazoolinux.org
> http://www.kalamazoolinux.org/mailman/listinfo/programming