TCP服务器中epoll_wait收到未知事件值5的原因咨询

我来帮你拆解一下这个问题——你看到的事件值5，其实是两个epoll事件的组合：EPOLLIN（值为1）加上EPOLLRDHUP（值为4），两者的位或结果正好是5。下面具体解释这个场景和处理方式：

事件含义拆解 #

• EPOLLIN：表示对应的文件描述符上有数据可读。这里要注意，TCP连接中对端发送的FIN包也会触发“可读”状态，此时调用read()/recv()会返回0，用来标识对端已经关闭连接。
• EPOLLRDHUP：这是Linux系统特有的epoll事件，用来表示对端已经关闭了连接的写方向，或者整个TCP连接已经断开（比如客户端主动调用close()关闭连接时，就会触发这个事件）。

为什么会出现这个事件组合 #

当客户端主动关闭连接时，会向服务器发送FIN报文。服务器的TCP协议栈收到FIN后，会做两件事：

1. 将对应的已连接socket标记为可读状态，触发EPOLLIN事件；
2. 因为对端已经关闭了写通道，触发EPOLLRDHUP事件。

这两个事件同时被触发，所以epoll_wait返回的事件值就是1 | 4 = 5，也就是你看到的“未知事件”。

如何正确处理这个事件 #

当收到这个事件时，你需要按以下步骤处理，避免资源泄漏：

1. 调用read()或recv()读取该socket的数据：

   char buf[1024];
   ssize_t n = read(client_fd, buf, sizeof(buf));
   

   如果返回值n == 0，说明对端已经关闭连接；如果返回值小于0，要根据errno判断是错误还是正常的中断（比如EINTR）。
2. 确认连接关闭后，将该文件描述符从epoll实例中移除：

   epoll_ctl(epoll_fd, EPOLL_CTL_DEL, client_fd, NULL);
   

3. 最后关闭该socket的文件描述符：

   close(client_fd);
   

另外补充一点：如果你不需要EPOLLRDHUP事件，可以在调用epoll_ctl()添加socket时，不将这个事件加入监听掩码，但通常建议监听它，这样能更直观地感知到对端的连接状态变化。

内容的提问来源于stack exchange，提问作者rohan hariharan