提升 asio 异步与阻塞读取、udp 速度/质量
我有一个用 C# 编写的快速但肮脏的概念验证应用程序，它从网络读取高数据速率多播 UDP 数据包。 由于各种原因，完整的实现将用 C++ 编写，我正在考虑使用 boost asio。 C# 版本使用线程通过阻塞读取来接收数据。 如果计算机负载很重（通常在另一个线程中处理这些数据包），我会遇到一些丢包的问题。
我想知道的是 异步读取操作（在Windows中使用重叠IO）将有助于确保我接收数据包和/或减少接收数据包所需的CPU时间。 执行阻塞读取的单线程非常简单，使用异步读取似乎增加了复杂性，但我认为如果它能提供更高的性能或在负载较重的系统上丢弃更少的数据包，那么这是值得的。 目前数据速率不应高于 60Mb/s。
I have a quick and dirty proof of concept app that I wrote in C# that reads high data rate multicast UDP packets from the network. For various reasons the full implementation will be written in C++ and I am considering using boost asio. The C# version used a thread to receive the data using blocking reads. I had some problems with dropped packets if the computer was heavily loaded (generally with processing those packets in another thread).
What I would like to know is if the async read operations in boost (which use overlapped io in windows) will help ensure that I receive the packets and/or reduce the cpu time needed to receive the packets. The single thread doing blocking reads is pretty straightforward, using the async reads seems like a step up in complexity, but I think it would be worth it if it provided higher performance or dropped fewer packets on a heavily loaded system. Currently the data rate should be no higher than 60Mb/s.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我还使用
boost::asio编写了一些多播处理代码。 我想说的是，总的来说，根据我的经验，在asio中做事会增加很多复杂性，这可能会让与你一起工作的其他人不容易理解你最终编写的代码。也就是说，可能支持迁移到 asio 而不是使用大量不同线程来完成工作的论点是，您将需要进行更少的上下文切换。 这在单核机器上显然是正确的，但是当你使用多核机器时呢？ 您是否计划将收到的工作卸载到线程或仅让单个线程执行处理工作？ 如果您采用单线程方法，您最终会遇到这样的情况：您可能会丢弃等待该线程处理工作的数据包。
最后就是秋千和回旋处。 我想说，如果你打算这样做，你想要得到一些相当可靠的数据来支持你走这条路的论点，只是因为它所带来的所有额外的复杂性（我确信对某些人来说这是一个全新的范式） ）。
I've written some multicast handling code using
boost::asioalso. I would say that overall, in my experience there is a lot of added complexity to doing things inasiothat may not make it easy for other people you work with to understand the code you end up writing.That said, presumably the argument in favour of moving to
asioinstead of using lots of different threads to do the work is that you would have to do less context switching. This would clearly be true on a single-core box, but what about when you go multi-core? Are you planning to offload the work you receive to threads or just have a single thread doing the processing work? If you go for a single threaded approach you are going to end up in a situation where you could drop packets waiting for that thread to process the work.In the end it's swings and roundabouts. I'd say you want to get some fairly solid figures backing up your arguments for going down this route if you are going to do so, just because of all the added complexity it entails (a whole new paradigm for some people I'm sure).