4,387
社区成员
发帖
与我相关
我的任务
分享完成端口同一时间能处理的socket最大数量能大于64么？
完成端口同一时间能处理的socket最大数量能大于64么？
如果能够，是怎么处理的。
谢谢。
如果能够，是怎么处理的。
谢谢。
...全文
请发表友善的回复…
发表回复
bb123456789 2003-09-23
- 打赏
- 举报
关注！
everandforever 2003-09-23
- 打赏
- 举报
不会有 64 这个限制吧, 从没听说过.
the rest of this discussion will cover only Windows NT and its derivatives (Windows 2000, Windows XP) using the native TCP/IP stack. These systems have much higher intrinsic capabilities than the Win9x OSes. (Note that if you plan on running your program on non-Microsoft stacks, you'll need to test them yourself.)
Anecdotal evidence from the Winsock 2 mailing list puts the limit in the "thousands of connections" neighborhood, if you use overlapped I/O. (Other I/O strategies hit their own performance limits on Windows before you get to thousands of simultaneous connections.) The specific limit is dependent on how much physical memory your server has, and how busy the connections are:
The Memory Factor: According to Microsoft, the WinNT and successor kernels allocate sockets out of the non-paged memory pool. (That is, memory that cannot be swapped to the page file by the virtual memory subsystem.) The size of this pool is necessarily fixed, and is dependent on the amount of physical memory in the system. On Intel x86 machines, the non-paged memory pool stops growing at 1/8 the size of physical memory, with a hard maximum of 128 megabytes for Windows NT 4.0, and 256 megabytes for Windows 2000. Thus for NT 4, the size of the non-paged pool stops increasing once the machine has 1 GB of physical memory. On Win2K, you hit the wall at 2 GB.
The "Busy-ness" Factor: The amount of data associated with each socket varies depending on how that socket's used, but the minimum size is around 2 KB. Overlapped I/O buffers also eat into the non-paged pool, in blocks of 4 KB. (4 KB is the x86's memory management unit's page size.) Thus a simplistic application that's regularly sending and receiving on a socket will tie up at least 10 KB of non-pageable memory. Assuming that simple case of 10 KB of data per connection, the theoretical maximum number of sockets on NT 4.0 is about 12,800s, and on Win2K 25,600.
I have seen reports of a 64 MB Windows NT 4.0 machine hitting the wall at 1,500 connections, a 128 MB machine at around 4,000 connections, and a 192 MB machine maxing out at 4,700 connections. It would appear that on these machines, each connection is using between 4 KB and 6 KB. The discrepancy between these numbers and the 10 KB number above is probably due to the fact that in these servers, not all connections were sending and receiving all the time. The idle connections will only be using about 2 KB each.
So, adjusting our "average" size down to 6 KB per socket, NT 4.0 could handle about 21,800 sockets and Win2K about 43,700 sockets. The largest value I've seen reported is 16,000 sockets on Windows NT 4.0. This lower actual value is probably partially due to the fact that the entire non-paged memory pool isn't available to a single program. Other running programs (such as core OS services) will be competing with yours for space in the non-paged memory pool.
4.9 - What are the "64 sockets" limitations?
There are two limitations in Winsock where you're limited to 64 sockets.
The Win32 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 Win32's event mechanism to wait for events on sockets. Because it uses Win32's 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 winsock.h determines the size of the fd_set structures you pass to select(). It's defined by default to 64. You can define this constant to a higher value before you #include winsock.h, and this will override the default value. Unfortunately, at least one non-Microsoft Winsock stack and some Layered Service Providers assume the default of 64; they will ignore sockets beyond the 64th in larger fd_sets.
You can write a test program to try this on the systems you plan on supporting, to see if they are not limited. If they are, you can get around this with threads, just as you would with event objects.
the rest of this discussion will cover only Windows NT and its derivatives (Windows 2000, Windows XP) using the native TCP/IP stack. These systems have much higher intrinsic capabilities than the Win9x OSes. (Note that if you plan on running your program on non-Microsoft stacks, you'll need to test them yourself.)
Anecdotal evidence from the Winsock 2 mailing list puts the limit in the "thousands of connections" neighborhood, if you use overlapped I/O. (Other I/O strategies hit their own performance limits on Windows before you get to thousands of simultaneous connections.) The specific limit is dependent on how much physical memory your server has, and how busy the connections are:
The Memory Factor: According to Microsoft, the WinNT and successor kernels allocate sockets out of the non-paged memory pool. (That is, memory that cannot be swapped to the page file by the virtual memory subsystem.) The size of this pool is necessarily fixed, and is dependent on the amount of physical memory in the system. On Intel x86 machines, the non-paged memory pool stops growing at 1/8 the size of physical memory, with a hard maximum of 128 megabytes for Windows NT 4.0, and 256 megabytes for Windows 2000. Thus for NT 4, the size of the non-paged pool stops increasing once the machine has 1 GB of physical memory. On Win2K, you hit the wall at 2 GB.
The "Busy-ness" Factor: The amount of data associated with each socket varies depending on how that socket's used, but the minimum size is around 2 KB. Overlapped I/O buffers also eat into the non-paged pool, in blocks of 4 KB. (4 KB is the x86's memory management unit's page size.) Thus a simplistic application that's regularly sending and receiving on a socket will tie up at least 10 KB of non-pageable memory. Assuming that simple case of 10 KB of data per connection, the theoretical maximum number of sockets on NT 4.0 is about 12,800s, and on Win2K 25,600.
I have seen reports of a 64 MB Windows NT 4.0 machine hitting the wall at 1,500 connections, a 128 MB machine at around 4,000 connections, and a 192 MB machine maxing out at 4,700 connections. It would appear that on these machines, each connection is using between 4 KB and 6 KB. The discrepancy between these numbers and the 10 KB number above is probably due to the fact that in these servers, not all connections were sending and receiving all the time. The idle connections will only be using about 2 KB each.
So, adjusting our "average" size down to 6 KB per socket, NT 4.0 could handle about 21,800 sockets and Win2K about 43,700 sockets. The largest value I've seen reported is 16,000 sockets on Windows NT 4.0. This lower actual value is probably partially due to the fact that the entire non-paged memory pool isn't available to a single program. Other running programs (such as core OS services) will be competing with yours for space in the non-paged memory pool.
4.9 - What are the "64 sockets" limitations?
There are two limitations in Winsock where you're limited to 64 sockets.
The Win32 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 Win32's event mechanism to wait for events on sockets. Because it uses Win32's 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 winsock.h determines the size of the fd_set structures you pass to select(). It's defined by default to 64. You can define this constant to a higher value before you #include winsock.h, and this will override the default value. Unfortunately, at least one non-Microsoft Winsock stack and some Layered Service Providers assume the default of 64; they will ignore sockets beyond the 64th in larger fd_sets.
You can write a test program to try this on the systems you plan on supporting, to see if they are not limited. If they are, you can get around this with threads, just as you would with event objects.
shenfuhua 2003-09-23
- 打赏
- 举报
up!gz
Fly1980 2003-09-22
- 打赏
- 举报
能, 理论上是无限制的.(看硬件的性能,cpu越多数量越多)
