asio::ip::tcp::resolver::async_resolve 是否需要外部取消？答案

【问题标题】：Does asio::ip::tcp::resolver::async_resolve need to be external canceled?asio::ip::tcp::resolver::async_resolve 是否需要外部取消？
【发布时间】：2020-10-20 12:46:44
【问题描述】：

我使用函数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() 是否提供任何保证以在智能时间限制内返回。

【问题讨论】：

标签： c++ c++11 network-programming boost-asio

【解决方案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_resolve：操作中止”），以便您获得信息。如果您希望在on_timeout 被击中时添加更详细的消息，以便您可以看到导致操作中止的其他逻辑流之间的差异。

我的问题是 - async_resolve() 是否提供任何保证以在智能时间限制内返回

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

假设所有 DNS 客户端都不可避免地存在超时似乎很合理，因为协议是 UDP，这意味着天生就容易丢包。不期待和处理丢包是不负责任的（事实上，出于同样的原因，毫无疑问会有“重试 N 次”的方法）。

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

【讨论】：