我正在开发一个多协议套接字服务器,在我第一次尝试时,我把它作为事件驱动,因为这是我所知道的最好方法,但是通过使用这种方法,我无法找到将应用程序特定数据链接到套接字的有效方法所以在每个事件中我都必须执行搜索才能将套接字链接到其上下文.经过一些研究后,我发现IO完成端口是一个更好的工作方式,所以经过大量阅读后,我终于能够重新编写代码,以便在IOCP方法下工作.
但经过一些进一步的研究后,我发现这篇文章(请阅读:"接受连接")建议通过在另一个线程上处理FD_ACCEPT事件来将接受操作与I/O进程分离,他还建议将此作为预防的手段恶意攻击...解释确实有意义,但作者没有考虑到在这种方法下没有办法(至少AFAIK)将套接字与其上下文数据相关联,因此在侦听的服务器上应用此建议绑定到多个地址的几个端口和每个处理不同协议的端口,必然涉及每个FD_ACCEPT事件的搜索操作,这可能(或可能不)打败解除接受的原始提议......这是我迁移到的原因首先完成港口.
所以..我想知道是否有2个完成端口,一个用于接受操作,一个用于I/O过程可以被认为是一般的热门,但特别是关于性能......或者最好只有一个？
更新:
经过一些实验,我发现,通过使用2个IOCP(在分离的线程上)将接受过程与I/O过程分离是根本不可行的,并且由于这个事实,不能获得效率提升.因此,即使他没有明确提及它,作者也是正确的,解耦这两个过程的唯一可行方法是通过处理FD_ACCEPT事件所有暗示,但如果他在他的陈述中也是正确的,那么唯一在我的情况下使其可行的方法是找到一种有效的方法将每个套接字链接到其上下文数据,或者换句话说; 无需搜索,所以原始问题仍然存在.
如果您使用IOCP进行数据流,那么通常最好使用IOCP来接受新连接,因此使用AcceptEx()是一个好主意.不要费心去处理使用它来读取来自对等端的第一块数据的复杂性,很难避免这种打开的潜在拒绝服务攻击,并且大多数服务器设计的性能提升可以忽略不计.只需将它作为重叠的Accept使用,这样可以节省每个端口必须有一个单独的接受线程,因此非常好地扩展.
就个人而言,我从未使用过FD_ACCEPT你所链接文章的想法.只需AcceptEx在完成后发布新内容并在开始时发布可配置的数字.这样你就会有'X'等待接受.
我在这里有一些文章和示例代码可能有所帮助.
| 归档时间： |
|
| 查看次数： |
509 次 |
| 最近记录： |