c++ - 最适合即时消息客户端的异步套接字模型？

Question

我正在使用 C++ (Win32) 开发即时消息客户端，并且正在试验不同的异步套接字模型。到目前为止，我一直在使用 WSAAsyncSelect通过我的主窗口接收通知。但是，我遇到了一些意外的结果，Winsock 为一个套接字额外生成了 5-6 个线程(除了调用 WSAAsyncSelect 时创建的初始线程之外)。

我计划改造客户端以通过 DLL:s 支持其他协议(protocol)，而且我担心根据我使用 WSAAsyncSelect 的经验，我当前的解决方案不适合，此外我对将网络与 UI 混合持否定态度代码(在消息循环中)。

我正在寻找适合多协议(protocol) IM 客户端的异步套接字模型的建议，该客户端需要能够处理大约 10-20+ 个连接(取决于数量协议(protocol)和协议(protocol)设计等)，同时不使用过多的线程——我对性能和降低资源使用量非常感兴趣。

我一直在寻找 IO Completion Ports，但从我收集到的信息来看，它似乎有点过分了。我非常感谢您就合适的套接字解​​决方案提供一些意见!

提前致谢! :-)

Answer 1

有四种基本方法可以处理多个并发套接字。

1. 多路复用，即使用 select() 轮询套接字。
2. AsyncSelect，这基本上就是您使用 WSAAsyncSelect 所做的事情。
3. 工作线程，为每个连接创建一个线程。
4. IO 完成端口，或 IOCP。 dp 在上面提到了它们，但基本上它们是操作系统特定的处理异步 I/O 的方法，具有非常好的性能，但有点令人困惑。

您选择哪一个通常取决于您打算去哪里。如果您打算将应用程序移植到其他平台，您可能希望选择#1 或#3，因为 select 与其他操作系统上使用的其他模型并没有太大的不同，而且大多数其他操作系统也有线程的概念(尽管它们可能操作不同)。 IOCP 通常是特定于 Windows 的(尽管 Linux 现在也有一些异步 I/O 函数)。

如果您的应用仅适用于 Windows，那么您基本上想要为您正在做的事情选择最佳模型。这可能是#3 或#4。 #4 是最有效的，因为它会回调您的应用程序(类似，但性能更好，WSAsyncSelect 问题更少)。

使用线程(IOCP 或 WorkerThreads)时，您必须处理的一件大事是将数据编码回可以更新 UI 的线程，因为您无法在工作线程上调用 UI 函数。最终，在大多数情况下，这将涉及一些来回消息传递。

如果您在托管代码中开发它，我会告诉您看看 Jeffrey Richter 的 AysncEnumerator，但您选择了 C++，它有利也有弊。许多人为 C++ 编写了各种网络库，也许您应该花些时间研究其中的一些。