Bug #2459
open
ndn-autoconfig (daemon mode): non-deterministic timeouts for DNS resolution
0%
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.
Updated by Alex Afanasyev almost 10 years ago
- Related to Feature #2417: tool/daemon to re-run ndn-autoconf when connectivity changes added
Updated by Davide Pesavento almost 10 years ago
- 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)
Not sure if OSX-specific, but see http://lists.apple.com/archives/darwin-development/2004/Apr/msg00022.html
Otherwise, perform the DNS resolution in a separate thread. Or use an async wrapper such as libasyncns.
Updated by Alex Afanasyev almost 10 years ago
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.
Updated by Alex Afanasyev almost 10 years ago
- Has duplicate Bug #2467: HUB discovery scenario: does not terminate after 30 minutes added
Updated by Alex Afanasyev almost 10 years ago
- Has duplicate deleted (Bug #2467: HUB discovery scenario: does not terminate after 30 minutes)
Updated by Davide Pesavento over 8 years ago
- Target version deleted (
v0.4) - Start date deleted (
01/31/2015)
Updated by Junxiao Shi over 7 years ago
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.