EAGAIN 错误：使用 Berkeley Socket API
有时，当我尝试连续发送一些数据包（我正在使用 send() API）时，我会收到此错误。现在我不知道我应该做什么。我有这些问题： 1) 我可以重新发送吗？如果是，那么我应该在多长时间后重试。是否有任何特定的策略需要遵循
2) 缓冲区大小超出其限制是唯一的原因吗？
3）有人可以给我一个更好的想法/代码，如何处理这种情况。
谢谢。 桑比特。
Sometimes when I try to send some packets continuously( I am using the send() API ) I receive this error. Now I am not sure what should I do than. I have these questions:
1) Can I re-send again ? If yes then after how much time should I try again. Is there any particular strategy to be followed
2) Is buffer size has exceeded its limits is the only reason ?
3) Can someone please give me a better idea/code, how to handle such scenario.
Thanks.
Sambit.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
来自send()：“EAGAIN——套接字被标记为非阻塞并且请求的操作将被阻止。” 当消息无法放入套接字的发送缓冲区时
此线程有一个简单的示例使用 select() 来处理 EAGAIN，接下来是关于隐藏在表面之下的各种惊喜的重要讨论。
From send(): "EAGAIN -- The socket is marked non-blocking and the requested operation would block." and also
This thread has a simple example of using select() to deal with EAGAIN, and is followed by significant discussion about what sorts of surprises lurk beneath the surface.
当没有剩余出站缓冲区空间时，通常会返回 EAGAIN。等待多长时间取决于底层连接的速度。正常的方法是等到 select() 或 poll() 告诉您套接字可用于写入。如果在 Linux 上，请查看 select_tut(2) 联机帮助页，当然还有 send(2) 联机帮助页。
如果您希望调用等待直到有可用空间，您可以更改为阻塞操作（这是默认设置）。或者您可以调用 select(2) 等待套接字可写，然后重试。
还有另一个重要的考虑因素。如果您发送 UDP 数据包，请记住，无法保证拥塞控制，并且如果您通过 Internet 发送数据包，如果您只是尝试尽快发送 UDP 数据包，那么几乎肯定会出现数据包丢失（这不一定适用于其他数据报套接字，例如 Unix 套接字）。
EAGAIN is usually returned when there is no outbound buffer space left. How long to wait depends on the speed of the underlying connection. The normal way is to wait until select() or poll() tells you that the socket is available for writing. If on Linux, take a look at the select_tut(2) manpage, and of course the send(2) manpage.
You could change to blocking operation (which is the default) if you want the call to wait until there is space available. Or you could call select(2) to wait until the socket is writeable and then try again.
There is one other important consideration. If you are sending UDP packets, then keep in mind that there is no guarantee of congestion control, and if you're sending packets over the Internet you will almost certainly get packet loss if you just try sending UDP packets as fast as possible (this doesn't necessarily apply to other datagram sockets such as Unix sockets).