On Thu, Jun 17, 2021 at 6:57 AM Tobias S. Josefowitz <[email protected]> wrote: > > On Fri, Jun 11, 2021 at 1:31 PM Chris Angelico <[email protected]> wrote: > > > > Branch: rosuav/http-multi-connect > > > > New APIs in Protocols.DNS.async_client - host_to_ips in both callback > > and Promise variants. > > > > Change of behaviour in Protocols.HTTP.Query and the high level > > functions that call on it (eg Protocols.HTTP.get_url_data and > > do_async_method): All forms will now look up the name with potentially > > multiple results, and will attempt connections on IPv6 before IPv4 > > (previously, synchronous requests would prefer IPv4 unless > > unavailable, and async would prefer IPv6 unless unavailable). > > > > Not merged into master as yet, but I will be using this on my own system. > > > > Code review would be appreciated. > > This looks good to me, but we still need to undo the host_to_ip() > changes of course. I also wonder if implementers of Happy Eyeballs[1] > really are just too careful, or if we ultimately would want to > implement Happy Eyeballs, too; using a "get me a connection to TARGET > please" type API. > > [1] https://en.wikipedia.org/wiki/Happy_Eyeballs >
Should host_to_ip be put completely back how it was (IPv4 only), or should it return IPv4 if available, IPv6 else? Happy Eyeballs, if implemented, should probably be an option - it's a tradeoff between faster connections and more load. Might be worth actually pushing that one down in the stack a bit, maybe a Stdio or Protocols function that establishes a connection and returns it? ChrisA
