是否需要从外部取消asio::ip::tcp::resolver::async_resolve

Question

我使用函数async_resolve()

using tcp = boost::asio::ip::tcp;
namespace asio = boost::asio;

template <class Request, class Response>
class HttpsClient : public std::enable_shared_from_this<HttpsClient<Request, Response>>
{
mutable asio::io_context::strand  m_strand;
tcp::resolver                     m_resolver;
const std::string                 m_host;
const std::string                 m_service;
void doSend(Request request, Handler handler)
{
...
m_resolver.async_resolve(
m_host, m_service,
asio::bind_executor(
m_strand, std::bind(&HttpsClient::onResolve, this->shared_from_this(), _1, _2)
)
);
... 
}

void onResolve(const boost::system::error_code& ec, tcp::resolver::results_type results);

例如，我应该在某个超时后取消async_resolve()吗？我的问题是，async_resolve()是否保证在智能时间限制内返回。

Answer 1

我会有更多的高级超时，当任何DNS请求以及其他IO操作无法及时完成时，这些超时将取消。

毕竟，知道区别只是稍微有趣一点，DNS解析通常是顺序IO链中的一个步骤，它表示类似于"；查找、连接、握手、接收、回复"；。

当然，一定要记录超时的实际原因。这可以简单到：

void on_timeout(error_code ec) {
if (ec != asio::errors::operations_aborted)) {
_resolver.cancel();
_socket.cancel();
// any other parts of the highlevel IO operation that might need cancelling
}
}

operations_aborted表示取消。因此，我们检查了它，以避免在定时器本身被取消时取消其他操作(例如，在析构函数期间或设置新的过期时自然发生的情况(。

现在，您可以在各个步骤的完成处理程序中检测operations_aborted，并使用它进行适当的日志记录("on_reresol:操作已中止"(，这样您就有了信息。如果您希望在on_timeout被命中时添加一条更详细的消息，这样您就可以看到导致中止操作的其他逻辑流之间的差异。

我的问题是-async_resolve((是否保证在智能时间限制中返回

我实际上对此并不确定。以上就是原因。

假设所有DNS客户端都不可避免地会有超时，这似乎是非常合理的，因为协议是UDP，这意味着固有的易受数据包丢失的影响。不期望和处理数据包丢失是不负责任的(事实上，毫无疑问，出于同样的原因，会有"重试N次"的方法(。

我确实注意到，当DNS没有响应时，其他一些应用程序往往会停滞一段固定的时间，但我不确定是什么导致它超时。我想它可能依赖于平台。