Hi, Great idea, I didn't know that it was already implemented by Trio and I didn't know that there were two RFCs to specify how to make this. In the case of the connection that strategy can bring many benefits in networks that are dynamic, perhaps the case of the ELBs in AWS which scale up or shrink the number of load balances that are in front of your application taking into account the traffic that they have to handle. That change gets reflected in the DNS answer, indeed AWS suggests to the clients to save the DNS resolutions in the cache client for not more than 60 seconds, obviously because the IP addresses will be adaptative to the number of load balancers at some specific time. Having a "big" connection timeout the client experience till reaching an available destination is proportional to the number of hosts iterated and failed for host in hosts: try: return await connect(host, timeout=1) except TimeoutError: logging.warning("Host not available, trying the next one") So definitely the proposal of the Happy Eyeballs implementation improves the latency needed to get a healthy connection. Thanks for making it visible! On Sun, May 13, 2018 at 7:40 AM, twisteroid ambassador <twisteroid.ambassador@gmail.com> wrote:
Repo: https://github.com/twisteroidambassador/async_stagger Docs: http://async-stagger.readthedocs.io/en/latest/
Provides near drop-in replacements for open_connection() and create_connection() using Happy Eyeballs. Also exposes the underlying scheduling logic where you can plug in your own coroutines to run.
I basically ported trio's implementation to asyncio, and it turned out to be not too difficult.
Cheers,
twistero _______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
-- --pau