sorry about code style...
of course there should be an option, I wasn't sure if it should be
configure opt or run-time opt and I didn't want to go into that,
because, well, I'm not so good with c-ares yet.
I solved my case and I hope to get you all started. I can code a bit
more, if I have some directions :)
Reasons for having auto-dns-update disabled are potentially more than
peformance.
* it doesn't work correctly if user sets custom flags or servers or whatever
* it would leak fd's if user sets keep sockets open flag
* it cancels outstanding requests, that's far from perfect if the only
change in dns config is an extra server added, or a vpn connection
that bounces on/offline.
* reading all dns stuff again could lead to poor performance on some
systems, file timestamps or registry keys could be tracked instead,
but that means a separate chunk of code for every api/os.
* it polls dns config every timeout, default timeout is 5 seconds,
normal queries complete much faster, downtime may therefore be
significant.
Now that I look at it, my issue was to update dns config in a
long-running python program, perhaps it would have been easier to hack
at pycurl bindings instead and supply libcurl with callbacks into
python for name resolution perhaps. There are nice async/non-blocking
name resolvers in pure python or with bindings for python out there.
d.
On 15 February 2011 01:37, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Tue, 15 Feb 2011, Dima Tisnek wrote:
>
>> Cross-posting this to curl list because I've got some comments here
>> and no comments on c-ares list.
>
> The libcurl list is still not the right place so I'll respond only on the
> c-ares list.
>
>> * adds an ares_reinit functon, which reinitializes the channel same
>> way as ares_init.
>
> Nit: you're not following the code style accurately. We don't do multiple
> statements on the same code line for example.
>
>> * patches ares_gethostbyname and ares_gethostbyaddr with automatic
>> updates.
>
> I think we need a new option to enable this. Or possibly one that instead
> disables it for those who have a reason for not wanting this - primarily I
> would think of performance reasons.
>
> --
>
> / daniel.haxx.se
>
Received on 2011-02-15