相关疑难解决方法(0)

你如何使套接字无阻塞？

我知道这个fcntl()功能,但我听说它并不总是可靠的.

你能解释一下究竟是什么SO_SNDBUF和SO_RECVBUF选择吗？

好的,由于某种原因,操作系统会缓冲输出/输入数据,但我想澄清这个问题.

他们的角色(一般)是什么？

它们是每插槽缓冲区吗？

传输层的缓冲区(例如TCP缓冲区)和这些缓冲区之间是否存在连接？

使用流套接字(TCP)和使用无连接套接字(UDP)时,它们是否具有不同的行为/角色？

一篇好文章也会很棒.

我搜索了它,但没有找到任何有用的信息.

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

非阻塞套接字是我们调用fcntl()方法并将O_NONBLOCK标志与其关联的套接字.任何人都可以告诉我将普通TCP_IP套接字转换为非阻塞套接字还需要什么？

如果非阻塞套接字可以与Windows服务器一起使用,可能会出现什么问题？