IOCP 摘要

windows 高级编程指南 第三版 Page 601

IIS 使用了一个相当复杂的算法来管理它的线程池。IIS 创建的最大线程数目是动态的。当IIS初始化时，对每个 CPU ，它最多允许创建 10 个线程。不过，根据客户请求，这一最大值可能会增加。IIS 设的最大值是计算机上的 RAM 的 M 字节数的两倍。

当一个客户请求要执行一个 ISAPI DLL 中的代码时，IIS 增大了池中的最大线程数目。当 ISAPI 函数返回时，IIS 减少了该值。这是因为 IIS 不知道 ISAPI DLL 函数要做什么事情。如果函数进入了一个无限循环，IIS 就失去了一个线程。所以 IIS 就增大了池中的最大线程数目。


Page 598
GetQueuedCompletionStatus返回可能有多种原因，如果传递无效完成端口句柄，函数返回False，GetLastError返回一个错误(ERROR_INVALID_HANDLE),如果超时，返回False, GetLastError返回WAIT_TIMEOUT, i/o完成队列删除一项，该表项是一个成功完成的I/O请求，则返回True。

当从 I/O 完成队列中删除一项时，有 lpdwNumberOfBytesTransferred, lpdwCompletionKey 和 lpOverlapped 参数指向的变量被设为反映该表项的信息。如果删除的表项代表一个成功完成的 I/O 请求，GQCS 返回 TRUE 。不过，如果删除的表项代表一个失败的 I/O 请求，GQCS 将返回 FALSE，调用 GetLastError 返回失败的原因。

可以通过检查 lpOverlapped 变量的值来判断 GQCS 失败的原因，如下面的代码所示：

[code]

DWORD dwNumberOfBytesTransferred, dwCompletionKey;

LPOVERLAPPED lpOverlapped;

BOOL fOk = GQCS( ..., &dwNumberOfBytesTransferred, &dwCompletionKey,
&lpOverlapped, 1000 );

DWORD dwError = GetLastError();

if( fOk ) {
// process a successfully completed I/O request.
} else {
if( lpOverlapped != NULL ) {
// process a failed completed I/O request.
// dwError contains the reason for failure
} else {
if( dwError == WAIT_TIMEOUT ) {
// Time-out while waiting for completed I/O entry
} else {
// Bad call to GQCS
// dwError contains the reason for the bad call
}
}
}
[/code]

http://itamarst.org/writings/win32sockets.html

[quote]
Differences in partial writes to TCP sockets (contributed by James Knight).
In Unix, socket.send(buf) will buffer as much of buf as it has space for, and then return how much it accepted. This could be 0 or up to something around 128K. If you send some data and then some more, it will append to the previous buffer.

In Windows, socket.send(buf) will either accept the entire buffer or raise ENOBUFS. Testing indicates that it will internally buffer any amount up to 50MB (this seems to be the total for either the process or the OS, I'm not sure). However, it will not incrementally accept more data to append to a socket's buffer until the big buffer has been completely emptied (seemingly down to the SO_SNDBUF length, which is 8192), but rather raises WSAEWOULDBLOCK instead.

[/quote]

<Network Programming for Microsoft Windows, Second Edition>

[quote]
Maximizing Connections
Maximizing the number of concurrent client connections is the more difficult of the two strategies. Handling the I/O on each connection becomes difficult. A server cannot simply post one or more sends or receives on each connection because the amount of memory (both in terms of locked pages and non-paged pool) is great. In this scenario, the server is interested in handling many connections at the expense of throughput on each connection. An example of this would be an instant messenger server. The server would handle many thousands of connections but would need to send or receive only a small number of bytes at a time.

For this strategy, the server does not necessarily want to post an overlapped receive on each connection because this would involve locking many pages for each of the receive buffers. Instead, the server can post an overlapped zero-byte receive. Once the receive completes, the server would perform a non-blocking receive until WSAEWOUDLBLOCK is returned. This allows the server to immediately receive all buffered data received on that connection. Because this model is geared toward clients that send data intermittently, it minimizes the number of locked pages but still allows processing of data on each connection.
[/quote]