sockets - 有人可以给我一个关于非阻塞套接字的 'send'行为的很好的解释吗？

Question

我现在至少阅读了10次文档，并且还阅读了大约10左右的代码片段和完整程序，其中使用了非阻塞套接字来发送数据。问题在于某些教程要么是针对初学者的(Beejs f.i.)，要么是假定他们的草率。那些不复杂的是专门的代码示例，这些示例不解释为什么要这样做。在我看来，即使是SO知识库也不能完全涵盖send行为的全部范围。我所追求的是关于fee的详细信息:

返回代码0确切表示什么，那么是否值得检查errno？还是应该不经进一步调查就丢弃该连接？

获得负返回值是否需要关闭连接就坏了，还是只有这样，除非errno是EWOULDBLOCK，EAGAIN或EINTR(... others)？

如果返回值为errno，是否值得检查> 0？显然，该值指示“已发送”的数据量(用引号表示，因为这确实是一个漫长的过程，对)，但是由于套接字是非阻塞的，这是否意味着可以立即发出另一个调用，或者再次取决于errno ，应该等待下一次发送机会(使用select/poll/epoll)吗？

基本上，有人先检查返回值，然后才检查errno值吗？还是send在每次调用时设置errno，无论返回值如何？这会使错误检查变得更容易...

如果有人获得EINTR，那么程序要采取的一种良好而健壮的行为是什么？只需记录状态并在下一次发送时重试，例如EWOULDBLOCK和EAGAIN？

是否同时检查EWOULDBLOCK和EAGAIN？我们可以相信两者具有相同的值(value)，还是取决于实现方式？

send是否为流套接字返回EMSGSIZE？如果不是，则缓冲区大小不会太大，对吗？

返回值本身可以等于两个已知的错误代码吗？

如果您可以提供一个健壮的非阻塞发送代码的示例，那将是不胜感激的。

Answer 1

这里有很多问题:

• What does return code of 0 indicate exactly, and is it worth checking errno then or should one just discard the connection without further investigation?

在POSIX系统上，send(2)永远不会返回0，除非您使用长度为arg的0对其进行调用。检查特定系统的文档以确保其遵循POSIX规范

• Does getting a negative return value warrant closing a connection gone bad, or is it only so unless errno is EWOULDBLOCK, EAGAIN or EINTR (...others) ?

不，返回值为-1(唯一可能的负返回值)仅表示未发送任何数据。您需要检查errno才能查看为什么-请参见send(2)手册页，以获取所有可能的errno值及其含义的完整列表。

• Is it worth checking errno when return value is > 0 ? Apparently, the value indicates amount of data "sent" (in quotes because it's a long process really, right), but since the socket is non-blocking, does it mean one can issue another call right away, or, depending on errno again, one should wait for the next sending occasion (using select/poll/epoll) ?

如果send返回成功(> 0)，则errno将保持不变，并将包含以前的内容(这可能是某些较早的系统调用产生的错误)。

• Basically, does one check the return value first and only then the errno value? Or maybe send sets errno on each call, return value regardless? That would make error checking somewhat easier...

首先检查返回值，如果返回值为-1，则检查errno。如果确实需要，可以在调用之前将errno设置为0，然后再进行检查。

• If one gets EINTR, what would be a good, robust behavior for a program to take? Simply record the state and retry on next send occasion, like with EWOULDBLOCK and EAGAIN?

好吧，最简单的方法是禁用系统调用的中断，在这种情况下，您将永远无法获得EINTR。将其与EWOULDBLOCK/EAGAIN一样对待也是很好的。

• Does one check for both EWOULDBLOCK and EAGAIN? Can we trust both having the same value, or does it depend on the implementation?

取决于实现，尽管通常它们是相同的。有时SysV vs BSD仿真模式有些奇怪，这可能会使它们有所不同，并且两种情况都可能发生

• Does send return EMSGSIZE for stream sockets? If it doesn't, then no buffer size is too big, right?

流套接字没有原子消息，而EMSGSIZE仅用于原子消息，因此不，流套接字不能返回EMSGSIZE

• Can return value itself be equal to either of the known error codes?

唯一的错误代码是-1。成功是写入的字节数，因此，如果您可以在32位计算机上写入2 ^ 32-1字节(或在64位计算机上写入2 ^ 64-1)，则可能会出现问题，但是您不能写那么多字节(如果尝试，通常会得到EINVAL或EFAULT)。