相关疑难解决方法(0)

确切地说,BSD套接字send()函数何时返回给调用者？

在非阻塞模式下,它应该立即返回,对吗？

至于阻止模式,手册页说:

当消息不适合套接字的发送缓冲区时,send()通常会阻塞,除非套接字已置于非阻塞I/O模式.

问题:

1. 这是否意味着send()如果内核发送缓冲区中有空间,则调用将始终立即返回？
2. send()TCP和UDP 的呼叫行为和性能是否相同？如果没有,为什么不呢？

非阻塞套接字的手册页中详细记录了两个案例:

• 如果send()返回与传输缓冲区相同的长度,则整个传输成功完成,并且套接字可能处于或不处于返回EAGAIN/EWOULDBLOCK的状态,下一次调用> 0字节进行传输.
• 如果send()返回-1并且errno是EAGAIN/EWOULDBLOCK,则没有传输完成,并且程序需要等到套接字准备好接收更多数据(epoll情况下的EPOLLOUT).

没有记录的非阻塞套接字是:

• 如果send()返回一个小于缓冲区大小的正值.

是否可以安全地假设send()甚至会在一个字节的数据上返回EAGAIN/EWOULDBLOCK？或者,非阻塞程序是否应该再次发送()以获得结论性的EAGAIN/EWOULDBLOCK？我担心在插座上放一个EPOLLOUT观察器,如果它实际上没有处于"阻塞"状态以响应它的出现.

显然,后一种策略(再次尝试获得某种结论)具有明确定义的行为,但它更加冗长并且会对性能产生影响.

我正在尝试学习如何使用epoll()TCP 服务器应用程序，因为我期望有很多连接。

我尝试检查示例和教程，他们总是建议使用/设置添加epoll()为非阻塞套接字的套接字。

为什么？