The good news is that the NT connection limit is non-architectural.
The bad news is that InterBase artificially limits the number of
connections. The good news is that it is trivial to fix.

>
>
>Jim Starkey wrote:
>>
>> At 09:44 PM 7/5/00 +0100, Jason Chapman wrote:
>> >What about NT?
>> >
>> >My largest customer has just blown 256!
>> >
>>
>> First, NT sockets come out of a different sequence than file ids.
>> Second, WIN32 using an int for file descriptors. This is not to
>> say that NT supports an infinite number of sockets, but it certainly
>> is NOT subject to the same soft of problems as Solaris.
>>
>> Jim Starkey
>>
>
>Jim,
>
>Here's the reasoning to problems I alluded to earlier on the list.
>Please read the <winsock.h> excerpt below.
>
>We took Microsoft's advice 5 years ago and pound defined FD_SETSIZE
>to 256 in remote/inet.c. The InterBase server traverses the port list
>and calls the FD_SET macro to prepare for the select() call. The
>macro performs the appropriate bounds checking and silently tosses
>extra ports when the array is full. So we will never listen to more
>than 256 server ports with select() even though we are happy to
>accept() them.
>
>It has nothing to do with Microsoft or the size of datatypes. We
>just haven't kept up with our customers' usage patterns.
>
>It's possible that raising the pound define of FD_SETSIZE to 1024+
>in remote/inet.c will solve the connectivity problems on Windows NT.
>It's certainly the place to start but it's premature to claim that
>it will be the panacea to all problems.
>

Jim Starkey