C 套接字的半关机是否会导致epoll停止接收事件?

C 套接字的半关机是否会导致epoll停止接收事件?,c,sockets,tcp,C,Sockets,Tcp,假设我有一个相互通信的客户机和服务器模型,并且在服务器端将epoll设置为在EPOLLIN和epolout上唤醒。据我所知,客户端套接字读/写端可用性的更改将触发服务器中的epoll事件。假设我在客户机上关闭了一半,那么我就关闭了客户机的写端。然后,正如预期的那样,我在服务器端收到一个EPOLLIN事件。但是,现在,假设我关闭了套接字的读取端epoll_wait在发生此情况时未唤醒。我认为可能发生的情况是,一旦客户端的写端关闭,它就不能向服务器发送任何关于它正在关闭读端的通知。另一方面,我认为拥

假设我有一个相互通信的客户机和服务器模型,并且在服务器端将epoll设置为在
EPOLLIN
epolout
上唤醒。据我所知,客户端套接字读/写端可用性的更改将触发服务器中的epoll事件。假设我在客户机上关闭了一半,那么我就关闭了客户机的写端。然后,正如预期的那样,我在服务器端收到一个
EPOLLIN
事件。但是,现在,假设我关闭了套接字的读取端
epoll_wait
在发生此情况时未唤醒。我认为可能发生的情况是,一旦客户端的写端关闭,它就不能向服务器发送任何关于它正在关闭读端的通知。另一方面,我认为拥有
epolout
会告诉我客户机读端/服务器写端状态的任何变化,但事实并非如此


我知道我可以检查失败的写入/SIGPIPE以查看客户端是否关闭了其读取端,但我更好奇的是,这是预期的行为还是我的代码的问题,如果是预期的,为什么会这样?

当客户端关闭其“读取端”时,服务器将不会收到通知

相反,当服务器检测到客户端已关闭其“写入端”时,服务器应决定何时完成数据写入,然后关闭自己的“写入端”。这将完全关闭TCP连接


如果您担心服务器可能会在客户端读取所有发送的数据之前过早地关闭连接,TCP会解决这个问题。与关闭“写入端”相关联的FIN数据包在其前面发送的数据包后面排队。只要客户端通过连续调用
recv
处理来自服务器的数据,
0
的返回值将指示所有可用数据都已读取。

当客户端关闭其“读取端”时,服务器将不会收到通知

相反,当服务器检测到客户端已关闭其“写入端”时,服务器应决定何时完成数据写入,然后关闭自己的“写入端”。这将完全关闭TCP连接


如果您担心服务器可能会在客户端读取所有发送的数据之前过早地关闭连接,TCP会解决这个问题。与关闭“写入端”相关联的FIN数据包在其前面发送的数据包后面排队。只要客户端通过连续调用
recv
处理来自服务器的数据,
0
的返回值将指示所有可用数据都已读取。

TCP协议中没有任何内容通知另一端已关闭读取端。您发送
FIN
表示您已停止写作,但仅此而已。@Barmar谢谢!如果是这种情况,那么当客户端的读取端准备就绪时,
epolout
是如何触发的呢。这表明本地端有用于输出的缓冲区空间,而不是客户端已准备好读取。TCP协议中没有任何内容可通知另一端已关闭读取端。您发送
FIN
表示您已停止写作,但仅此而已。@Barmar谢谢!如果是这种情况,那么当客户端的读取端准备就绪时,
epolout
是如何触发的呢。这表明本地端有用于输出的缓冲区空间,而不是客户端已准备好读取。