Red Hat Bugzilla – Bug 209981
select() doesn't work with multicast UDP
Last modified: 2007-11-30 17:11:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
Description of problem:
select() doesn't seem to work properly multicast. mcasttest.cpp illustrates the problem. cleansockets.h allows the code to be compiled on windows; it's just standard headers on linux.
FD_ISSET not set
This shows that select() is not detecting that the socket has recieved data, but it obviously has recieved data because recvfrom() returns packets.
Strangely the code works when compiled on windows and run under WINE!
This would imply the WINE people know about this problem and worked around it. I've played with this for a while removing a few sockopts here and there, but for naught.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
gcc -o mcasttest -lstdc++ mcasttest.cpp
2) send data:
3) recieve (on another shell):
FD_ISSET not set
I've done an automatic update a few days ago. I'm running:
[root@ares mcasttest]# rpm -q kernel
Fedora Core release 5 (Bordeaux)
Created attachment 138039 [details]
main code - illustrates the bug
Sorry for forgetting to attach this right away!
Created attachment 138040 [details]
Just standard headers on Linux, does windows compatiblity
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed. See bug 207474 for further details.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.
Nope, it's still broken. I recompiled it and it does the same thing. select()
returns nothing even thought the socket has data.
Your application is buggy.
The first select argument should be "socketId + 1". Make that change
and it will work properly, I just verified that here.
If you copied the select() call from the Linux man page, you should
note that the example given in the manpage is select()'ing on file
descriptor "0", standard input, and therefore the first argument to
select should be "0 + 1".
Finally, you didn't provide the cleansockets.h header file, so I
had to spend the time to put one together. Providing self-contained
test cases makes your problem get looked at faster, just a note for
Ok, my bad!!! I should have read the MAN page. I thought it was the number of
sockets. On windows it's ignored. Theoretically select() can always calculate
that parameter from the others, so debatebly it's a useless parameter. Maybe
there's some speed benefit.
Anyway thanks. Sorry. I hope my company will give you money. We've bought Red
Hat licenses in the past and the customer(ING bank) we're doing this for may
also give you something.
Just for the record that header file "cleansockets.h" was attached in the 2nd
comment. Sorry I didn't attach it immediately.
The first argument to select() provides two things:
1) An optimization, which you noticed, which reduces the amount of the
fd bitmaps which the select() implementation has to scan.
2) An upgrade path for increasing the size of fd_set transparently. The
kernel doesn't actually care how big these bitmaps are, all it would
see is a larger first argument if "fd_set" were made larger in userspace
and the application made use of that larger area.