How to determine terminated TCP connection in Linux?

On Fri, 24 Sep 2004 14:22:15 -0400, "Alexander Baranov"
<baranov@intech21.com> wrote:
>The point really is that the
>operator may be idle for hours and it is to be acceptable. Though, I haven't
>read Knuth yet :-).

For that you'll need Stevens. 8o)


-- 
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
  Per the FCA, this address may not be added to any commercial mail list

Thanks a lot to everybody! Something has become clear to me.
Alex.
"Steve Schefter" <steve_schefter@hotmail.com> wrote in message
news:cc448f8b.0409241102.d64c90b@posting.google.com...
> Hi Alexander.
>
> "Alexander Baranov" <baranov@intech21.com> wrote
> > I made a Linux TCP server for control applications. When some TCP client
> > connects to it, goes into infinite console loop, getting characters,
echoing
> > them to client, parsing commands etc. Everything  is OK until the client
> > unexpectedly terminates the connection. I have to detect this event
inside
> > the loop and break. I thought that it might be done by analyzing socket
> > state (i.e. if the state is not ESTABLISHED - break the loop) but  from
> > various examples and HOWTOs I did not see how to do it. It seems that I
have
> > to solve this problem in different way.
>
> There are two ways that the server can see that the connection has gone
> away.  First, a negative return on read() which is not EWOULDBLOCK.
Second,
> include the socket in your list of error file descriptors which you pass
> to select().  If it indicates an error, the socket is likely gone (you
might
> want to be more discriminating on errors; I'm not).
>
> The other problem is that TCP may not notice that the socket has gone away
> for quite a long time.  This is the case when you have nothing outstanding
> to be acked (by the client) when the session goes away and no attempt to
> send anything from the server until you get something from the client
> (which can no longer happen).  This is what the TCP keepalives are for.
> They are on by default in most TCP implemenations but they tend to be in
> the 2 hour range.  So a "poll" is only sent to the client every 2 hours
> and it isn't until then that you don't get a reponse and then get the
session
> failing (and the read() failing or the exception indication).  This is
fine
> for things like telnet which are using a not very scarce resource (pseudo
> ttys).  I set the timeout to about 2 minutes for connections:
>
>     on = 1;
>     setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, (char *)&on, sizeof(on));
>     value = 2 * 60;     /* every 2 minutes */
>     setsockopt(fd, SOL_TCP, TCP_KEEPIDLE, (char *)&value, sizeof(value));
>
> Here on and value are ints.
>
> As a side benefit if you are using a VPN, Cisco IOS times out idle
> sessions every hour.  If you happening to be going through a Cisco
> and using VPN, the keepalives are considered traffic enough that
> Cisco doesn't see them as idle (defeating Cisco's idle feature, but
> of more use to my application).
>
> Regards,
>       Steve
>
> ------------------------------------------------------------------------
> Steve Schefter                               phone: +1 705 725 9999 x26
> The Software Group Limited                     fax: +1 705 725 9666
> 642 Welham Road,
> Barrie, Ontario CANADA  L4N 9A1                Web: www.wanware.com