Bug #2459
open
ndn-autoconfig (daemon mode): non-deterministic timeouts for DNS resolution
Added by Alex Afanasyev almost 10 years ago.
Updated over 7 years ago.
Description
The current implementation of ndn-autoconf uses res_query and res_search methods that block thread execution for an unknown (potentially long) amount of time. If machine has connectivity to DNS servers, then there is no problem. I tested on my machine when I disconnected from the network and I couldn't quite get how long should I wait till the function actually finishes...
The issue needs to be resolved in some way.
- Related to Feature #2417: tool/daemon to re-run ndn-autoconf when connectivity changes added
- Subject changed from ndn-autoconfg (daemon mode) Non-deterministic timeouts for DNS resolution to ndn-autoconfig (daemon mode): non-deterministic timeouts for DNS resolution
- Description updated (diff)
I saw that post, but changing parameters in _res doesn't seem to improve much (may be it improved, but it still took too long).
We can check libasyncns.
- Has duplicate Bug #2467: HUB discovery scenario: does not terminate after 30 minutes added
- Has duplicate deleted (Bug #2467: HUB discovery scenario: does not terminate after 30 minutes)
- Target version deleted (
v0.4)
- Start date deleted (
01/31/2015)
Chromium uses a worker thread to do DNS resolution:
Since some DNS resolutions can take a long time, it is paramount that such delays in one resolution should not cause delays in other resolutions. Toward this end (on Windows, where there is no native support for asynchronous DNS resolution), Chromium currently employs 8 completely asynchronous worker threads to do nothing but perform DNS prefetch resolution. Each worker thread simply waits on a queue, gets the next requested domain name, and then blocks on a synchronous Windows resolution function. Eventually the operating system responds with a DNS resolution, the thread then discards it (leaving the OS cache warmed!), and waits for the next prefetch request. With 8 threads, it is rare than more than one or two threads will block extensively, and most resolution proceed rather quickly (or as quickly as DNS can service them!). On Debug builds, the "about:histograms/DNS.PrefetchQueue" has current stats on the queueing delay.
Source code indicates this applies to not only Windows but also POSIX systems.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by