IUnknown

什么时候发布啊？

这里有一个用 zero byte buffer 策略集成 iocp 到 libevent 的方案。
具体的源代码：http://spserver.googlecode.com/files/libevent-1.4.4-iocp-3.zip

vc6 的 dsw 文件在 libevent-1.4.4-iocp-3/libevent-iocp 目录中。
这个方案就是单线程负责 IO ，里面有 echo_iocp.exe 和 testiocpstress.exe ，可以试试看它的性能。

方案的描述可以看看
http://monkeymail.org/archives/libevent-users/2008-June/001269.html

@爱上龙卷风
>>>关于你提到的框架，本质上是多线线程的。负责 IO 的线程数目理论上本来就应该是你机器cpu的个数。前提是你保证你的io设计是异步执行的。

框架中用到了多线程，不过用于处理 IOCP 的线程（或者称为用于处理前端网络 IO 的线程）就只有一个。后端的线程池是用于处理具体的业务的，不会涉及前端的网络 IO 的。前端的网络 IO 可以非常清晰地剥离出来，由一个单独的线程来负责。在 input 的时候，在前端的 IO 线程中读入数据，放入 inputqueue，线程池负责 inputqueue；output 的时候，线程池把结果放入 outputqueue ，前端 IO 线程负责处理 outputqueue 。

@RedFox
我也是進來討論你提出的第三個問題的。

通常的做法是一個 Socket 用一個 WSARecv 異步操作，有完成事件時，先處理完這個異步操作時，才再次發出下一個 WSARecv 異步操作。這樣就不會有你說的消息亂序問題了。

而你說的一次對同一個 socket 提交 n 個 WSARecv 操作。我認為是不可取的。


也是用这个方法来实现的，这样做会比较简单，可以避免消息的乱序问题。而且在关闭 socket 释放资源的时候，也相对容易控制。

@爱上龙卷风
你应该弄错了,的确,如果按照你的说法,就是单线程了,没有多线程。
当然没有问题。但是，你的performance是没法保证的，几乎没有什么
throughput的。


关于这一点，有实现过一个用单线程负责 IO 操作，线程池负责业务逻辑处理的 server framework 。负责 IO 的单线程，主要是执行 WSARecv， WSASend ，GetQueuedCompletionPort，具体的业务逻辑不在这个线程里面执行。
用这个框架实现过一个 echo server ，进行大压力测试，发现 throughput 还是很高的。可以认为在目前的 CPU 速度下，只是执行 WSARecv，WSASend，GetQueuedCompletionPort ，还是足够快的。
如果在同一台机运行 client 和 server，测试的结果是可以达到每秒 send 10万， recv 10万。