Open ruslandoga opened 4 months ago
In place of a "ping": I would also happily work on implementing happy eyeballs into Erlang!
Related issues / discussions / projects:
I believe built-in happy eyeballs implementation would be a huge win for the ecosystem. 👍
Yes!
I believe that the idea is that gen_tcp (and gen_udp, gen_sctp) should be "close to the metal". And these kinds of features are up to the application.
I my memory is correct the inets (httpd and httpc) had a similar config option (inet6fb4 or something like it).
I do not know if ssl has this feature.
'socket' is very much "close to the metal". But gen_tcp could maybe be considered to be a layer that should provide this kind of a feature. We will discuss ASAP (vacation times here at OTP central).
This is the kind of feature that sits between OTP and application I think. It makes sense to have it in OTP because many would use it, but not all network connections require it either. It could be a separate open source project, but then who has the will and the bandwidth to maintain it?
Happy Eyeballs is also tricky in that it pretty much requires connecting via 4/6 concurrently. The socket
module's nowait
could come in handy there. Try to connect to all then wait for the winner. But once we have the right socket
connected, we need to be able to hand it off to gen_tcp
or ssl
. So OTP changes would be required.
The alternative is building on top of gen_tcp
or ssl
but that means having concurrent processes and much higher complexity.
If we could "upgrade" a socket
socket to gen_tcp
/ ssl
/ others, in a documented way, then I believe we wouldn't be far from actually implementing this in a fairly straightforward way.
It could be a separate open source project, but then who has the will and the bandwidth to maintain it?
FWIW, I started working on https://github.com/ruslandoga/happy_tcp and will be trying to implement Happy Eyeballs by using prim_inet:async_connect
but it's quite hacky:
I haven't looked into socket
yet, just gen_tcp
with inet
backend.
So OTP changes would be required.
So far, happy_tcp seems to work without any changes but it would be nice if inet_tcp_backend "behaviour" could connect to multiple addresses instead of just one, then my hack of passing a list of addresses could go away.
But my ideal would be having inet6_tcp
do all this. So that gen_tcp:connect(Domain, Port, [inet6])
"would just work", the way it already works for gen_tcp:listen
(which afaik binds on both ipv4 and ipv6 when inet6 option is provided).
The OTP changes are needed to keep the same interface, i.e. once the connection has succeeded you use gen_tcp
or ssl
as you normally would. There's no reason to have yet another interface today, other than the fact that we can't upgrade the socket
or prim_inet
socket to gen_tcp
without using undocumented functions. Note that the code exists but it is not a public interface from OTP (same goes for prim_inet:async_connect
).
👋
Is your feature request related to a problem? Please describe.
Not sure yet. First I'd like double check if
gen_tcp:connect
andssl:connect
withinet6
option are supposed to fallback toinet
when IPv6 connection is not successful. And if it's not supposed to work this way, I'd like to request this feature!Right now I'm not able to make this sort of fallback work. Here're some examples from Fly.io dual-stack machine and from an IPv4-only container running on AWS EC2. I'm using IPv4-only and IPv6-only hosts from http://dual.tlund.se
From Fly.io Machine
Connecting to IPv4-Only Host works with default
inet
optionBut fails when
inet6
option is providedipv6_v6only
doesn't HelpDefault options (
inet
) don't work with IPv6-only hostinet6
works with IPv6-only hostFrom IPv4-only container on AWS EC2
No fallback to
inet
Describe the solution you'd like
inet6
would fallback toinet
automatically when needed so that providinginet6
option would always increase the chance of a successful connection.Describe alternatives you've considered
Some Elixir libraries perform a manual fallback from inet6 to inet like Mint and some other libraries like Postgrex allow a list of endpoints to be provided for connection attempts.
Additional context
Relevant discussion (where this question originated): https://github.com/phoenixframework/phoenix/pull/4289#issuecomment-2149345334