18,356
社区成员
发帖
与我相关
我的任务
分享完成端口同一时间能处理的socket最大数量能大于64么？
完成端口同一时间能处理的socket最大数量能大于64么？
如果能够，是怎么处理的。
谢谢。
如果能够，是怎么处理的。
谢谢。
...全文
请发表友善的回复…
发表回复
fanfyj 2003-09-23
- 打赏
- 举报
关注!
bingkuijia 2003-09-23
- 打赏
- 举报
当然可以！请教那些做过FTP服务器编程的人！
UP
UP
LuckFox 2003-09-23
- 打赏
- 举报
不明白，帮你UP！
lostgdi731 2003-09-23
- 打赏
- 举报
to bulesnow(benben)
谢谢了。
谢谢了。
bb123456789 2003-09-23
- 打赏
- 举报
关注，帮你顶！
ZHENG017 2003-09-23
- 打赏
- 举报
不好意思。昨晚发现是自己在closesocket时使用的vector::iterator中erase出错。导致错误。嘿嘿，现在是2000个线程各自发送100包数据，io server写2000*100次局域网数据库sql server 。大约每包数据花费时间是7.315ms.比delphi的bde强多了。而且我的io server只开了2个work thread.cpu利用率大概也在60%左右。测试程序也在本机。
如果是使用select模型来做，的确有64的限制，需要#define FD_SETSIZE 200
谢谢楼上各位兄弟。马上结。
如果是使用select模型来做，的确有64的限制，需要#define FD_SETSIZE 200
谢谢楼上各位兄弟。马上结。
ZHENG017 2003-09-23
- 打赏
- 举报
不好意思。昨晚发现是自己在closesocket时使用的vector::iterator中erase出错。导致错误。嘿嘿，现在是2000个线程各自发送100包数据，io server写2000*100次局域网数据库sql server 。大约每包数据花费时间是7.315ms.比delphi的bde强多了。而且我的io server只开了2个work thread.cpu利用率大概也在60%左右。测试程序也在本机。
如果是使用select模型来做，的确有64的限制，需要#define FD_SETSIZE 200
谢谢楼上各位兄弟。马上结。
如果是使用select模型来做，的确有64的限制，需要#define FD_SETSIZE 200
谢谢楼上各位兄弟。马上结。
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.
sevencat 2003-09-23
- 打赏
- 举报
自己改FD_SETSIZE 大小吧。
一般也是这么用的，下面这个文章也是这么说的，是链接期决定的
Maximum number of sockets supported
The maximum number of sockets supported by a particular Windows Sockets supplier is implementation specific. An application should make no assumptions about the availability of a certain number of sockets. This topic is addressed further in section 4.3.15, WSAStartup(). However, independent of the number of sockets supported by a particular implementation is the issue of the maximum number of sockets which an application can actually make use of.
The maximum number of sockets which a Windows Sockets application can make use of is determined at compile time by the manifest constant FD_SETSIZE. This value is used in constructing the fd_set structures used in select() (see section 4.1.18). The default value in winsock.h is 64. If an application is designed to be capable of working with more than 64 sockets, the implementor should define the manifest FD_SETSIZE in every source file before including winsock.h. One way of doing this may be to include the definition within the compiler options in the makefile, for example adding -DFD_SETSIZE=128 as an option to the compiler command line for Microsoft C. It must be emphasized that defining FD_SETSIZE as a particular value has no effect on the actual number of sockets provided by a Windows Sockets implementation.
from::
http://burks.brighton.ac.uk/burks/pcinfo/progdocs/winsock/winsock2.htm
一般也是这么用的，下面这个文章也是这么说的，是链接期决定的
Maximum number of sockets supported
The maximum number of sockets supported by a particular Windows Sockets supplier is implementation specific. An application should make no assumptions about the availability of a certain number of sockets. This topic is addressed further in section 4.3.15, WSAStartup(). However, independent of the number of sockets supported by a particular implementation is the issue of the maximum number of sockets which an application can actually make use of.
The maximum number of sockets which a Windows Sockets application can make use of is determined at compile time by the manifest constant FD_SETSIZE. This value is used in constructing the fd_set structures used in select() (see section 4.1.18). The default value in winsock.h is 64. If an application is designed to be capable of working with more than 64 sockets, the implementor should define the manifest FD_SETSIZE in every source file before including winsock.h. One way of doing this may be to include the definition within the compiler options in the makefile, for example adding -DFD_SETSIZE=128 as an option to the compiler command line for Microsoft C. It must be emphasized that defining FD_SETSIZE as a particular value has no effect on the actual number of sockets provided by a Windows Sockets implementation.
from::
http://burks.brighton.ac.uk/burks/pcinfo/progdocs/winsock/winsock2.htm
醉马不肖 2003-09-23
- 打赏
- 举报
/*
* Select uses arrays of SOCKETs. These macros manipulate such
* arrays. FD_SETSIZE may be defined by the user before including
* this file, but the default here should be >= 64.
*
* CAVEAT IMPLEMENTOR and USER: THESE MACROS AND TYPES MUST BE
* INCLUDED IN WINSOCK2.H EXACTLY AS SHOWN HERE.
*/
#ifndef FD_SETSIZE
#define FD_SETSIZE 64
#endif /* FD_SETSIZE */
typedef struct fd_set {
u_int fd_count; /* how many are SET? */
SOCKET fd_array[FD_SETSIZE]; /* an array of SOCKETs */
} fd_set;
完全断口书上说有64的限制，所以我编程不用完全断口
* Select uses arrays of SOCKETs. These macros manipulate such
* arrays. FD_SETSIZE may be defined by the user before including
* this file, but the default here should be >= 64.
*
* CAVEAT IMPLEMENTOR and USER: THESE MACROS AND TYPES MUST BE
* INCLUDED IN WINSOCK2.H EXACTLY AS SHOWN HERE.
*/
#ifndef FD_SETSIZE
#define FD_SETSIZE 64
#endif /* FD_SETSIZE */
typedef struct fd_set {
u_int fd_count; /* how many are SET? */
SOCKET fd_array[FD_SETSIZE]; /* an array of SOCKETs */
} fd_set;
完全断口书上说有64的限制，所以我编程不用完全断口
AaronChan 2003-09-23
- 打赏
- 举报
书上说没有限制，我也没测试过！
UP UP
UP UP
petpetg 2003-09-22
- 打赏
- 举报
我不会
bulesnow 2003-09-22
- 打赏
- 举报
可以，但须自己改变。如下：
一个Windows Sockets应用程序可以使用的套接口的最大数目是在编译时由常量FD_SETSIZE决定的。这个常量在select()函数（参见4.1.18）中被用来组建fd_set结构。在WINSOCK.H中缺省值是64。如果一个应用程序希望能够使用超过64个套接口，则编程人员必须在每一个源文件包含WINSOCK.H前定义确切的FD_SET值。FD_SETSIZE缺省值为64，可在包含winsock.h前用#define FD_SETSIZE来改变该值
一个Windows Sockets应用程序可以使用的套接口的最大数目是在编译时由常量FD_SETSIZE决定的。这个常量在select()函数（参见4.1.18）中被用来组建fd_set结构。在WINSOCK.H中缺省值是64。如果一个应用程序希望能够使用超过64个套接口，则编程人员必须在每一个源文件包含WINSOCK.H前定义确切的FD_SET值。FD_SETSIZE缺省值为64，可在包含winsock.h前用#define FD_SETSIZE来改变该值
sevencat 2003-09-22
- 打赏
- 举报
同一时间能处理的估计是蛮多的，
不过大家都在等而已了。
系统中能同时进行处理的应该是你的CPU数目。
不过大家都在等而已了。
系统中能同时进行处理的应该是你的CPU数目。
szjay 2003-09-22
- 打赏
- 举报
ting
ZHENG017 2003-09-22
- 打赏
- 举报
喝喝，我试过ms的CreateIoCompletionPort,然后GetQueuedCompletionStatus以及codeproject上的io complete port的使用BindIoCompletionCallback的例子。
自己写的测试程序，开64个线程各个线程与server通信1000次和各自通信1次。（就最简单的只把送来的数据转发).不出错。但如果开65个线程各自通信1次都出错。
在select模型中，系统有限制是64.
楼上的兄弟做过实践吗？
自己写的测试程序，开64个线程各个线程与server通信1000次和各自通信1次。（就最简单的只把送来的数据转发).不出错。但如果开65个线程各自通信1次都出错。
在select模型中，系统有限制是64.
楼上的兄弟做过实践吗？
ypos 2003-09-22
- 打赏
- 举报
没有限制，直到用光系统资源
mfc168 2003-09-22
- 打赏
- 举报
这个与系统的并发数量有关了，socket的数量是没有这个限制的，具体的也不大清楚，算是帮你UP
windbells 2003-09-22
- 打赏
- 举报
当然能够处理，你把创建的socket的句柄绑定到完成端口上就可以了。
然后在工作线程里根据得到完成端口状态的返回结果进行处理
然后在工作线程里根据得到完成端口状态的返回结果进行处理
Billy_Chen28 2003-09-22
- 打赏
- 举报
不太清楚，给你顶一下！
