测试服务器出现很奇怪的问题。

yang_crystal

他的意思应该是客户端发送成功了，但是服务端此时还收不到数据，当客户端close时候才能收到刚发的数据和对方的close
自己认为的，

guochgz

很抱歉，没有表达清楚。

是这样的，现在测试到的情况是这样的。

client在发送登陆包后，然后进入等待接收状态。直到一个超时值耗完后。比如说。10s.
服务器在client超时后，读到登陆数据包，处理， 然后，又读到对端close（ 不一定是串行的，也有可能服务器在处理登陆包时，服务器读到对端关闭sock的事件）

现在的疑惑是：为什么这些client发出的包，服务器会在超时后，epoll才返回事件，如果说之前有数据包没有处理。那么，之后的该fd，应该不会处于就绪状态，也不会有事件返回才对。

guochgz

怎么说？

这个有无接收确认应该不会是导致该问题出现的根本原因吧。

converse

我大概猜猜,你用的epoll中的ET模式,而且服务器去读取数据的时候没有读到EAGAIN,也就是没有读到返回错误为止,而是只读了一部分数据,这样里面残存的数据就不会给server发通知,直到client超时关闭了导致连接状态发生变化server才收到通知.

flw

出现问题不要猜，要查。
学会使用各种系统工具去侦测/感知系统状态。
比如 netstat tcpdump snmp 等等。
搞明白是发送端的问题，还是接收端的问题。

guochgz

对的， 我之前也是这样怀疑的。 但是有两点让我排除这种可能性。

1： 因为通讯协议是固定长度的封包，而且，检测该sock，重连后，client只发了一个登陆包。 不会在发登陆包之前有数据到达的。
2： 即使有数据没有处理完。那么之后的epoll 也不会在sock的状态改变才返回啊。 因为ET模式，要不就不返回事件，要不立马返回。

回flw，谢谢你的忠告，我也一直认为臆想是程序员最大的毛病，只有测试-》分析问题-》得出结论才是正确的解决问题之道

converse

2： 即使有数据没有处理完。那么之后的epoll 也不会在sock的状态改变才返回啊。 因为ET模式，要不就不返回事件，要不立马返回。

你错了,ET模式要一直读到出错才行,否则如果缓冲区还有数据也不会通知的.我现在几乎可以肯定是这个原因了.

guochgz

你说的是正确的， 我之前一直把sock可读 和 接收到对端关闭sock，发送FIN，当作同一种状态，才钻入了死胡同。

converse

LZ,我针对使用EPOLL时需要注意的一些问题写了一份文档,你可以看看:

http://bbs.chinaunix.net/thread-1089208-1-1.html