继我们遇到的问题之后，我试图了解当进程忙于使用重复调用send()在套接字上写入数据(数千个UDP视频数据包+偶尔的TCP消息(时ARP表更改的影响/影响。
似乎，无论出于何种原因，我们的进程(更准确地说：Live555 WIS-Streamer的进程(都被这个事件绊倒/阻止了。
任何人都可以帮助我了解在这种情况下可能发生的情况 - 我们可能期望/从send()中捕获哪些错误/返回状态，我们如何在代码中缓解这种情况？
我目前正在阅读名为Understanding Linux network Internals(仅1035页(的信息小册子，但非常感谢任何有助于加速调试过程的提示！
编辑以添加：我不希望人们认为我忽略了有关端口状态或进程状态的问题，该问题很少发生(平均可能每 24 小时发生一次(，并且仅在一个(远程(安装上我们无法轻松访问，我们正在努力在实验室中复制它，以便我们可以进行更详细的诊断，但系统看门狗在问题发生后 ~3 分钟内重置， 因此，当消息到达我们时，它已经重新启动并开始正常工作。
编辑以添加Wireshark信息：我不确定在这里总结 wireshark 捕获的最佳方法(很难上传 ~1TB 捕获的数据包！(，但我会尝试。 Cam:X & Cam:Y 是由两个相同的 Live555 WIS Streamer 实例从不同端口流式传输的两个 RTSP 视频流。服务器"A"和"B"是服务器上两个网卡的 MAC。
数据包的顺序如下所示：
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
ARP Packet to Cam from Server 'B' "<my IP> is now on 'B'"
Intel ANS Probe broadcast from Server 'B', Sender ID '1' team ID 'B'
Intel ANS Probe broadcast from Server 'A', Sender ID '2' team ID 'B'
<silence> from Cam:X
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
此时或前后流中没有其他数据包。英特尔 ANS 数据包并不总是与来自 NIC 的 ARP 一致，但为了完整起见，我想我会包含它们。
这个问题似乎对时间非常敏感，我们经常从服务器看到这些"团队"ARP，只有一次在蓝月亮中它们给我们带来问题 - 好像网络堆栈代码中有一个特定的点对ARP表的变化很敏感。它并不总是同一个流实例，值得注意的是另一个实例(以及所有其他网络流量 - HTTP 等(继续正常工作。
听起来成组的 NIC "不应该"像这个会话中那样的 ARP，但当然，当流量都是 UDP 时，他们不会意识到任何会话。
，如果只是为了解决这个问题，客户重新配置了他们狡猾的网卡并且一切正常，所以不幸的是，对于好奇的人来说，这意味着没有人会付钱给任何人太仔细地查看可以做些什么来解决这个问题。