WSAEWOULDBLOCK send 出错（转）

今天有朋友问我关于 Winsock 发送数据出错的问题，错误代码为 WSAEWOULDBLOCK。而刚好以前自己也遇到过这个问题，也研究过一下发生的原因，所以很顺利的帮朋友解决了问题，但由于自己语言表达能力太弱，所以干脆把原因分析写下来：“关于 Winsock Send 无法完成，返回 WSAEWOULDBLOCK 的原因分析和解决方法”，如下：

首先，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.