当前位置:  开发笔记 > 运维 > 正文

高性能udp服务器.阻止还是非阻塞?C

如何解决《高性能udp服务器.阻止还是非阻塞?C》经验,为你挑选了1个好方法。

我一直在做阻断,相较于UDP非阻塞套接字大量的阅读,但我有一个很难理解一个比其他的优点.互联网上的绝大多数评论似乎都表明非阻塞性更好,但对于哪些情况下它们会更好,并不是非常具体,而且我发现没有任何参考资料,只要阻止是首选.我对这个问题的希望是,社区可能会对这个问题有所启发.

关于我自己的问题集的一些背景知识,以便可以专门应用答案以及问题的一般性质.我有一个udp服务器,我写的将在本地局域网上有40个连接,从而可以流入恒定的数据流.数据速率将达到250MB/s avg,峰值达到500 + Mb/s,平均值数据报大小约为1400字节.数据报的处理很轻,但由于大量的msgs效率和性能是高优先级,以防止丢包.

因为我无法真正找到类似于这个特定问题集的内容的任何上下文信息,所以我必须根据我能够收集的关于阻塞与非阻塞的内容进行一些猜测.我将用我目前的假设结束这一点,然后打开你的输入.基本上,因为这将是每个连接上几乎恒定的数据包流,我认为阻塞套接字会更好,因为任何recv函数实际花费阻塞的时间与使用事件相比非常非常小基于模型,在异步模式下会有大量的触发器.我觉得我的真正的问题集很可能是我计划用于从套接字读取的40个线程的优先级管理...确保每个获得它们的cpu时间份额.我的方法和想法可能不正确,所以我希望并且如果社区可以帮助在这个问题上有所启发,我将非常感激.

问候,吉姆.

〜编辑〜

而我担心线程设计将如何影响/整合阻塞/非阻塞问题.我真的最关心的是如何从我的问题集的角度来看待阻止/非阻塞.如果线程确实成为一个问题,我可以使用线程池解决方案.

〜EDIT2〜

首先,想说你到目前为止的回答.你们中的一些人已经提到过具有这么多套接字的单线程/套接字模型可能是一个坏主意,我承认我自己是解决方案.然而,在nikolai响应中的一个链接中,作者讨论了一个单线程/套接字模型,并链接到一个非常有趣的论文,我认为我将链接到这里,因为它消除了我对线程与事件有关的很多神话基于模型:为什么事件是一个坏主意

请享用.



1> Nikolai Feti..:

不是答案,只是一些链接,如果你的书签中还没有它们:

Dan Kegel 的C10K问题,Jeff Darcy
的高性能服务器架构,
高级轮询API:epoll(4), kqueue(2).

编辑:

虽然听起来很愚蠢,但我完全错过了你正在使用UDP,所以...

由于UDP中没有协议级连接,除非您必须在不同的端口工作,否则服务器上不需要40个套接字.只有一个 UDP"服务器"套接字可以为所有客户端做.您可以阻止这一个套接字,只需确保套接字接收缓冲区足够大,以适应流量峰值,并且不会花太多时间处理每次读取.

推荐阅读
女女的家_747
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有