为什么假设send可能返回的数据少于在阻塞套接字上传输的请求数据？

Question

在流套接字上发送数据的标准方法一直是调用send和一大块数据来写,检查返回值以查看是否所有数据都已发送,然后再次调用send直到整个消息被接受为止.

例如,这是一个常见方案的简单示例:

int send_all(int sock, unsigned char *buffer, int len) {
  int nsent;

  while(len > 0) {
    nsent = send(sock, buffer, len, 0);
    if(nsent == -1) // error
      return -1;

    buffer += nsent;
    len -= nsent;
  }
  return 0; // ok, all data sent
}

甚至BSD手册也提到了这一点

...如果套接字上没有可用的消息空间来保存要传输的消息,则send()通常会阻塞 ...

这表明我们应该假设send可以在不发送所有数据的情况下返回.现在我发现这个相当破碎,但即使是W. Richard Stevens在他的标准参考书中假定这是关于网络编程的,而不是在开头的章节中,但更高级的例子使用他自己的写(写所有数据)函数而不是调用write.

现在我认为这仍然或多或少被破坏,因为如果send无法传输所有数据或接受底层缓冲区中的数据并且套接字阻塞,则send应该阻塞并在整个发送请求被接受时返回.

我的意思是,在上面的代码示例中,如果send返回的数据发送的数量较少,那么将使用新请求再次调用它.自上次通话以来有什么变化？最多几百个CPU周期已经过去,因此缓冲区仍然是满的.如果发送现在接受数据,为什么它不能接受它？

否则我们将以低效循环结束upp,我们试图在无法接受数据并继续尝试的套接字上发送数据,否则？

因此,如果需要,似乎解决方法会导致代码效率极低,并且在这些情况下应该避免阻塞套接字,而应该使用非阻塞套接字和select.

Answer 1

上面描述中缺少的是,在Unix中,系统调用可能会被信号中断.这正是阻塞send(2)可能会返回短数的原因.