Tag: 编码式

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

在流套接字上发送数据的标准方法一直是调用send和一大块数据进行写入，检查返回值以查看是否所有数据都已发送，然后再次调用send直到整个消息被接受为止。 例如，这是一个常见方案的简单示例： int send_all（int sock，unsigned char * buffer，int len）{ 不存在 while（len> 0）{ nsent = send（sock，buffer，len，0）; if（nsent == -1）//错误 返回-1; buffer + = nsent; len – = nsent; } 返回0; //好的，发送了所有数据 } 甚至BSD手册也提到了这一点 …如果套接字上没有可用的消息空间来保存要传输的消息，则send（） 通常会阻塞 … 这表明我们应该假设send可以在不发送所有数据的情况下返回。 现在我发现这个相当破碎，但即使是W. Richard Stevens在他的标准参考书中假定这是关于网络编程的 ，而不是在开头的章节中，但更高级的例子使用他自己的写（写所有数据）函数而不是调用write。 现在我认为这仍然或多或少地被破坏，因为如果send无法传输所有数据或接受底层缓冲区中的数据并且套接字阻塞，则send应该阻塞并在整个发送请求被接受时返回。 我的意思是，在上面的代码示例中，如果发送返回的数据发送的数量较少，将会发生的情况是，将使用新请求再次调用它。 自上次通话以来有什么变化？ 最多几百个CPU周期已经过去，因此缓冲区仍然是满的。 如果发送现在接受数据，为什么它不能接受它？ 否则，我们将以低效循环结束upp，我们试图在无法接受数据并继续尝试的套接字上发送数据，否则？ 因此，如果需要，似乎解决方法会导致代码效率极低，在这种情况下，应该避免阻塞套接字，而应该使用非阻塞套接字和select。