client_loop: send disconnect: Broken pipe_非阻塞模式下 send 和 recv 函数的返回值

我们来根据前面的讨论来总结一下 send 和 recv 函数的各种返回值意义：

返回值 n	返回值含义
大于 0	成功发送 n 个字节
0	对端关闭连接
小于 0( -1)	出错或者被信号中断或者对端 TCP 窗口太小数据发不出去(send)或者当前网卡缓冲区已无数据可收(recv)

我们来逐一介绍下这三种情况：

• 返回值大于 0

  对于 send 和 recv 函数返回值大于 0，表示发送或接收多少字节，需要注意的是，在这种情形下，我们一定要判断下 send 函数的返回值是不是我们期望发送的缓冲区长度，而不是简单判断其返回值大于 0。举个例子：

  1

  很多新手会写出上述代码，虽然返回值 n 大于 0，但是实际情形下，由于对端的 TCP 窗口可能因为缺少一部分字节就满了，所以返回值 n 的值可能在 (0, buf_length] 之间，当 0 < n < buf_length 时，虽然此时 send 函数是调用成功了，但是业务上并不算正确，因为有部分数据并没发出去。你可能在一次测试中测不出 n 不等于 buf_length 的情况，但是不代表实际中不存在。所以，建议要么认为返回值 n 等于 buf_length 才认为正确，要么在一个循环中调用 send 函数，如果数据一次性发不完，记录偏移量，下一次从偏移量处接着发，直到全部发送完为止。

1  //推荐的方式一

 1

• 返回值等于 0

  通常情况下，如果 send 或者 recv 函数返回 0，我们就认为对端关闭了连接，我们这端也关闭连接即可，这是实际开发时最常见的处理逻辑。

  但是，现在还有一种情形就是，假设调用 send 函数传递的数据长度就是 0 呢？send 函数会是什么行为？对端会 recv 到一个 0 字节的数据吗？需要强调的是，在实际开发中，你不应该让你的程序有任何机会去 send 0 字节的数据，这是一种不好的做法。 这里仅仅用于实验性讨论，我们来通过一个例子，来看下 send 一个长度为 0 的数据，send 函数的返回值是什么？对端会 recv 到 0 字节的数据吗？

  server 端代码：

 1  

上述代码侦听端口号是 3000，代码 55 行调用了 recv 函数，如果客户端一直没有数据，程序会阻塞在这里。

client 端代码：

 1

client 端连接服务器成功以后，每隔 3 秒调用 send 一次发送一个 0 字节的数据。除了先启动 server 以外，我们使用 tcpdump 抓一下经过端口 3000 上的数据包，使用如下命令：

1

然后启动 client ，我们看下结果：

客户端确实是每隔 3 秒 send 一次数据。此时我们使用 lsof -i -Pn 命令查看连接状态，也是正常的：

然后，tcpdump 抓包结果输出中，除了连接时的三次握手数据包，再也无其他数据包，也就是说，send 函数发送 0 字节数据，client 的协议栈并不会把这些数据发出去。

1[root@localhost ~]

因此，server 端也会一直没有输出，如果你用的是 gdb 启动 server，此时中断下来会发现，server 端由于没有数据会一直阻塞在 recv 函数调用处(55 行)。

上述示例再次验证了，send 一个 0 字节的数据没有任何意思，希望读者在实际开发时，避免写出这样的代码。