IO重量级操作与监听UDP和SCTP数据的网络应用程序之间的问题

当你说UDP套接字关闭时,你确切的意思是什么?你试试看 send 但失败了?

对于SCTP,可以在这些I/O操作运行时收集wireshark或pcap跟踪吗(最好在对等机上运行wireshark)?我的猜测是(一个有教育意义的猜测,不看代码),当这些I/O操作出现在图片中时,您的进程会因CPU时间而变得匮乏。另一端发送 SCTP Heartbeat messages 但没有得到回复。或者,如果数据正在流动,则对等端没有接收到任何 SACKS 因为它们还没有被您端的SCTP堆栈处理。

因此,对等端会在内部中止关联并停止向您发送数据(因为它将所有路径都视为关闭,所以不会发送中止)。在这种情况下,您的SCTP堆栈仍然认为关联是活动的)。 尝试确认值是什么 Heartbeat timeout, RTO timeout,SACK timeout, maximum Path retransmission & max Association retransmission 在对等端。我还没有使用内核sctp,但是sysctl应该能够为您提供这些值。

无论哪种方法,当您观察到这个问题时收集PCAP跟踪,都可以让我们更好地了解出了什么问题。希望有帮助。

以下是我要调查的一些事情:

当脚本未运行时,在UDP套接字上加载什么?是连续的还是剧烈的?当脚本不运行时,套接字是否会自动关闭?从套接字读取的数据发生了什么情况?从套接字(原始或已处理)生成的数据有多少被写入磁盘?您能监视CPU、网络和磁盘IO利用率以查看它们中的任何一个是否已饱和吗?运行IO操作的脚本能否以较低的优先级运行,或者相反,运行UDP套接字的进程能否以较高的优先级运行?

有一件事是,allot of people不检查send的返回值,他们也不检查诸如 EINTR 在 recv 可能是IO负载太重导致了 send 或 雷科 你的应用程序将这些错误视为一个硬错误,在不知道这些错误是暂时的情况下关闭套接字。

我已经看到了这种情况的发生,你应该通过启动日志级别来检查它,看看你的应用程序是否在意外地调用close。