tcp - EPOLLRDHUP 不可靠

Question

我正在使用 epoll_wait 在客户端-服务器 TCP 连接上使用非阻塞读/写。

问题是，我无法使用 EPOLLRDHUP 标志可靠地检测“peer closed connection”事件。经常发生没有设置标志的情况。客户端使用 close() 并且服务器在大多数情况下从 epoll_wait 接收到 EPOLLIN | EPOLLRDHUP 事件。正如预期的那样，读取产生零字节。不过，有时只有 EPOLLIN 出现，产生零字节。

使用 tcpdump 进行的调查表明，据我所知正常关机发生了。我看到一个 Flags [F.]、Flags [F.]、Flags [.] 事件序列，它们应该对应于 FIN、FIN 和 ACK。 SO_LINGER 未被使用。

我考虑过在零字节读取时处理'peer closed'，但是，您有可能得到一个EPOLLIN |具有非零字节可用的 EPOLLRDHUP 事件，当对等方发送并立即关闭连接时 - 我需要以 EPOLLRDHUP 为基础的情况。有什么建议吗？

Answer 1

要回答这个问题:EPOLLRDHUP 如果您在收到零字节读取后继续轮询，确实会出现。因此，从我的实验来看，读取零字节的 EPOLLIN 或 EPOLLRDHUP 似乎是有序关闭的可靠指标，唯一的问题是，它们没有一起接收。有时(成为这个问题的主题的情况)，碰巧收到 EPOLLIN，产生零字节(连接终止)，在随后的轮询中，您会看到 EPOLLRDHUP。其他时候，反之亦然:您将 EPOLLRDHUP 与 EPOLLIN 一起获取，后者表示要读取的实际字节数。然后，在后续读取中，您将获得零字节。