SocketIOCP

一个用 C# Socket 实现的 IOCP

这是一个用 C# Socket 实现的 IOCP 。

采用 Listener + Dispatch + Worker 的设计， Listener 是一个线程， Dispatch 是一个线程， Worker 是一组线程。一个 Socket 对应一个 Worker ，一个 Worker 对应一个线程。

Listener 负责监听 Accept() ，将 Socket 放到 SocketQueue 中， Dispatch 负责从 SocketQueue 中取出 Socket ，为 Socket 创建一个 Worker，并启动 Worker 。

测试结果，可以达到每秒 15000 个请求，和常规写法 ReceiveAsync() 是一个水平。两者的 CPU 占用率也差不多： Server 进程 20% 左右， System 进程 20% 左右，测试工具 12% 左右。

但是，效率最好的，是常规写法 Receive()，就是 1 线程监听 Accept()， n 线程 Receive() ，

每秒请求也是 15000 的水平，但是短时间内可以上升到 2 万或者 23000 。

而且，有一点重要的是， CPU 占用率更低。 Server 进程 10% 以下，很多时候 5% 左右，有时候 5% 以下。
System 进程 30% - 40% ，有时候超过 40% 。测试工具 10% 左右。

从这里可以看出来，常规写法 Receive() 的 loading 主要是在 System 进程上。我想 Socket 的工作线程就在 System 进程里。

System 进程是系统进程。操作系统的内核工作应该就是在这个 System 进程里。包括 Socket 虚拟内存等。

从这里可以看出来，并发测试的时候， System 进程正在做跟我们一样的事， SocketIOCP 相当于在外面又把 Socket 做的事又做了一遍。 ^^ 这就好像在裤子外面又套了一条裤子，当然会显得笨重和更加占用 CPU 资源。

但是反过来，如果从这个角度来看的话， SocketIOCP 能做到现在这样，也是不错了。 ^^

SocketIOCP 的设计，如果用来处理底层数据的输入输出，也会表现的很出色的。

最终的这个版本，实际上和常规写法 Receive() 一样，为每个 Socket 分配一个线程。这和我最初的 “用最小数量的线程来完成数据处理工作” 的想法不太一样。

因为，对于分时多任务，线程是最自然的做法。另一方面，为了保持实时响应性，也只能这样做。

所以，如果我们要写 Socket 网络应用，那么可能常规写法 Receive() 还是最好的写法。常规写法 Receive() 参考这篇文章： https://blog.csdn.net/andrew_wx/article/details/6629721/