Java Socket 在异常后变得不可用
问题
在桌面网络应用程序中，向 DatagramSocket 发送数据时有时会发生异常：
java.net.SocketException: No buffer space available (maximum connections reached?): Datagram send failed
在此异常之后，套接字完全无法使用：它没有收到任何内容，并且 send() 无限期挂起。复制测试是一个简单的应用程序（创建套接字、绑定、while (true) send();），
当我的机器进入睡眠模式然后在中间返回时，我只能在 Windows 上 100% 的情况下重复此行为。 “密集数据流”。
问题是：
- 这种行为对于 bsd 套接字来说是正常的吗 - 发生错误后变得不可用？或者这是一种 WSA 错误？
- 有什么方法可以将故障套接字“重置”到工作状态，或者重新打开套接字是唯一的解决方案？
- 捕获异常后是否可以将此类情况与常规 I/O 错误（即可恢复错误）区分开来？
- 关于何时重新打开应用程序中的套接字，是否有任何一般性指导/建议（我的意思是：网络地址更改、PC 睡眠/唤醒和其他事件）
谢谢！ :)
Problem
In a desktop network application upon sending data to DatagramSocket sometimes the exceptiption occur:
java.net.SocketException: No buffer space available (maximum connections reached?): Datagram send failed
After this exception socket is completely unusable: it doesn't recieve anything and send() hangs indefinitely. The reproducing test is a trivial app (create socket, bind, while (true) send();)
I can repeat this behavior in 100% of cases only on Windows when my machine goes to sleep mode and then come back in a middle of "intensive data flow".
The questions are:
- is this behavior normal for bsd sockets - to get unusable after an error? or it is a kind of WSA bug?
- is there any way to "reset" faulty socket to working state or reopening socket is the only solution?
- is it possible to distinguish such conditions from regular I/O errors (i.e. recoverable ones) after catching exception?
- are there any general guidance/advices on when I shall reopen sockets in application (I mean: network address changed, PC sleep/wake-up and other events)
Thanks! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
套接字在出现任何异常（SocketTimeoutException 除外）后都将无法使用。
A socket is unusable after any exception at all with the exception of SocketTimeoutException.
我认为如果读取或写入套接字导致抛出异常，则可以安全地假设套接字不再可用。在这种情况下，您期望出现什么样的可恢复 I/O 错误？
I think it would be safe to assume that the socket is no longer usable, if reading from or writing to the socket causes an exception to be thrown. What kind of recoverable I/O errors would you expect in such a situation?