9 Oct
2024
9 Oct
'24
9:31 a.m.
On Wed, Oct 9, 2024 at 6:18 AM Travis Burtrum <travis(a)burtrum.org> wrote:
On 9/24/24 4:12 AM, Daniel Gultsch wrote:
I think a simpler version of this XEP would just be:
With my council hat on I’m going to vote +1 as I believe there is
enough text that people could start implementing it.
On a personal level and as a client developer I share a lot of the
concerns that Travis has.
I think a better version of the XEP would be "As soon as you have to
decide between IPv4 and IPv6 do happy eyeballs" which purposefully
leaves out all the steps that get you to this point as those can vary
widely.
Somewhat related as a client developer who (somewhat unfortunately)
has an incentive to just connect to something that works by every
means necessary I started to treat connections as successful only
after establishing a stream (instead of just a TCP connection). This
is to work around issues around misconfigured HAproxys that drop us
into the webserver instead of the XMPP server. Thus a simple happy
eyeballs that throws away the slower TCP connection instead of keeping
it as a fallback in case the faster one doesn’t work would probably
not work for me.
This is all to say; I can (or should) probably implement a XEP that
says "Use Happy Eyeballs" but the current proposed XEP has too many
words that I may or may not have to ignore to make it work in
practice. (I haven’t event gotten to the part where my client does
very aggressive "last working connection" caching for networks where
DNS simply doesn’t work)
cheers
Daniel
When you have domains/ports to connect to with
the same priority, use
the algorithm defined in
https://datatracker.ietf.org/doc/html/rfc8305
to connect to them.
Re-explaining what is already defined in the SRV and XMPP RFCs is rather
confusing, I kept looking for something different and couldn't find it.
Additionally it implies this doesn't apply to all of the other
connection methods XMPP uses, XEP-0156 and XEP-0368 for starters, being
too specific is harmful here.