Fix request: Implement Happy Eyeballs Version 2: Better Connectivity Using Concurrency, RFC 8305

Q_comm_red
Q_comm_red Member ✭✭
edited October 2023 in Display/UI
It appears from testing that Quicken has not implemented RFC 8305 (Happy Eyeballs Version 2: Better Connectivity Using Concurrency). This can be demonstrated using wireshark that shows Quicken delays loading data file if an ipv6 address is not working, which has been the case this week. The work around is to disable ipv6 and things work normally.

Scenario: The quicken app attempts to contact the ipv6 of "download.quicken.com" address several times without success. Quicken then contacts services.quicken.com and determines that the only option is an ipv4 address. The delay as seen by the user is about 30 seconds.

Implementing RFC 8305, as many browsers and apps have, would resolve the ipv6/ipv4 issue in less than 1 second, typically.

This is a request to implement RFC 8305 in quicken for windows.

If the quicken developers wish to persue this, I have a wireshark file that demonstrates the issue. The developers may send an email requesting the file. The client running Quicken is located in Austin, Texas.

Please post questions if the above is not clear.
1
1 votes

Reviewed · Last Updated

Comments

  • Rocket J Squirrel
    Rocket J Squirrel SuperUser ✭✭✭✭✭
    edited April 2023

    @Q_comm_red

    I haven't kept up with RFCs for many years, so this is new to me. Having perused most of the RFC, it seems to me this should be implemented in the network layer of the operating system, not by each and every individual application. What am I missing?

    Quicken user since version 2 for DOS, now using QWin Biz & Personal Subscription (US) on Win10 Pro.

  • Q_comm_red
    Q_comm_red Member ✭✭
    @Rocket J Squirrel
    The network layer was my thought too, but as I read some of the RFC and other references, it appears the apps, Browsers mainly, are doing it.

    In the Wireshark data, quicken does another call to a different server to get a working IP address. So it seems that a "fallback logic" is already in the quicken, but its all serialized so the wait for the user is 30 secs. The odd part is that the ipv4 address that quicken finally uses is the one returned by first DNS response, but the quicken tried ipv6 first, several times before 'falling back' and requesting the addresses from another server.
  • Q_comm_red
    Q_comm_red Member ✭✭
    @Rocket J Squirrel
    Just checked and the ipv6 address is now responding (per wireshark) and quicken is using that address prior to opening a data file. 30 second loading delay is back to normal 5 secs or so.