>> Oh, and the change we've made (to our internal c-ares tree) is : when a
>> dns-query fails the client supplied callback function got the general
>> ARES_ENOTFOUND error code but not the error code that was reported to
the
>> host_callback (in case of ares_gethostbyname for example). In our case
we
>> had a single name server that timed-out but we couldn't tell that from a
>> situation where we've supplied the wrong IP for it.
>
>I'm sorry, but can you elaborate on exactly why the existing value is not
>enough? I don't quite understand.
Lets say you provide c-ares with a single nameserver to perform a
gethostbyname query. And lets assume that the query times out. Then
end_hquery (in ares_gethostbyname.c) is called with a ARES_ENOTFOUND status
code which overrides the ARES_ETIMEOUT error that was actually returned for
the first (and only) query. Is that clearer?
Cheers,
Shmul
On Nov 15, 2007 1:22 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Wed, 7 Nov 2007, Shmulik Regev wrote:
>
> > Recently there have been a couple of discussions regarding extra values
> > passed to callback functions and the resulting API changes. We have also
> > encountered a situation where we need to get data that is not currently
> > available to the c-ares client (see below). Daniel mentioned (
> >
> http://daniel.haxx.se/projects/c-ares/mail/c-ares-archive-2007-09/0023.shtml
> )
> > that he thinks an opaque handle of some sort is probably the right way
> to
> > handle (no pun intended) such future additions.
> >
> > My question - I'm willing to write such a patch but I want to understand
> > what are the guidelines for it - should we use an handle and add calls
> to
> > extract data from it or should we pass a struct that has the data?
>
> It would then use the first approach, with some kind of function that
> extracts
> information so that the (internal) struct can be modified between versions
> without breaking the ABI.
>
> > Oh, and the change we've made (to our internal c-ares tree) is : when a
> > dns-query fails the client supplied callback function got the general
> > ARES_ENOTFOUND error code but not the error code that was reported to
> the
> > host_callback (in case of ares_gethostbyname for example). In our case
> we
> > had a single name server that timed-out but we couldn't tell that from a
> > situation where we've supplied the wrong IP for it.
>
> I'm sorry, but can you elaborate on exactly why the existing value is not
> enough? I don't quite understand.
>
> I would also be interested in reading anyone else's opinions about this
> patch/suggestion.
>
> Related to this, I posted a blog entry about my current c-ares situation:
>
> http://daniel.haxx.se/blog/2007/11/15/c-ares-and-me/
>
Received on 2007-11-25