On 31/07/13 18:09, Mark Delany wrote:
> On 31Jul13, Jakub Hrozek allegedly wrote:
>> On Wed, Jul 31, 2013 at 02:58:31PM +0000, Mark Delany wrote:
>>> On 31Jul13, Daniel Pocock allegedly wrote:
>>>> - if the application discovers new DNS servers (or if Ares has a way of
>>>
>>> Unfortunately that's what I've had to do. Monitor for DNS server changes and
>>> create a new ares channel.
>>
>> In SSSD, we use this approach as well. Watch resolv.conf with inotify
>> and just destroy and recreate the channel as appropriate.
>
> Right. The good news is that ares_destroy is callback friendly in that
> all the callbacks are called during the destroy process so you're not
> left with any lingering or lost queries.
>
> The bad news is that all the pending queries have to be re-initiated
> on the new channel.
>
> I imagine a clever implementation could have callbacks that test for
> ARES_ECANCELLED/ARES_EDESTRUCTION and automatically re-add the
> query to the newly constructed channel.
>
> Really, the biggest problem for me is that my user code has to get
> into the same business as ares_init() in that it has to know how to
> detect the changed environment. The current approach is a simplistic
> test on /etc/resolv.conf, but that doesn't work on all platforms.
>
Some situations (e.g. Linux VPN, DHCP) have resolv.conf. However, some
of the platforms I'm aiming for don't have that, e.g. Android:
https://github.com/resiprocate/android-demo-message
The higher-level application can probably do something to sense the
platform-specific change, e.g. Android apps can have a high-level
callback from the Android API:
SIP applications are very sensitive to network changes and need to
monitor this stuff anyway. Other applications may want c-ares to do
everything for them behind the scenes.
Received on 2013-07-31