select on listen socket always succeeds - Unix

This is a discussion on select on listen socket always succeeds - Unix ; I'm doing some experimental work on linux (x86, 2.6 kernel) with a tcp server. What I have is a typical select() call which is suppose to tell me when a socket is readble. This must happen for both listen socket ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: select on listen socket always succeeds

  1. select on listen socket always succeeds

    I'm doing some experimental work on linux (x86, 2.6 kernel) with a tcp
    server. What I have is a typical select() call which is suppose to
    tell me when a socket is readble. This must happen for both listen
    socket to accept new connections and the normal sockets.
    All of the connections including the listen socket are set non-
    blocking and furthermore socket re-use flag is specified for the
    listen socket.
    However I experience that with the listen socket it ALWAYS returns as
    readable regardless of if any clients are connecting or not.
    I'm using both ipv4 and ipv6 on each their socket and what I see is
    that the ipv4 socket always returns as readable.

    What am I missing here? The linux man page for accept says something
    else.
    I should note that this code is ported from Windows where it worked
    perfectly fine without any changes.

    I've ensured that highest socket number + 1 is passed to select.
    Before this it wouldn't even return at all.

    Has anyone seen this before?

    Thanks.

    -- Henrik


  2. Re: select on listen socket always succeeds

    hg@x-formation.com wrote:
    > I'm doing some experimental work on linux (x86, 2.6 kernel) with a


    There have been 23 versions of the 2.6 kernel thusfar, so it would be
    good to state which specific one you are using. The output of uname
    -a would suffice for that purpose.

    > tcp server. What I have is a typical select() call which is suppose
    > to tell me when a socket is readble. This must happen for both
    > listen socket to accept new connections and the normal sockets. All
    > of the connections including the listen socket are set non- blocking
    > and furthermore socket re-use flag is specified for the listen
    > socket.


    I presume you mean SO_REUSEADDR, which will allow a socket to be bound
    to port numbers for which there are already TCP endpoints in states
    other than LISTEN. That is not the same thing as socket reuse, which
    if it were present under linux would be the actual reuse of socket
    datastructures, probably not unlike the TCP connection caching of
    HP-UX 11 and perhaps other platforms. (Which in and of itself is
    somewhat poorly named since it isn't the "connection" cached as much
    as the stack of Streams modules which carry the state of a
    connection).

    > However I experience that with the listen socket it ALWAYS returns as
    > readable regardless of if any clients are connecting or not.
    > I'm using both ipv4 and ipv6 on each their socket and what I see is
    > that the ipv4 socket always returns as readable.


    > What am I missing here? The linux man page for accept says something
    > else.
    > I should note that this code is ported from Windows where it worked
    > perfectly fine without any changes.


    In the land of Unix/Linux, something working under Windows is rarely a
    ringing endorsement

    > I've ensured that highest socket number + 1 is passed to select.
    > Before this it wouldn't even return at all.


    Start taking strace traces of your application and that will likely
    help you determine what is going-on. It will help make certain that
    your select() calls are being given what you think they are being
    given and show you what they are returning.

    rick jones
    --
    firebug n, the idiot who tosses a lit cigarette out his car window
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  3. Re: select on listen socket always succeeds

    wrote in message
    news:1193138692.400978.118760@y27g2000pre.googlegr oups.com...
    > I'm doing some experimental work on linux (x86, 2.6 kernel) with a tcp
    > server. What I have is a typical select() call which is suppose to
    > tell me when a socket is readble. This must happen for both listen
    > socket to accept new connections and the normal sockets.
    > All of the connections including the listen socket are set non-
    > blocking and furthermore socket re-use flag is specified for the
    > listen socket.
    > However I experience that with the listen socket it ALWAYS returns as
    > readable regardless of if any clients are connecting or not.
    > I'm using both ipv4 and ipv6 on each their socket and what I see is
    > that the ipv4 socket always returns as readable.


    What happens when you call accept()?

    Can you reproduce the problem in something small enough to post?

    Alex



  4. Re: select on listen socket always succeeds

    >
    > What happens when you call accept()?


    accept() works as it's suppose to. In non-blocking mode I get EWOULDBLOCK
    and in blocking mode it just hangs.
    So it seems that select is posting wrong information.

    Obviously I must be doing something wrong but it seems so simple since it is
    done right after the book.

    > Can you reproduce the problem in something small enough to post?
    >


    I'll give that a try and get back. Obviously it's not so easy as there is a
    lot of setup code involved.

    I would equally like to see some example code on select/accept which I could
    use to double-check with.
    Except for this wrong accept socket everything works fine with this select
    implementation.

    -- Henrik



  5. Re: select on listen socket always succeeds

    Henrik Goldman wrote:
    > I would equally like to see some example code on select/accept which I could
    > use to double-check with.
    > Except for this wrong accept socket everything works fine with this select
    > implementation.


    You mean something like http://beej.us/guide/bgnet/examples/selectserver.c?

  6. Re: select on listen socket always succeeds

    The problem has now been solved.

    The application has a dual-stack implementation as described in:
    http://www.ietf.org/rfc/rfc4038.txt

    However when ipv6 sockets are NOT forced to only accept ipv6
    connections then select will fail by making ipv4 socket ready always.
    So it seems like it's a bug in the underlying system.

    As soon as I removed the ipv6 socket it started to work.

    Now I fixed it by using:

    setsockopt(sockfd[nsock], IPPROTO_IPV6, IPV6_V6ONLY,
    (char *)&on, sizeof(on));

    as mentioned in the rfc.

    I didn't expect that it would work this way though. Even if I I
    wouldn't specify the above flag select shouldn't behave like it does.

    -- Henrik


  7. Re: select on listen socket always succeeds

    hg@x-formation.com writes:
    > The problem has now been solved.
    > The application has a dual-stack implementation as described in:
    > http://www.ietf.org/rfc/rfc4038.txt
    >
    > However when ipv6 sockets are NOT forced to only accept ipv6
    > connections then select will fail by making ipv4 socket ready always.
    > So it seems like it's a bug in the underlying system.


    This is 'a bug' in the system configuration. Unless the machine is on
    an IPv6 network, which it most certainly isn't, it shouldn't pretend
    to be. Instead of hacking around inappropriate setting forced onto you
    for entirely "political" reasons, request that they are changed.

    Yes, I know this is a hopeless quest. Nothing can force a computer
    scientist to deal with reality if it doesn't want to.


+ Reply to Thread