Subject | Re: [IB-Architect] Interbase connection limit and Support related Problems |
---|---|
Author | Jim Starkey |
Post date | 2000-07-06T13:49:42Z |
At 05:54 PM 7/6/00 +1000, you wrote:
with read/write, only socket specific send/recv (this from personal
experience). Unlike Unix fds, they are allocated sequentially.
Also, on NT, the fd_set data structure is an array of handles
which is searched, while on Unix it is a dense bit vector directly
accessed.
But there are implementation details. The important point is that
NT, unlike Solaris, does not have an API induced limit on the number
of sockets supported. This is not to say that are not limits, but
they are internal to NT and hence can be stretched by the whim of
Brother Bill.
Jim Starkey
>I wrote:Sockets are indeed handles, no question. But they don't work
>>This typically not true. If the stack provides IFS handles, they are
>>allocated out of the same namespace as file handles and can be used in the
>>standard Win32 functions, like ReadFile(), WriteFile(), etc. The Microsoft
>>TCP/IP stack generates IFS handles, although third party TCP/IP stacks
>might
>>not.
>
>Let me get this right.
>
>Even stacks which do not generate IFS handles have their handles allocated
>out of the same namespace as Win32 handles, and must do so to avoid clashes.
>There were issues with NT prior to SP4 with the use of handles from non-IFS
>providers in native Win32 calls (like ReadFile/WriteFile), but they were not
>handle namespace issues.
>
with read/write, only socket specific send/recv (this from personal
experience). Unlike Unix fds, they are allocated sequentially.
Also, on NT, the fd_set data structure is an array of handles
which is searched, while on Unix it is a dense bit vector directly
accessed.
But there are implementation details. The important point is that
NT, unlike Solaris, does not have an API induced limit on the number
of sockets supported. This is not to say that are not limits, but
they are internal to NT and hence can be stretched by the whim of
Brother Bill.
Jim Starkey