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() 是否在智能时间限制中向 return 提供任何保证。

Answer 1

我会有更多 high-level 超时，当它们未能及时完成时，将取消任何 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 被命中时添加更详细的消息，以便您可以看到导致操作中止的其他逻辑流之间的区别。

My question is - does async_resolve() give any guaranties to return in smart time limitations

我真的不确定。以上就是原因。

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

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

asio::ip::tcp::resolver::async_resolve需要外部注销吗？

Does asio::ip::tcp::resolver::async_resolve need to be external canceled?

c++

network-programming

boost-asio

c++11