相关疑难解决方法(0)

1. 我们可以在同一个套接字上调用一个线程的发送和另一个线程的recv吗？
2. 我们可以从同一个套接字上的不同线程并行调用多个发送吗？

我知道一个好的设计应该避免这种情况,但我不清楚这些系统API将如何表现.我也找不到相同的好文档.

方向上的任何指针都会有所帮助.

在流套接字上发送数据的标准方法一直是调用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.