首先,Winsock 异常 10035 WSAEWOULDBLOCK (WSAGetLastError) 的意识是 Output Buffer 已经满了,无法再写入数据。确切的说它其实不算是个错误,出现这种异常的绝大部分时候其实都不存在 Output Buffer 已满情况,而是处于一种“忙”的状态,而这种“忙”的状态还很大程度上是由于接收方造成的。意思就是你要发送的对象,对方收的没你发的快或者对方的接受缓冲区已被填满,所以就返回你一个“忙”的标志,而这时你再发多少数据都没任何意义,所以你的系统就抛出个 WSAEWOULDBLOCK 异常通知你,叫你别再瞎忙活了。
那么,我该怎么办呢?网上有很多朋友的做法是遇到这种情况就 Sleep 一段时间,一般短暂停顿后 Output Buffer 就空出来了,那就又可以继续发送了。不过我推荐另外的方法:根据 MSDN 文档所示,当出现 WSAEWOULDBLOCK 异常后直到空出 Output Buffer 时,系统会发送一个 FD_WRITE 给发送方。我们完全可以在等收到 FD_WRITE 消息后再重新发送从出现异常开始的数据包即可(该包需要全部重新发送)。
至此,该问题结案。最后顺便提一下:FD_WRITE 消息会在至少三钟情况下出现,而上面只是其中的一种,所以我建议给 Socket 做个标志判断以便于规范性。
以前对于FD_WRITE是怎么触发的,相关书籍上虽然清楚的列出了三种条件,却也是看不太明了。在今天,自己实现了一个通信程序的第一步骤:消息交换(呵呵),用单步跟踪的方式,在服务端程序上清楚的看了一回客户端程序连接、发送数据时服务端程序的消息反应。我的程序中,接收的消息不多,是主要的四种:FD_ACCEPT 、FD_READ 、FD_WRITE 、FD_CLOSE。
程序开始,连接的时候,服务端接收的是FD_ACCEPT FD_WRITE,接收数据时,就只有FD_READ 了。
这个时候,再回想书上列的三种条件:
1、使用connect或WSAConnect,一个套接字首次建立了连接;
2、使用accept或WSAAccept,套接字被接受后;
3、若send、WSASend 、Sendto、或WSASendTo操作失败,返回了WSAWOULDBLOCK错误,而且缓冲的窨变得可用。
The FD_WRITE network event is handled slightly differently. An FD_WRITE network event is recorded when a socket is first connected with connect/WSAConnect or accepted with accept/WSAAccept, and then after a send fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE network event setting and lasting until a send returns WSAEWOULDBLOCK. After such a failure the application will find out that sends are again possible when an FD_WRITE network event is recorded and the associated event object is set.