Looking at the windows 64 sockets allowed bug.

[James Rogers <jamesmrogers () gmail com>]

"  o Investigate increasing FD_SETSIZE on Windows to allow us to
    multiplex more sockets.  See Henri's email:
    http://seclists.org/nmap-dev/2012/q1/267 [James and Fyodor?]"

Everything I am seeing says that select() on windows can support more
than 64 sockets, as long as you

#define FD_SETSIZE 1024

before you call

#include <wsock32.h>

This site was very clear:  http://tangentsoft.net/wskfaq/advanced.html

4.9 - What are the “64 sockets” limitations?

There are two 64-socket limitations:

The Windows event mechanism (e.g. WaitForMultipleObjects()) can only
wait on 64 event objects at a time. Winsock 2 provides the
WSAEventSelect() function which lets you use Windows’ event mechanism
to wait for events on sockets. Because it uses Windows’ event
mechanism, you can only wait for events on 64 sockets at a time. If
you want to wait on more than 64 Winsock event objects at a time, you
need to use multiple threads, each waiting on no more than 64 of the
sockets.

The select() function is also limited in certain situations to waiting
on 64 sockets at a time. The FD_SETSIZE constant defined in the
Winsock header determines the size of the fd_set structures you pass
to select(). The default value is 64, but if you define this constant
to a different value before including the Winsock header, it accepts
that value instead:

        #define FD_SETSIZE 1024
        #include <wsock32.h>

The problem is that modern network stacks are complex, with many parts
coming from various sources, including third parties via things like
Layered Service Providers. When you change this constant, you’re
depending on all these components to play by the new rules. They’re
supposed to, but not all do. The typical symptom is that they ignore
sockets beyond the 64th in larger fd_set structures. You can get
around this limitation with threads, just as in the event object case.

--

I believe this is saying that someone could install 3rd party
utilities to their network stack that break support of more than 64
sockets at a time.
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/