> -----Original Message-----
> From: Windows NTBugtraq Mailing List
> [mailto:NTBUGTRAQLISTSERV.NTBUGTRAQ.COM]On Behalf Of Andrew van der
> Stock

> Almost every program using MS's C Runtime library for
> select() will suffer
> from this problem.
<snip>

This problem really comes from not RTFM - The Fine Manual states:

==============
Four macros are defined in the header file WINSOCK2.H for manipulating and
checking the descriptor sets. The variable FD_SETSIZE determines the maximum
number of descriptors in a set. (The default value of FD_SETSIZE is 64,
which can be modified by defining FD_SETSIZE to another value before
including WINSOCK2.H.) Internally, socket handles in an FD_SET structure are
not represented as bit flags as in Berkeley Unix. Their data representation
is opaque. Use of these macros will maintain software portability between
different socket environments.
==============

I don't have time at the moment to go look up FD_SETSIZE on my Linux box,
but I presume that there is some maximum, and exceeding it will cause select
(or one of the FD macros) to complain.

> Look for programs that use select(), and load msvcrt.dll (or close
> relations, and/or statically link with them). The CRT has
> been known broken
> for a long time.

Um, if broken means that it said you can have a max of 64, you fed it more
than 64, and it complained as documented, then I would suppose it is broken.
IMHO, it seems like it works as advertised.

> If you port programs from Unix-land, please do yourselves a favor, and
> change code that relies heavily on select() or poll() to use
> native winsock
> async I/O. Not only do you get far higher throughput, it's
> likely that you
> will be far more robust.

The by far most efficient way of doing a select on a Win32 system is to use
WSAEventSelect(). It's a fair bit more code, but very much worth it.
However, be warned that once you've got all those events associated with
sockets, if you want to wait on a group of them, that 64 will be a number to
work with - 64 is the maximum number of handles you can pass to
WaitForMultipleObjects(). There are various ways to work around the issue,
but that's very implementation-dependent.

As someone who has ported a fair bit of sockets code, putting big wrappers
around the parts of the app that would call select may be more trouble than
it is worth - very much depends on what the app is doing and whether the
performance gains outweigh the code churn. It is definately worth the
trouble for something like a port scanner.

David LeBlanc
dleblancmindspring.com

----------------------------------------------------------------------------
Delivery co-sponsored by Trend Micro
============================================================================
TREND MICRO REAL-TIME VIRUS ALERTS
If you would like to know about a virus outbreak before CNN and ZDNet get
Trend Micro Virus Info Feed FREE. Simply copy and paste a small piece of
code to give your visitors a real-time top 10 list and the latest virus
advisories. Setup takes just 10 minutes and requires no server-side code on
your Web site. All content is updated automatically from Trend Micro's Web
site.
http://www.antivirus.com/banners/tracking.asp?si=8&bi=237&ul=/syndication/
vinfo/
----------------------------------------------------------------------------

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]