Need cancel() on async_resolve() to callback the resolve handler immediately
Hi All, I'm looking for a solution for below problem. We're using async_resolve() to perform DNS resolution using boost::asio::ip::tcp::resolver. In few instances probably during network connectivity issues, async_resolve is taking more time. When our application timeouts in 15seconds while waiting for DNS resolution, cancel() is called on resolver. But, that doesn't callback to resolve handle immediately. When I tried to search for this, it looks like, when a cancel() is called on resolver, that doesn't cancel ongoing actual resolution but may cancel if there are any other pending asynchronous action. It's taking 40seconds at times to call resolve handler even when failed to resolve host and even after calling cancel on it. My application waits until resolve handler is called after cancel() to proceed further processing. Is it possible to stop that async_resolve() and get callback to resolve handle immediately after cancel()? If that's impossible, is there a way that we can stop that doesn't callback resolve handler later? Is it possible to close underlying socket related to async_resolve from my application? Thank you in advance. Regards, Sandeep
Hi,
Can someone please help me with this?
On Mon, Aug 23, 2021 at 7:54 PM sandeep m.v
Hi All,
I'm looking for a solution for below problem. We're using async_resolve() to perform DNS resolution using boost::asio::ip::tcp::resolver. In few instances probably during network connectivity issues, async_resolve is taking more time. When our application timeouts in 15seconds while waiting for DNS resolution, cancel() is called on resolver. But, that doesn't callback to resolve handle immediately. When I tried to search for this, it looks like, when a cancel() is called on resolver, that doesn't cancel ongoing actual resolution but may cancel if there are any other pending asynchronous action. It's taking 40seconds at times to call resolve handler even when failed to resolve host and even after calling cancel on it. My application waits until resolve handler is called after cancel() to proceed further processing. Is it possible to stop that async_resolve() and get callback to resolve handle immediately after cancel()? If that's impossible, is there a way that we can stop that doesn't callback resolve handler later? Is it possible to close underlying socket related to async_resolve from my application? Thank you in advance.
Regards, Sandeep
-- Regards, Sandeep Mob# 9000707098
On Linux async_resolve is currently implemented in terms of a spawned
thread which calls a synchronous function. It has a 30s timeout and can’t
be cancelled.
On Tue, 24 Aug 2021 at 21:56, Vinnie Falco via Boost
On Tue, Aug 24, 2021 at 12:09 PM sandeep m.v via Boost
wrote: Can someone please help me with this?
Are you by chance using Windows? What version?
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212
Thank you for the response. We build our application for multiple platforms, Windows, Linux, Android and iOS. If it is not possible to cancel, is there a way to close internal socket, so that it wont callback resolve handler? By that way, we can at least go ahead with our processing after our internal timeout assuming callback never happen later. Is that something possible? On Wed, Aug 25, 2021 at 1:29 AM Richard Hodges via Boost < boost@lists.boost.org> wrote:
On Linux async_resolve is currently implemented in terms of a spawned thread which calls a synchronous function. It has a 30s timeout and can’t be cancelled.
On Tue, 24 Aug 2021 at 21:56, Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Tue, Aug 24, 2021 at 12:09 PM sandeep m.v via Boost
wrote: Can someone please help me with this?
Are you by chance using Windows? What version?
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Regards, Sandeep Mob# 9000707098
There are a couple of convoluted ways to build cancellation into the linux
resolve() activity.
The problem is that the sockets and timers used for this are entirely
embedded in the OS-shipped library layer and not accessible to user code.
It's a bit of a mess that has never been cleaned up. There isn't much that
Asio can do about it.
At present the "cleanest" way is to fork a child process to do the resolve
call for you and async_wait on a pipe from that child. If you want to
cancel it, send the child a SIGKILL which will result in the wait on the
pipe completing with an error.
Ghastly I know...
On Wed, 25 Aug 2021 at 08:30, sandeep m.v
Thank you for the response.
We build our application for multiple platforms, Windows, Linux, Android and iOS. If it is not possible to cancel, is there a way to close internal socket, so that it wont callback resolve handler? By that way, we can at least go ahead with our processing after our internal timeout assuming callback never happen later. Is that something possible?
On Wed, Aug 25, 2021 at 1:29 AM Richard Hodges via Boost < boost@lists.boost.org> wrote:
On Linux async_resolve is currently implemented in terms of a spawned thread which calls a synchronous function. It has a 30s timeout and can’t be cancelled.
On Tue, 24 Aug 2021 at 21:56, Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Tue, Aug 24, 2021 at 12:09 PM sandeep m.v via Boost
wrote: Can someone please help me with this?
Are you by chance using Windows? What version?
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Regards, Sandeep Mob# 9000707098
On 8/25/21 11:27 AM, Richard Hodges via Boost wrote:
There are a couple of convoluted ways to build cancellation into the linux resolve() activity. The problem is that the sockets and timers used for this are entirely embedded in the OS-shipped library layer and not accessible to user code. It's a bit of a mess that has never been cleaned up. There isn't much that Asio can do about it.
At present the "cleanest" way is to fork a child process to do the resolve call for you and async_wait on a pipe from that child. If you want to cancel it, send the child a SIGKILL which will result in the wait on the pipe completing with an error.
Ghastly I know...
On Linux, there is also getaddrinfo_a: https://man7.org/linux/man-pages/man3/getaddrinfo_a.3.html which allows to perform name resolution asynchronously, with cancellation. It's a GNU extension. I wonder if it can be incorporated into Boost.ASIO. PS: Please, don't top-post.
On Wed, 25 Aug 2021 at 08:30, sandeep m.v
wrote: Thank you for the response.
We build our application for multiple platforms, Windows, Linux, Android and iOS. If it is not possible to cancel, is there a way to close internal socket, so that it wont callback resolve handler? By that way, we can at least go ahead with our processing after our internal timeout assuming callback never happen later. Is that something possible?
On Wed, Aug 25, 2021 at 1:29 AM Richard Hodges via Boost < boost@lists.boost.org> wrote:
On Linux async_resolve is currently implemented in terms of a spawned thread which calls a synchronous function. It has a 30s timeout and can’t be cancelled.
On Tue, 24 Aug 2021 at 21:56, Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Tue, Aug 24, 2021 at 12:09 PM sandeep m.v via Boost
wrote: Can someone please help me with this?
Are you by chance using Windows? What version?
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Regards, Sandeep Mob# 9000707098
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 8/25/21 1:23 PM, Andrey Semashev wrote:
On 8/25/21 11:27 AM, Richard Hodges via Boost wrote:
There are a couple of convoluted ways to build cancellation into the linux resolve() activity. The problem is that the sockets and timers used for this are entirely embedded in the OS-shipped library layer and not accessible to user code. It's a bit of a mess that has never been cleaned up. There isn't much that Asio can do about it.
At present the "cleanest" way is to fork a child process to do the resolve call for you and async_wait on a pipe from that child. If you want to cancel it, send the child a SIGKILL which will result in the wait on the pipe completing with an error.
Ghastly I know...
On Linux, there is also getaddrinfo_a:
https://man7.org/linux/man-pages/man3/getaddrinfo_a.3.html
which allows to perform name resolution asynchronously, with cancellation. It's a GNU extension. I wonder if it can be incorporated into Boost.ASIO.
It seems, it's even been suggested before: https://github.com/chriskohlhoff/asio/issues/449
At present the "cleanest" way is to fork a child process to do the resolve call for you and async_wait on a pipe from that child. If you want to cancel it, send the child a SIGKILL which will result in the wait on the pipe completing with an error.
Ghastly I know...
Here is a possible workaround that I've hacked together. Uses C++20
coroutines and latest boost.asio.
example output:
$ resolve
timeout: 1ms : exception Connection timed out
timeout: 5000ms : timeout: 5000ms : 142.250.184.14:80,
[2a00:1450:4003:80f::200e]:80
timeout: 20000ms : timeout: 20000ms : 142.250.184.14:80,
[2a00:1450:4003:80f::200e]:80
Here's the code:
//
// Copyright (c) 2021 Richard Hodges (hodges.r@gmail.com)
//
// Distributed under the Boost Software License, Version 1.0. (See
accompanying
// file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
//
//
#include
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Andrey Semashev
-
Richard Hodges
-
sandeep m.v
-
Vinnie Falco