Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #1690 > unrolled thread

is SO_KEEPALIVE broken?

Back to article view | Back to comp.os.linux.networking

Contents

  is SO_KEEPALIVE broken? Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-10-06 07:18 +0200
    Re: is SO_KEEPALIVE broken? telsar <noone@nowhere.com> - 2012-10-06 13:59 -0500
      Re: is SO_KEEPALIVE broken? Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-10-07 00:12 +0200
        Re: is SO_KEEPALIVE broken? Richard Kettlewell <rjk@greenend.org.uk> - 2012-10-07 11:52 +0100
          Re: is SO_KEEPALIVE broken? Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-10-08 05:09 +0200
    Re: is SO_KEEPALIVE broken? Ian Zimmerman <itz@buug.org> - 2012-10-14 12:52 -0700
      Re: is SO_KEEPALIVE broken? Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-10-18 14:17 +0200

#1690 — is SO_KEEPALIVE broken?

Hello,
I have two programs, which communicate via a TCP socket. one client 
which sends one-byte commands and a server which interprets them. The 
server uses read() to get those bytes.

The manual page for recv says:
 > The return value will be 0 when the peer  has  performed  an
 >       orderly shutdown.
(allegedly recv and read behave roughly the same)

So, I've been using the return value to determine if the connection 
should end. Unfortunately it turns out, that in rare cases 0 is returned 
even for live connections, which will unexpectedly terminate the session!!
The connection is using the SO_KEEPALIVE TCP option, to avoid problems 
with stale connections after computer crashes. AFAIK it did not happen 
before introduction of the SO_KEEPALIVE into the program.

So, the obvious question is now: How may I reliably recognize a close on 
the other side of the connection (to avoid stale connection threads), 
while still using keepalive to catch those no-FIN situations.

regards,
JK

[toc] | [next] | [standalone]

#1691

On 10/6/2012 12:18 AM, Johann Klammer wrote:
> Hello,
> I have two programs, which communicate via a TCP socket. one client
> which sends one-byte commands and a server which interprets them. The
> server uses read() to get those bytes.
> 
> The manual page for recv says:
>> The return value will be 0 when the peer  has  performed  an
>>       orderly shutdown.
> (allegedly recv and read behave roughly the same)
> 
> So, I've been using the return value to determine if the connection
> should end. Unfortunately it turns out, that in rare cases 0 is returned
> even for live connections, which will unexpectedly terminate the session!!
> The connection is using the SO_KEEPALIVE TCP option, to avoid problems
> with stale connections after computer crashes. AFAIK it did not happen
> before introduction of the SO_KEEPALIVE into the program.
> 
> So, the obvious question is now: How may I reliably recognize a close on
> the other side of the connection (to avoid stale connection threads),
> while still using keepalive to catch those no-FIN situations.
> 
> regards,
> JK
> 
select until true on the filehandle and when there is something to recv
it would be true.

-- 
Steal a little and go to jail, steal a lot and become King.

http://twovoyagers.com/improve-usenet.org/

[toc] | [prev] | [next] | [standalone]

#1692

telsar wrote:
> select until true on the filehandle and when there is something to recv
> it would be true.
>

I have been using poll with .events=POLLIN|POLLPRI and checked for 
POLLHUP and POLLIN. I thought that I'd get at least one byte from read 
after the POLLIN showed up, but in at least one case that was not true. 
Not sure why. Tomorrow, I'll try to reproduce it.

[toc] | [prev] | [next] | [standalone]

#1693

Johann Klammer <klammerj@NOSPAM.a1.net> writes:
> telsar wrote:

>> select until true on the filehandle and when there is something to recv
>> it would be true.
>
> I have been using poll with .events=POLLIN|POLLPRI and checked for
> POLLHUP and POLLIN. I thought that I'd get at least one byte from read
> after the POLLIN showed up, but in at least one case that was not
> true. Not sure why. Tomorrow, I'll try to reproduce it.

Implementations vary wildly (and even within themselves); you need to do
the read/recv, you can’t rely on just checking POLLHUP.

http://www.greenend.org.uk/rjk/tech/poll.html collects some of the
variation.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#1699

Richard Kettlewell wrote:
> Johann Klammer<klammerj@NOSPAM.a1.net>  writes:
>> telsar wrote:
>
>>> select until true on the filehandle and when there is something to recv
>>> it would be true.
>>
>> I have been using poll with .events=POLLIN|POLLPRI and checked for
>> POLLHUP and POLLIN. I thought that I'd get at least one byte from read
>> after the POLLIN showed up, but in at least one case that was not
>> true. Not sure why. Tomorrow, I'll try to reproduce it.
Sorry, cannot seem to reproduce it. Perhaps something else is broken in 
that program...

>
> Implementations vary wildly (and even within themselves); you need to do
> the read/recv, you can’t rely on just checking POLLHUP.
>
> http://www.greenend.org.uk/rjk/tech/poll.html collects some of the
> variation.
>

Thanks, I'll read it.

[toc] | [prev] | [next] | [standalone]

#1733

The following message is a courtesy copy of an article
that has been posted to comp.os.linux.networking as well.


Johann> Hello, I have two programs, which communicate via a TCP
Johann> socket. one client which sends one-byte commands and a server
Johann> which interprets them. The server uses read() to get those
Johann> bytes.

Johann> The manual page for recv says:

>> The return value will be 0 when the peer has performed an orderly
>> shutdown.

Johann> (allegedly recv and read behave roughly the same)

Shouldn't both just block until there's something to read?  Or do you
turn on nonblocking mode?

-- 
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png
Rule 420: All persons more than eight miles high to leave the court.

[toc] | [prev] | [next] | [standalone]

#1754

Ian Zimmerman wrote:
> The following message is a courtesy copy of an article
> that has been posted to comp.os.linux.networking as well.
>
>
> Johann>  Hello, I have two programs, which communicate via a TCP
> Johann>  socket. one client which sends one-byte commands and a server
> Johann>  which interprets them. The server uses read() to get those
> Johann>  bytes.
>
> Johann>  The manual page for recv says:
>
>>> The return value will be 0 when the peer has performed an orderly
>>> shutdown.
>
> Johann>  (allegedly recv and read behave roughly the same)
>
> Shouldn't both just block until there's something to read?  Or do you
> turn on nonblocking mode?
>

Yes, unless the connection has been closed, in which case they return 
zero(at least here).

Sorry about the line noise. The bug turned out to be in the client which 
shut down unexpectedly. Had nothing to do with recv()/KEEPALIVE.

bye,
JK

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web