在处理 UDP 多播和多线程时跟踪间歇性问题的技术？
我想知道您是否有任何建议来追踪涉及由多个线程处理 UDP 多播数据包的棘手问题。
- 该问题总是在程序启动时出现，即启动后1秒内。因此，我知道问题发生的时间窗口。
- 该问题仅在程序运行大约 20 次时出现一次。其他 19 次运行，运行完美。
- 该程序正在将 UDP 多播数据包重新组装成数据包，如果出现问题，则数据包的内容格式错误（可以使用 CRC 检查）。
.NET 中是否有任何调试技术可用于跟踪涉及网络 UDP 数据包的多线程环境中的错误？
在这样的环境中如何获得可见性？
I'm wondering if you have any recommendations to track down a tricky problem that involves UDP multicast packets being handled by multiple threads.
- The problem always occurs when the program is started up, within 1 second of startup. So, I know the time window that the problem occurs in.
- The problem occurs only once in about 20 runs of the program. The other 19 runs, it works flawlessly.
- The program is reassembling the UDP multicast packets into data packets, if the problem occurs then the contents of the data packets are malformed (this can be checked with a CRC).
Are there any debugging techniques in .NET that you can use to track down bugs in multithreaded environments that involve network UDP packets?
How do I get visibility in such an environment?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果没有更多信息，我无法给出具体建议。我将从以下开始。
我要做的第一件事是检查聚合和重新组装数据包的代码中是否存在可能的竞争条件。不知何故，您从多个线程获取数据包并将它们组合起来。通常，这是通过以下两种方式之一完成的：单个线程将数据包排队以由专用线程（多生产者，单消费者设计）处理，或者使用某种允许线程共享缓冲区的同步。也就是说，每个线程将其传入数据包添加到组合数据包中。
前者更容易控制。您可以使用并发队列（例如 .NET
BlockingCollection），而不必担心同步问题。如果您使用带锁的Queue，或者您的各个线程正在协作组合数据包，则必须确保同步中不存在任何漏洞。另一种可能性是一个或多个传入数据包以某种方式损坏，或者阅读器没有正确读取它。您应该记录每个传入数据包以及线程号和传入时间。当问题出现时，您可以检查日志以查看数据包是否处于良好状态。如果是，那么几乎可以肯定问题出在您的同步上。
由于缺乏有关您的具体应用的更多信息，我没有任何其他建议。
Without more information, I can't give specific recommendations. I'd start with the following.
The first thing I'd do is check to see if there are possible race conditions in the code that aggregates and reassembles the packets. Somehow, you're taking packets from multiple threads and combining them. Typically this is done in one of two ways: either the individual threads queue packets for processing by a dedicated thread (a multiple producer, single consumer design), or you use some kind of synchronization that allows the threads to share a buffer. That is, each thread adds its incoming packet to the combined packet.
The former is easier to control. You can use a concurrent queue (such as the .NET
BlockingCollection) and not worry about synchronization. If you're using aQueue<T>with a lock, or if your individual threads are cooperating to combine the packets, you have to make sure that there aren't any holes in your synchronization.Another possibility is that one or more of the incoming packets is corrupt in some way, or the reader isn't reading it correctly. You should log every incoming packet along with the thread number and the time it came in. When the problem crops up, you can check the log to see if the packets are in good shape. If they are, then the problem is almost certainly with your synchronization.
Absent more information about your specific application, I don't have any other recommendations.