Hi Dima,
so, you mean that when going from wifi to wifi there might be some
pending request
and for that, one needs to call ares_cancel?
I thought that ares__destroy_servers_state would be enough.
Also I tried to counter-reinit everything that is initialized in
init_by_resolv_conf
including domain and nameserver.
In my patch I am clearing all channel values and call
init_by_resolv_conf once again so every information in
/etc/resolv.conf shall end up in channel struct values.
Did I missed something?
This is for instance clearing of domains:
https://github.com/nayana-sue/c-ares/commit/696a1d59be106520a0471348caa469b03aa477ae#diff-6c5528d5eccbe836842006e4f0cb89baR1900
Of course your patch is much more robust because you also load the
parameters values,
which I do not do (it can be added to my patch, but then I might do the
whole ares_init as you do).
What is missing in your patch that needs some more work?
Thanks for your feedback and insights,
Nayanā
Dňa 26. 8. 2019 o 3:22 Dima Tisnek napísal(a):
> Hi Nayana, it's awesome that you want to make this happen.
>
> The problem is actually more complex than this:
> * [in some cases] c-ares is the only "good" resolved for libcurl, and
> * [when I last checked] c-ares reads /etc/resolv.conf only once
>
> Thus, for a device that moves from network to network (e.g. wifi), has
> a long-running process, needs domain name resolution timeouts (e.g.
> wifi) and some other requirements (multithreaded IIRC, because libc
> resolver uses a signal for timeout), this really is a problem.
>
> It may seem that this circumstances are peculiar, but, actually many
> IoT devices fall into this category.
>
> Back in the day, I've tried to make a patch, but didn't have
> time/stamina and couldn't put enough effort for it to be accepted.
>
> https://gist.github.com/dimaqq/397682b68cdc0992a5d314c53e8ecf86 has the code.
>
> The task is somewhat more complex than you stated, because resolv.conf
> may contain several bits of configuration, and sometimes partial
> update could break things (IIRC to resolve a LAN host, both `domain`
> and `nameserver` are needed).
>
> Cheers,
> d.
>
> On Thu, 15 Aug 2019 at 21:36, Nayanā Topolsky <nayana.topolsky_at_zoho.com> wrote:
>> Hi,
>>
>> so I used just stat as the conf file is small, no need for 64bit version.
>> However I was not sure if I should ifdef the stat structure usages as well?
>>
>> So the pull request is there, the only systems that use /etc/resolv.conf are Linux and OSX, which both passed via CI tests.
>> I guess there are no win32 automated tests?
>>
>> Dňa 9. 8. 2019 o 9:02 Daniel Stenberg napísal(a):
>>
>> On Thu, 8 Aug 2019, Nayanā Topolsky wrote:
>>
>> I used stat64 function to check mtime and ctime and also size and ino values in very similar way as it is done in libc.
>>
>>
>> stat(), or variations of it, should be fairly portable over many systems. (In the curl project we do stat on basically *all* platforms with just this little setup magic: https://github.com/curl/curl/blob/master/lib/curl_setup.h#L361-L396)
>>
>> The particular file name(s) you check which that call could also be system specific but should be possible to be made to work on a fair amount of systems.
>>
>> I can send a patch (or pull request) with hope that somebody else will continue the work on it. Or maybe it would be mergable even in this way.
>>
>>
>> We will prefer a pull-request so that we get it somewhat verified before we consider merging and handling updates and reviews are also stream-lined that way.
>>
>> We can't guarantee that "somebody else" will magically continue working on it if you just drop it there though, I suppose it depends on how much work that remains...
>>
>> Thanks!
>>
Received on 2019-08-26