我一直在做阻断,相较于UDP非阻塞套接字大量的阅读,但我有一个很难理解一个比其他的优点.互联网上的绝大多数评论似乎都表明非阻塞性更好,但对于哪些情况下它们会更好,并不是非常具体,而且我发现没有任何参考资料,只要阻止是首选.我对这个问题的希望是,社区可能会对这个问题有所启发.
关于我自己的问题集的一些背景知识,以便可以专门应用答案以及问题的一般性质.我有一个udp服务器,我写的将在本地局域网上有40个连接,从而可以流入恒定的数据流.数据速率将达到250MB/s avg,峰值达到500 + Mb/s,平均值数据报大小约为1400字节.数据报的处理很轻,但由于大量的msgs效率和性能是高优先级,以防止丢包.
因为我无法真正找到类似于这个特定问题集的内容的任何上下文信息,所以我必须根据我能够收集的关于阻塞与非阻塞的内容进行一些猜测.我将用我目前的假设结束这一点,然后打开你的输入.基本上,因为这将是每个连接上几乎恒定的数据包流,我认为阻塞套接字会更好,因为任何recv函数实际花费阻塞的时间与使用事件相比非常非常小基于模型,在异步模式下会有大量的触发器.我觉得我的真正的问题集很可能是我计划用于从套接字读取的40个线程的优先级管理...确保每个获得它们的cpu时间份额.我的方法和想法可能不正确,所以我希望并且如果社区可以帮助在这个问题上有所启发,我将非常感激.
问候,吉姆.
〜编辑〜
而我担心线程设计将如何影响/整合阻塞/非阻塞问题.我真的最关心的是如何从我的问题集的角度来看待阻止/非阻塞.如果线程确实成为一个问题,我可以使用线程池解决方案.
〜EDIT2〜
首先,想说你到目前为止的回答.你们中的一些人已经提到过具有这么多套接字的单线程/套接字模型可能是一个坏主意,我承认我自己是解决方案.然而,在nikolai响应中的一个链接中,作者讨论了一个单线程/套接字模型,并链接到一个非常有趣的论文,我认为我将链接到这里,因为它消除了我对线程与事件有关的很多神话基于模型:为什么事件是一个坏主意
请享用.
我不太确定对 40 个套接字使用 40 个线程是个好主意...当然，当套接字数量较少时，每个套接字使用一个线程是有意义的，但是拥有这么多线程只会导致线程饥饿、死锁，以及丢失的数据包。
至于阻塞与非阻塞，请记住阻塞可能相对昂贵......尽管在我看来它更容易使用。异步触发器等总体上可能比阻塞/唤醒线程更快。