An application that uses a Happy Eyeballs algorithm checks both IPv4 and IPv6 connectivity (with a preference for IPv6) and uses the first connection that is returned. REFERENCE FOR RFC8305 IS NOT DEFINED YET. Happy Eyeballs solves this problem by determining which transport would be better used for a particular connection by trying them both in parallel. Happy Eyeballs is designed to address the problem that many IPv6 networks are unreachable from parts of the Internet, and applications trying to reach those networks will appear unresponsive, thus frustrating users. The name "happy eyeballs" derives from the term "eyeball" to describe endpoints which represent human Internet end-users, as opposed to servers. Happy Eyeballs (also called Fast Fallback) is an algorithm published by the IETF that makes dual-stack applications (those that understand both IPv4 and IPv6) more responsive to users by attempting to connect using both IPv4 and IPv6 at the same time (preferring IPv6), thus minimizing common problems experienced by users with imperfect IPv6 connections or setups. If it's extremely popular, NodeJS can merge it in, and the code can be removed from here.Short description: Algorithm for applications supporting both Internet protocol versions 4 and 6 Ultimately though, I think it would probably be better for the community to develop something like this and test it out before merging it into NodeJS anyway and see the response it gets. It would be great if node could implement this natively, but there are currently no plans to do that. So, if you're on a IPv6-only network, you don't have to try every single IPv4 address before you get to the IPv6 address. In curl's implementation, which I prefer, its starts with the first address, then tries the next address of a different family. Still, this is better than dropping the request entirely. It could be a good idea to log a warning for the user that the first address sent by getaddrinfo was not available, as the 300ms timeout adds latency to every connection. Ideally, fetch would send the first address first, wait 300ms, and if no connection was made, continue down the line of addresses returned by dns.lookup. This can cause extremely confusing errors for developers using dual stack networks where IPv4 support periodically drops, because it's very hard to find what is causing the issue (I should know). Note, that verbatim=true will probably become the default. Currently, due to a poor design decision by NodeJS developers, IPv4 addresses are preferred, even when this contradicts RFC 6724. Btw, semi-related, the DNS lookup should be returning results with verbatim=true. Net.createConnection attempts to create a connection with the default dns.lookup server. I would propose node-fetch handle failover similarly to the browser. With IPv6-only network connectivity becoming increasingly common, misconfigurations in DNS servers can cause requests to fail, even when connectivity is available through alternative servers.īrowsers typically try to create a connection, wait 300ms, then try the next available server provided by getaddrinfo in the kernel.Ĭurrently, node-fetch implements no failover for support for timed-out connections. This functionality is also implemented in curl, iOS, Android, etc. In the browser, this is handled for you using the Happy Eyeballs algorithm. Is your feature request related to a problem? Please describe.ĭNS misconfigurations or server down time can cause fetch requests not to be fulfilled.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |