Re: Name lookup/DNS resolution mechanism of libcurl
Am 2013-04-10 23:06, schrieb Daniel Stenberg: On Wed, 10 Apr 2013, Michael-O wrote: Add an alias for ENABLE_THREADS_WIN32 as ENABLE_ASYNC_DNS if this define is for DNS only. Threads win22 says absolutely nothing at least to me. We have two different ways to provide asynchronous DNS! Threads and c-ares. My bad, sorry. I was too shortsighted. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Günter, Am 2013-04-11 14:24, schrieb Guenter: Hi Mike, On 10.04.2013 21:54, Michael-O wrote: I strongly support this approach because its clear and makes everything explicit. I would even go one step further: Add an alias for ENABLE_THREADS_WIN32 as ENABLE_ASYNC_DNS if this define is for DNS only. Threads win22 says absolutely nothing at least to me. Compile commands could be: mingw32-make mingw32-(ares|adyn|sdyn|dyn) where dyn == adyn. This would be fully backward compatible, right? no; dyn is already used to build with dynamic linking (wasnt my idea but historically already in this makefile when I entered this project); the default build is therefore a static linking of curl. ironicGreat that all these parameters well documented.../ironic I've just commited a patch which makes it now possible to build all resolver flavours without further hacking: http://svwe10.itex.at/cgit/cgit.cgi/curl.git/commit/?id=96ffe645fd2494f14780f7c105fcfeeb8ca7d94f mingw32-make mingw32-sync -- builds with synchronous resolver mingw32-make mingw32-ares -- builds with ares asynchronous resolver mingw32-make mingw32 -- builds with win32 asynchronous resolver of course feel free to use: mingw32-make mingw32-async -- builds with win32 asynchronous resolver because all options not recognized are silently ignored ... :-P I think it would make the issue a lot clearer if they would be named: - syncdns - aresdns - asyncdns Referring to my comment above. in addition I've commited another small fix for the c-ares MinGW makefile in order to automatically create ares_build.h when building from Git: http://svwe10.itex.at/cgit/cgit.cgi/c-ares.git/commit/?id=2004a7a1115e25128170e40470eba8603f7080da please test if you have some cpu cycles ... Tests will follow... Michael --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Günter, Am 2013-04-11 14:24, schrieb Guenter: [..] in addition I've commited another small fix for the c-ares MinGW makefile in order to automatically create ares_build.h when building from Git: http://svwe10.itex.at/cgit/cgit.cgi/c-ares.git/commit/?id=2004a7a1115e25128170e40470eba8603f7080da please test if you have some cpu cycles ... Did you actually see my last mail [1] with tests? Now, I have cloned from Git. c-ares compiles fine. I have compiled plain (lib)curl in three runs with ares, async and sync. Virtual Box adapter has been enabled for testing. ares: name resolution works flawlessly and fast async: horribly slow as before sync: even faster than ares This makes me think, either the adapter is seriously broken or there is some defect with the asynchronous resolution. Any ideas? Btw: I have linked dynamically. Static linking can be tested upon request. Mike [1] http://curl.haxx.se/mail/lib-2013-04/0150.html --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
On Fri, 12 Apr 2013, Michael-O wrote: ares: name resolution works flawlessly and fast async: horribly slow as before Please don't call the threaded resolver backend the async one, as the c-ares one is async as well. If the threaded resolver is slow it sounds like something is wrong since I really can't see how it should be notable slower than the stock sync one. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Mike, On 10.04.2013 21:54, Michael-O wrote: I strongly support this approach because its clear and makes everything explicit. I would even go one step further: Add an alias for ENABLE_THREADS_WIN32 as ENABLE_ASYNC_DNS if this define is for DNS only. Threads win22 says absolutely nothing at least to me. Compile commands could be: mingw32-make mingw32-(ares|adyn|sdyn|dyn) where dyn == adyn. This would be fully backward compatible, right? no; dyn is already used to build with dynamic linking (wasnt my idea but historically already in this makefile when I entered this project); the default build is therefore a static linking of curl. I've just commited a patch which makes it now possible to build all resolver flavours without further hacking: http://svwe10.itex.at/cgit/cgit.cgi/curl.git/commit/?id=96ffe645fd2494f14780f7c105fcfeeb8ca7d94f mingw32-make mingw32-sync -- builds with synchronous resolver mingw32-make mingw32-ares -- builds with ares asynchronous resolver mingw32-make mingw32 -- builds with win32 asynchronous resolver of course feel free to use: mingw32-make mingw32-async -- builds with win32 asynchronous resolver because all options not recognized are silently ignored ... :-P in addition I've commited another small fix for the c-ares MinGW makefile in order to automatically create ares_build.h when building from Git: http://svwe10.itex.at/cgit/cgit.cgi/c-ares.git/commit/?id=2004a7a1115e25128170e40470eba8603f7080da please test if you have some cpu cycles ... Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Guenter li...@gknw.net wrote: How can USE_THREADS_WIN32 both be defined and set to 0? The USE_THREADS_WIN32 == 0 part is superfluous AFAICS. well, simply by -DUSE_THREADS_WIN32=0 ... I think you know I already knew that. Just that it's highly suspicious that it was needed. I forgot the reason behind this and possibly in some time, nobody will understand the historic reason. honestly I'm not happy with that hack, and if someone has something better in mind please speak up! Me neither. That's why I reacted on this tree-state logic. --gv --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
hi Gisle, On 10.04.2013 12:37, Gisle Vanem wrote: Guenter li...@gknw.net wrote: How can USE_THREADS_WIN32 both be defined and set to 0? The USE_THREADS_WIN32 == 0 part is superfluous AFAICS. well, simply by -DUSE_THREADS_WIN32=0 ... I think you know I already knew that. sorry; I didnt think further about, but that was just the answer to your question as I understood it; and to be 100% sure I quickly checked it with the test sample ... also I wouldnt be much surprised if the test sample would give other results with other preprocessors than the one from gcc ... Just that it's highly suspicious that it was needed. I forgot the reason behind this and possibly in some time, nobody will understand the historic reason. honestly I'm not happy with that hack, and if someone has something better in mind please speak up! Me neither. That's why I reacted on this tree-state logic. lets 1st get the pending release out of the door; the current 'logic' seems at least to work better than what we had before; and after the release we should check for a better solution like Yang suggested - but that would then cause to modify all Windows static makefiles, and a bunch of testing would then be required too (for which I have not the time ATM). Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Am 2013-04-09 21:10, schrieb Guenter: Hi Mike, On 09.04.2013 20:46, Michael-O wrote: Am 2013-04-09 20:31, schrieb Guenter: yes, today commited two patches - one for curl and one for c-ares ... Do you want to to clone from Git and test it? sure, that would be great! But remember that Daniel might at any time tag and release ... so only a short while for last-minute hot-fixes :-P Hi Günter, I don't mind have them in 7.30.1 as long as (lib)curl gets improved. I have checkws the github diffs which are very simple. Now here are my results, I make several compilation runs. In all cases, I compiled c-ares one with MinGW which ran flawlessly. 1. Plain vanilla curl with - Added #define HTTP_ONLY in lib\config-win32.h set LIBCARES_PATH=D:\Projekte\c-ares-master mingw32-make mingw32-winssl-ares src\curl --version curl 7.30.0-DEV (i386-pc-win32) libcurl/7.30.0-DEV WinSSL c-ares/1.10.0-DEV Protocols: http https Features: AsynchDNS GSS-Negotiate Largefile NTLM SSL SSPI Compiles fine. 2. Plain vanilla curl with - Added #define HTTP_ONLY in lib\config-win32.h - LIBCARES_PATH changed directly in Makefile.m32 mingw32-make mingw32-winssl-ares mingw32-make[1]: *** No rule to make target '../ares/libcares.a', needed by 'curl.exe'. Stop. mingw32-make[1]: Leaving directory 'D:/Projekte/curl-master/src' Makefile:87: recipe for target 'mingw32-winssl-ares' failed mingw32-make: *** [mingw32-winssl-ares] Error 2 For some reason, make does not realize that LIBCARES_PATH has been changed internally. So I continued with solution 1 for further testing. Now I tried to compile my simple C file against that libcurl dynamically: gcc -LD:\\Projekte\\curl-master\\lib -o curlsimple.exe curlsimple.o -lcurldll I presume that curldll is statically linked against libcares, thus includes it. enabled VirtualBox Host-only Adapter and chaged PATH accordingly curlsimple http://curl.haxx.se Provided URL: http://curl.haxx.se % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 11444 100 114440 0 73358 0 --:--:-- --:--:-- --:--:-- 73358 Name lookup time: 0.031000 s Connect time: 0.047000 s Pretransfer time: 0.00 s start transfer time: 0.062000 s Total time: 0.156000 s Perfect! c-ares does not suffer from this problem. What I haven't tried: 1. Link statically against libcurl 2. Enable and compile other protocols only 3. Enable sync DNS resolver Are you interested in these results too? Grüße aus Berlin, Michael --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Am 2013-04-10 04:40, schrieb Yang Tse: Hi Gün, On Wed, Apr 10, 2013, Guenter li...@gknw.net wrote: honestly I'm not happy with that hack, and if someone has something better in mind please speak up! Modify Makefile.m32 in order to make it define one out of three possibilities ENABLE_ARES, ENABLE_SYNC_DNS or ENABLE_THREADS_WIN32. Modify config-win32.h in a way such that when above mentioned macros are defined config-win32.h defines appropriate USE_ARES, USE_THREADS_WIN32 or none of these two. This decoupling should also allow to retain default and previous behaviour of config-win32.h I strongly support this approach because its clear and makes everything explicit. I would even go one step further: Add an alias for ENABLE_THREADS_WIN32 as ENABLE_ASYNC_DNS if this define is for DNS only. Threads win22 says absolutely nothing at least to me. Compile commands could be: mingw32-make mingw32-(ares|adyn|sdyn|dyn) where dyn == adyn. This would be fully backward compatible, right? Mike --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
On Wed, 10 Apr 2013, Michael-O wrote: Add an alias for ENABLE_THREADS_WIN32 as ENABLE_ASYNC_DNS if this define is for DNS only. Threads win22 says absolutely nothing at least to me. We have two different ways to provide asynchronous DNS! Threads and c-ares. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Am 2013-04-02 00:43, schrieb Guenter: Hi Michael, On 01.04.2013 23:24, Michael-O wrote: Am 2013-04-01 22:52, schrieb Guenter: 1st we need to know if this is also an issue with the default windows resolver; so have you also tested with a non-c-ares build? If it only occures with c-ares then this is only an issue with this lib, but not with libcurl. How can I know? I have compiled plain vanilla with mingw. I presume that Features: AsynchDNS is standard windows resolver. That's what Daniel wrote as first reply. yep; somehow I must have mixed this up with c-ares, sorry about! Was probably because Gisle wrote about c-ares; but again: I mixed things up! I have built now c-ares 1.9.1 with 'mingw32-make -f Makefile.m32' and tried to compile curl against it: 1. Added #define HTTP_ONLY and uncommented #define USE_ARES in config-win32.h 2. Set LIBCARES_PATH=E:\Downloads\c-ares-1.9.1 3. Finally compiled curl with mingw32-make mingw32-winssl-ares But the linking fails with: [snip] What now? oh! seems that c-ares is build static only while libcurl tries to link the dynamic one; I will look into this; probably something wrong with the makefiles Günter, were you able to look at the Makefiles of c-ares and curl? Mike --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Mike, On 09.04.2013 20:01, Michael-O wrote: Günter, were you able to look at the Makefiles of c-ares and curl? yes, today commited two patches - one for curl and one for c-ares ... Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Am 2013-04-09 20:31, schrieb Guenter: Hi Mike, On 09.04.2013 20:01, Michael-O wrote: Günter, were you able to look at the Makefiles of c-ares and curl? yes, today commited two patches - one for curl and one for c-ares ... Do you want to to clone from Git and test it? --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Mike, On 09.04.2013 20:46, Michael-O wrote: Am 2013-04-09 20:31, schrieb Guenter: yes, today commited two patches - one for curl and one for c-ares ... Do you want to to clone from Git and test it? sure, that would be great! But remember that Daniel might at any time tag and release ... so only a short while for last-minute hot-fixes :-P the fixes are trivial: http://svwe10.itex.at/cgit/cgit.cgi/c-ares.git/commit/?id=c95041c6a1dcbd1882711a6551f957dd15f026f7 and: http://svwe10.itex.at/cgit/cgit.cgi/curl.git/commit/?id=658ec97055456f739222aa2a5719a4d403ced99a Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
On Tue, 9 Apr 2013, Guenter wrote: But remember that Daniel might at any time tag and release ... so only a short while for last-minute hot-fixes :-P EXactly. Please be careful with last-minute pushes now. My plan is to release what's HEAD in git in 14-15 hours or so. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Guenter li...@gknw.net wrote: On 09.04.2013 20:01, Michael-O wrote: Günter, were you able to look at the Makefiles of c-ares and curl? yes, today commited two patches - one for curl and one for c-ares ... Thanks for fixing this. I wrote about this in this thread: http://curl.haxx.se/mail/lib-2013-01/0131.html earlier this year. Your patch below looks good here. Except: +#if !defined(USE_ARES) !defined(USE_THREADS_WIN32) # define USE_THREADS_WIN32 1 +#elif defined(USE_THREADS_WIN32) USE_THREADS_WIN32 == 0 +# undef USE_THREADS_WIN32 #endif How can USE_THREADS_WIN32 both be defined and set to 0? The USE_THREADS_WIN32 == 0 part is superfluous AFAICS. --gv --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Gisle,
On 10.04.2013 00:07, Gisle Vanem wrote:
Thanks for fixing this. I wrote about this in this thread:
http://curl.haxx.se/mail/lib-2013-01/0131.html
earlier this year. Your patch below looks good here.
Except:
+#if !defined(USE_ARES) !defined(USE_THREADS_WIN32)
# define USE_THREADS_WIN32 1
+#elif defined(USE_THREADS_WIN32) USE_THREADS_WIN32 == 0
+# undef USE_THREADS_WIN32
#endif
How can USE_THREADS_WIN32 both be defined and set to 0?
The USE_THREADS_WIN32 == 0 part is superfluous AFAICS.
well, simply by -DUSE_THREADS_WIN32=0 ...
try this:
#include stdio.h
int main() {
#if !defined(TEST)
printf(TEST: undefined\n);
#else
printf(TEST: defined\n);
#if TEST = 0
printf(TEST: %d\n, TEST);
#endif
#endif
return 0;
}
gcc -Wall -O2 tdef.c -o tdef ; ./tdef
TEST: undefined
gcc -Wall -O2 -DTEST tdef.c -o tdef ; ./tdef
TEST: defined
TEST: 1
gcc -Wall -O2 -DTEST=0 tdef.c -o tdef ; ./tdef
TEST: defined
TEST: 0
gcc -Wall -O2 -DTEST=1 tdef.c -o tdef ; ./tdef
TEST: defined
TEST: 1
so that means if we have somewhere in the code:
#ifdef USE_THREADS_WIN32
it will be processed no matter if you define USE_THREADS_WIN32=1 or
USE_THREADS_WIN32=0, hence its needed to explicitely undef it if we see
it defined to 0 so that we are able to have both USE_ARES *and*
USE_THREADS_WIN32 undefined in order to use the syncronous DNS ...
then we must keep in mind that neither USE_ARES nor USE_THREADS_WIN32 is
defined we want keep to default to USE_THREADS_WIN32=1 , argh ..
this is necessary in order to not break previous behaviour ...
honestly I'm not happy with that hack, and if someone has something
better in mind please speak up!
Gün.
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Gün, On Wed, Apr 10, 2013, Guenter li...@gknw.net wrote: honestly I'm not happy with that hack, and if someone has something better in mind please speak up! Modify Makefile.m32 in order to make it define one out of three possibilities ENABLE_ARES, ENABLE_SYNC_DNS or ENABLE_THREADS_WIN32. Modify config-win32.h in a way such that when above mentioned macros are defined config-win32.h defines appropriate USE_ARES, USE_THREADS_WIN32 or none of these two. This decoupling should also allow to retain default and previous behaviour of config-win32.h HTH -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Günter, Am 2013-04-02 00:43, schrieb Guenter: I have built now c-ares 1.9.1 with 'mingw32-make -f Makefile.m32' and tried to compile curl against it: 1. Added #define HTTP_ONLY and uncommented #define USE_ARES in config-win32.h 2. Set LIBCARES_PATH=E:\Downloads\c-ares-1.9.1 3. Finally compiled curl with mingw32-make mingw32-winssl-ares But the linking fails with: [snip] What now? oh! seems that c-ares is build static only while libcurl tries to link the dynamic one; I will look into this; probably something wrong with the makefiles There seems to be another issue with DNS setup. In config-win32.h sections /* Define to enable c-ares asynchronous DNS lookups. */ /*#define USE_ARES 1*/ /* Define to enable threaded asynchronous DNS lookups. */ /*#define USE_THREADS_WIN32 1*/ remained as-is but still async DNS lookups are enabled. I presumed that synchronous would run. In Makefile.m32 ifeq ($(findstring -dyn,$(CFG)),-dyn) DYN = 1 endif DYN is never used again. Seems to be a dead-end. Michael --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Michael, On 01.04.2013 12:37, Michael-O wrote: As a side note: when running the configure script in cygwin either for curl or c-ares the script hangs on checking types of args and return type for recvfrom... [1] Though my machine is quite old, the script runs in a decent time except that test. I really think that this is the same problem as with the DNS resolver. I doubt this since AFAICT configure doesnt make any tests over the network ... but: this test is by far really the slowest of all configure tests; I've just tested on an older box (old Cygwin on W2K3r2, P4 2.8GHz 2GB RAM) and this test took over 180 seconds; the whole configure run took: time ./configure [snip] real22m27.235s user0m46.476s sys 2m41.462s then I just tested on a more modern box (recent SuSE Linux, AMD Phenom II X4 965 8GB RAM) and even there this test took ~20 seconds where all other tests took only fracts of seconds - so here the recvfrom test took ~35% of the whole time configure needed: time ./configure [snip] real0m58.441s user0m26.424s sys 0m24.257s Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Michael, On 31.03.2013 17:18, Michael-O wrote: I am on Windows XP SP3 32 bits, I have compiled curl with MingW32 with GCC 4.5.2. you should upgrade to a newer MinGW version; in the past it turned out that exactly this version had some issues [1][2] ... Gün. [1] http://curl.haxx.se/mail/lib-2013-02/0286.html [2] http://curl.haxx.se/mail/lib-2013-02/0334.html --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Am 2013-04-01 14:23, schrieb Guenter: Michael, On 31.03.2013 17:18, Michael-O wrote: I am on Windows XP SP3 32 bits, I have compiled curl with MingW32 with GCC 4.5.2. you should upgrade to a newer MinGW version; in the past it turned out that exactly this version had some issues [1][2] ... Gün. [1] http://curl.haxx.se/mail/lib-2013-02/0286.html [2] http://curl.haxx.se/mail/lib-2013-02/0334.html Thanks Günter, I am now on GCC 4.7.2. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Am 2013-04-01 14:06, schrieb Guenter: Hi Michael, On 01.04.2013 12:37, Michael-O wrote: As a side note: when running the configure script in cygwin either for curl or c-ares the script hangs on checking types of args and return type for recvfrom... [1] Though my machine is quite old, the script runs in a decent time except that test. I really think that this is the same problem as with the DNS resolver. I doubt this since AFAICT configure doesnt make any tests over the network ... but: this test is by far really the slowest of all configure tests; I've just tested on an older box (old Cygwin on W2K3r2, P4 2.8GHz 2GB RAM) and this test took over 180 seconds; the whole configure run took: time ./configure [snip] real22m27.235s user0m46.476s sys 2m41.462s I have virtually the same setup and had: real24m12.438s user6m53.799s sys 5m14.550s So it that normal on Cygwin or is that related to my slow machine? I wonder how this would look like on the same slow machine but with a non-Windows OS. Thanks for the testing Michael --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Michael-O 1983-01...@gmx.net wrote: Jackpot! No proxies but I found several addresses in 192.168.56.* This is the VirtualBox (version 4.1.24 installed) Host-Only Network adapter. I have disabled it, and boom curl resolves immediately. A bug in VirtualBox I would guess. Some similar issue is still open [1]. I see similar issues with AsyncDNS if I have a dead or really slow nameserver in the list of DNS-server libcurl is trying. Building without USE_ARES gives much better resolve times in this case. AFAICS since the WindDNS (the code enabled by USE_THREADS_WIN32) is smarter than C-ares is. ipconfig /all will give you a hint of what DNS-servers C-ares will try. BTW. Gunter, your testspeed.bat file writes the test-file to disk and then deletes it right after. IMHO when testing just network speed, (and rule out a slow disk) you could write to the NUL-device and possibly eliminate some timing errors: curl -s -A %UAGENT% -w %OUTFMT% -o NUL %BASEURL%/%DLFILE% --gv --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Gisle, On 01.04.2013 17:51, Gisle Vanem wrote: BTW. Gunter, your testspeed.bat file writes the test-file to disk and then deletes it right after. IMHO when testing just network speed, (and rule out a slow disk) you could write to the NUL-device and possibly eliminate some timing errors: curl -s -A %UAGENT% -w %OUTFMT% -o NUL %BASEURL%/%DLFILE% there's always somewhere room for improvements! Thanks very much, that's really a good idea! Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Am 2013-04-01 17:18, schrieb Michael-O: Am 2013-04-01 16:19, schrieb Guenter: Hi Michael, On 01.04.2013 12:37, Michael-O wrote: This is what I have assumed, it's my setup. How come that other applications resolve quite fast? some things you should check: - disable automatic proxy configuration in IE if enabled Was disabled anyway. - check with 'route print' for local proxy (f.e. AVM DSLWeb or such; Viruses) Jackpot! No proxies but I found several addresses in 192.168.56.* This is the VirtualBox (version 4.1.24 installed) Host-Only Network adapter. I have disabled it, and boom curl resolves immediately. A bug in VirtualBox I would guess. Some similar issue is still open [1]. I have created an issue for this: https://www.virtualbox.org/ticket/11663 Daniel, you may want to add this as a known issue. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Michael, On 01.04.2013 22:36, Michael-O wrote: I have created an issue for this: https://www.virtualbox.org/ticket/11663 Daniel, you may want to add this as a known issue. 1st we need to know if this is also an issue with the default windows resolver; so have you also tested with a non-c-ares build? If it only occures with c-ares then this is only an issue with this lib, but not with libcurl. Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Name lookup/DNS resolution mechanism of libcurl
Hi Michael, On 01.04.2013 23:24, Michael-O wrote: Am 2013-04-01 22:52, schrieb Guenter: 1st we need to know if this is also an issue with the default windows resolver; so have you also tested with a non-c-ares build? If it only occures with c-ares then this is only an issue with this lib, but not with libcurl. How can I know? I have compiled plain vanilla with mingw. I presume that Features: AsynchDNS is standard windows resolver. That's what Daniel wrote as first reply. yep; somehow I must have mixed this up with c-ares, sorry about! Was probably because Gisle wrote about c-ares; but again: I mixed things up! I have built now c-ares 1.9.1 with 'mingw32-make -f Makefile.m32' and tried to compile curl against it: 1. Added #define HTTP_ONLY and uncommented #define USE_ARES in config-win32.h 2. Set LIBCARES_PATH=E:\Downloads\c-ares-1.9.1 3. Finally compiled curl with mingw32-make mingw32-winssl-ares But the linking fails with: [snip] What now? oh! seems that c-ares is build static only while libcurl tries to link the dynamic one; I will look into this; probably something wrong with the makefiles Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
