[squid-dev] [RFC] dns_wait_for_all

[Alex Rousskov]

On 09/14/2016 07:26 PM, Amos Jeffries wrote:
> On 15/09/2016 8:15 a.m., Alex Rousskov wrote:
>> Any better ideas or objections to adding dns_wait_for_all?


> In principle okay. However, I was intending to redesign the object we
> store DNS RR results in to achieve this is a more useful way. 

If you are talking about Comm::ConnectionList/serverDestinations, then
that object will have to be redesigned to support this proposal, of
course. The object would also have to be safely shared across FwdState,
peer selection code, and DNS code for the proposed feature to work.


> * slow DNS responses could add to the chain while earlier results are
> still in Async queue pending delivery to a caller.

... and while the caller is going through the TCP connect steps. That
TCP connect may be unsuccessful, requiring another attempt, possibly
using a different address. We already have the retrying code in place
and I am not proposing to change those algorithms during this project,
but the timing of new destinations arrival will change.


>  - this would obsolete the need for dns_wait_for_all to be configurable.

I have nothing specific against making the proposed algorithm the only
one, but I am not sure that _all_ side effects of the current
resolve-everything-first code are useless in all environments. AFAICT,
supporting both algorithms is easy (it is supporting the proposed
algorithm that is difficult).


> * ip/fqdn caches can store older data up to some timeout in TTL / LRU
> sequence.

I am not sure the DNS cache should be affected by the new lookup results
handling algorithm or the new serverDestinations storage of those
results. AFAICT, the DNS cache should store each result independently
while serverDestinations stores an ordered collection of results (some
of which may come from the DNS cache).

If you think that caching must change as a part of this project, can you
detail the related caching changes you would expect or foresee? If
caching changes are mostly independent, then we can discuss them
later/separately (to stay focused).


Thank you,

Alex.