| Author |
select on listen socket always succeeds
|
|
| hg@x-formation.com 2007-10-23, 8:07 am |
| 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
| |
| Alex Fraser 2007-10-23, 7:18 pm |
| <hg@x-formation.com> wrote in message
news:1193138692.400978.118760@y27g2000pre.googlegroups.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
| |
| Henrik Goldman 2007-10-23, 7:18 pm |
| >
> 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
| |
| Henry Townsend 2007-10-23, 7:18 pm |
| 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?
| |
| hg@x-formation.com 2007-10-24, 8:08 am |
| 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
| |
| Rainer Weikusat 2007-10-24, 8:08 am |
| 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.
| |
| Rick Jones 2007-10-29, 7:09 pm |
| 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...
|
|
|
|