ares_getaddrinfo(): Fail faster on AF_UNSPEC if we've already received one address class #551
Conversation
…l A or AAAA query, tell any other related oustanding queries to not perform any retries if they have issues
…w if a query was really queued or not
…ich is what the prior code would do
| /* Identical to ares_send() except returns normal ares return codes like | ||
| * ARES_SUCCESS */ | ||
| int ares_send_ex(ares_channel channel, const unsigned char *qbuf, int qlen, | ||
| ares_callback callback, void *arg); |
There was a problem hiding this comment.
If these two new functions indeed are intended to be added to the public API, then they need man pages as well.
Maybe start out for internal consumption only?
There was a problem hiding this comment.
They're in the private header. Not sure if they need to be public at all. I just needed to know if there was an error code to know if the query pointer was invalidated by the call or not as otherwise it would cause access to a free'd memory area. In the future we could make them public and add docs for them, but for now they're private.
| @@ -248,6 +248,8 @@ struct query { | |||
| int using_tcp; | |||
| int error_status; | |||
| int timeouts; /* number of timeouts we saw for this request */ | |||
| int no_retries; /* do not perform any additional retries, this is set when | |||
There was a problem hiding this comment.
Maybe make it no_retries:1; to signal that it actually is a boolean? Alternatively use a bool typedef.
There was a problem hiding this comment.
This is another one where "convention" within c-ares gets in the way. There is no bool type defined or used anywhere within c-ares, and I can't find any other instances of using the bitfield width modifiers. You can see the "using_tcp" member above, it too is a boolean, however it too uses no modifiers. I'd rather keep consistency at this point and maybe do a bulk "cleanup" in the future for things like this.
As per #541, when using AF_UNSPEC with ares_getaddrinfo() (and in turn with ares_gethostbynam()) if we receive a successful response for one address class, we should not allow the other address class to continue on with retries, just return the address class we have.
This will limit the overall query time to whatever timeout remains for the pending query for the other address class, it will not, however, terminate the other query as it may still prove to be successful (possibly coming in less than a millisecond later) and we'd want that result still. It just turns off additional error processing to get the result back quicker.