地址已与 boost asio 接受器一起使用
我编写了一个服务器，用于侦听传入的 TCP 连接和连接到它的客户端。当我关闭服务器并在同一端口上重新启动它时，有时在调用 bind(...) 时会收到错误消息 EADDRINUSE（在 Linux 上错误代码：98）。即使我设置了重用套接字的选项，也会发生这种情况。
该错误并非总是发生，但当客户端连接到服务器并在服务器关闭时发送数据时，它似乎更频繁地发生。我想问题是服务器关闭时仍然有挂起的连接（相关主题：https://stackoverflow.com/questions/41602/how-to-forcously-close-a-socket-in-time-wait）。
在服务器端，我使用 boost::asio::ip::tcp::acceptor。我使用选项“reuse_address”对其进行初始化（请参阅 http://beta.boost.org/doc/libs/1_38_0/doc/html/boost_asio/reference/basic_socket_acceptor.html）。这是代码片段：
using boost::asio::ip::tcp;
acceptor acceptor::acceptor(io_service);
endpoint ep(ip::tcp::v4(), port);
acceptor.open(ep.protocol());
acceptor.set_option(acceptor::reuse_address(true));
acceptor.bind(ep);
acceptor.listen();
接受器关闭于：
acceptor.close();
在此之前我也尝试过使用acceptor.cancel()，但它具有相同的效果。发生此错误时，我在相当长的一段时间内无法在同一端口上重新启动服务器。重新启动网络会有所帮助，但不是永久解决方案。
我缺少什么？
任何帮助将不胜感激！ :)
I wrote a server that is listening for incomming TCP connections and clients connecting to it. When I shut down the server and restart it on the same port, I sometimes get the error message EADDRINUSE when calling bind(...) (error code: 98 on Linux). This happens even though I am setting the option to reuse the socket.
The error does not happen all the time, but it seems that it happens more often when clients are connected to the server and sending data while it shuts down. I guess the problem is that there are still pending connections while the server is shut down (related topic: https://stackoverflow.com/questions/41602/how-to-forcibly-close-a-socket-in-time-wait).
On the server side, I am using boost::asio::ip::tcp::acceptor. I initialize it with the option "reuse_address" (see http://beta.boost.org/doc/libs/1_38_0/doc/html/boost_asio/reference/basic_socket_acceptor.html). Here is the code snippet:
using boost::asio::ip::tcp;
acceptor acceptor::acceptor(io_service);
endpoint ep(ip::tcp::v4(), port);
acceptor.open(ep.protocol());
acceptor.set_option(acceptor::reuse_address(true));
acceptor.bind(ep);
acceptor.listen();
The acceptor is closed with:
acceptor.close();
I also tried using acceptor.cancel() before that, but it had the same effect. When this error occurred, I cannot restart the server on the same port for quite some time. Restarting the network helps, but is not a permanent solution.
What am I missing?
Any help would be greatly appreciated! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这些最初是对问题的评论。
您的服务器是否分叉子进程？另外，您确定套接字处于 TIME_WAIT 状态吗？发生这种情况时，您可能需要获取
netstat -ap输出These were originally a comment to the question.
does your server fork child processes? Also, are you sure the socket is in TIME_WAIT state? You might want to grab the
netstat -apoutput when this happens当你“用武力”解决这些问题时，似乎你是在把问题归咎于你，不是吗？
默认行为要求您等待是有原因的，否则网络可能会将前一个连接的 ACK 与新连接的 ACK 混淆。
我不会允许这个“解决方案”包含在我的团队的发布版本中。
请记住，当错误概率非常低时，测试就极其困难！
When you solve these problems "by force", it seems you are calling problems on your head, do not you?
There is a reason the default behavior requires you to wait, otherwise the network could for example confuse the ACK from the previous connection to be ACK for the new connection.
I would not allow this "solution" to be included in release builds in my team.
Remember, when the probability of error is very low, testing is extremely difficult!