Varnish only resolve the ip on startup

[Guillaume Quintard]

On Mon, Oct 4, 2021 at 11:55 AM Dridi Boukelmoune <dridi at varni.sh> wrote:

> That still doesn't seal the can of worms: once there are more than one
> address per family or addresses change, it's our connection and
> pooling models that need to be revisited, how many different addresses
> to try connecting to, how to retry, and how we account for all of that
> (stats for example). Again, it's a bit more complex that just saying
> "change the connect callback to one that combines resolve+connect".
>

I do understand that it's the core of the problem, and I'm probably being
pig-headed on this, but it feels to me that it's not really different from
a server with a floating IP, or a level-4 load-balancer fronting the
backend. The addresses may change, there may be more than one, but once the
connection is open, you can trust it and keep using it.
We trust connect() to get us to our goal, using getaddrinfo() on top of it
just means that we trust the DNS server to provide good info. So:
- if we prefer IPv6, we go through the list and pick the first IPv6 entry,
if we don't find one, we just grab the first IPv4 entry, no second chance
- if you try to reuse a connection and it died on you, you try to
resolve+connect a new one. Maybe you get the same IP, maybe you don't, but
we trust the DNS implementation to shuffle the entries around
- stats is an interesting issue, but again, only if you let it be. Backends
are already "IP address" or "UDS path", I'm fine with hiding all the DNS
entries behind "non-numerical host".

I agree, things get gnarly when we start fiddling with DNs, but there's
that portable interface that allows us to not have to. And if you want
fancy stuff like stats per IP, and fun load-balancing options that are
DNS-aware, there are vmods for that.

For the sake of transparency, I must admit that I do have an issue with my
proposal though: there's no timeout option for getaddrinfo, which sucks.

-- 
Guillaume Quintard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20211004/4632e71b/attachment.html>