Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

connect: Fix happy eyeballs logic for IPv4-only builds #168

Closed
wants to merge 1 commit into from

Conversation

jay
Copy link
Member

@jay jay commented Mar 15, 2015

(trynextip)

  • Don't try the "other" protocol family unless IPv6 is available. In an
    IPv4-only build the other family can only be IPv6 which is unavailable.

This change essentially stops IPv4-only builds from attempting the
"happy eyeballs" secondary parallel connection that is supposed to be
used by the "other" address family.

Prior to this change in IPv4-only builds that secondary parallel
connection attempt could be erroneously used by the same family (IPv4)
which caused a bug where every address after the first for a host could
be tried twice, often in parallel. This change fixes that bug. An
example of the bug is shown below.

Assume MTEST resolves to 3 addresses 127.0.0.2, 127.0.0.3 and 127.0.0.4:

  • STATE: INIT => CONNECT handle 0x64f4b0; line 1046 (connection #-5000)
  • Rebuilt URL to: http://MTEST/
  • Added connection 0. The cache now contains 1 members
  • STATE: CONNECT => WAITRESOLVE handle 0x64f4b0; line 1083
    (connection #0)
  • Trying 127.0.0.2...
  • STATE: WAITRESOLVE => WAITCONNECT handle 0x64f4b0; line 1163
    (connection #0)
  • Trying 127.0.0.3...
  • connect to 127.0.0.2 port 80 failed: Connection refused
  • Trying 127.0.0.3...
  • connect to 127.0.0.3 port 80 failed: Connection refused
  • Trying 127.0.0.4...
  • connect to 127.0.0.3 port 80 failed: Connection refused
  • Trying 127.0.0.4...
  • connect to 127.0.0.4 port 80 failed: Connection refused
  • connect to 127.0.0.4 port 80 failed: Connection refused
  • Failed to connect to MTEST port 80: Connection refused
  • Closing connection 0
  • The cache now contains 0 members
  • Expire cleared
    curl: (7) Failed to connect to MTEST port 80: Connection refused

The bug was born in commit 2d435c7.

(trynextip)
- Don't try the "other" protocol family unless IPv6 is available. In an
IPv4-only build the other family can only be IPv6 which is unavailable.

This change essentially stops IPv4-only builds from attempting the
"happy eyeballs" secondary parallel connection that is supposed to be
used by the "other" address family.

Prior to this change in IPv4-only builds that secondary parallel
connection attempt could be erroneously used by the same family (IPv4)
which caused a bug where every address after the first for a host could
be tried twice, often in parallel. This change fixes that bug. An
example of the bug is shown below.

Assume MTEST resolves to 3 addresses 127.0.0.2, 127.0.0.3 and 127.0.0.4:

* STATE: INIT => CONNECT handle 0x64f4b0; line 1046 (connection #-5000)
* Rebuilt URL to: http://MTEST/
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x64f4b0; line 1083
(connection #0)
*   Trying 127.0.0.2...
* STATE: WAITRESOLVE => WAITCONNECT handle 0x64f4b0; line 1163
(connection #0)
*   Trying 127.0.0.3...
* connect to 127.0.0.2 port 80 failed: Connection refused
*   Trying 127.0.0.3...
* connect to 127.0.0.3 port 80 failed: Connection refused
*   Trying 127.0.0.4...
* connect to 127.0.0.3 port 80 failed: Connection refused
*   Trying 127.0.0.4...
* connect to 127.0.0.4 port 80 failed: Connection refused
* connect to 127.0.0.4 port 80 failed: Connection refused
* Failed to connect to MTEST port 80: Connection refused
* Closing connection 0
* The cache now contains 0 members
* Expire cleared
curl: (7) Failed to connect to MTEST port 80: Connection refused

The bug was born in commit curl/curl@2d435c7.
bagder pushed a commit that referenced this pull request Mar 16, 2015
Bug: #168

(trynextip)
- Don't try the "other" protocol family unless IPv6 is available. In an
IPv4-only build the other family can only be IPv6 which is unavailable.

This change essentially stops IPv4-only builds from attempting the
"happy eyeballs" secondary parallel connection that is supposed to be
used by the "other" address family.

Prior to this change in IPv4-only builds that secondary parallel
connection attempt could be erroneously used by the same family (IPv4)
which caused a bug where every address after the first for a host could
be tried twice, often in parallel. This change fixes that bug. An
example of the bug is shown below.

Assume MTEST resolves to 3 addresses 127.0.0.2, 127.0.0.3 and 127.0.0.4:

* STATE: INIT => CONNECT handle 0x64f4b0; line 1046 (connection #-5000)
* Rebuilt URL to: http://MTEST/
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x64f4b0; line 1083
(connection #0)
*   Trying 127.0.0.2...
* STATE: WAITRESOLVE => WAITCONNECT handle 0x64f4b0; line 1163
(connection #0)
*   Trying 127.0.0.3...
* connect to 127.0.0.2 port 80 failed: Connection refused
*   Trying 127.0.0.3...
* connect to 127.0.0.3 port 80 failed: Connection refused
*   Trying 127.0.0.4...
* connect to 127.0.0.3 port 80 failed: Connection refused
*   Trying 127.0.0.4...
* connect to 127.0.0.4 port 80 failed: Connection refused
* connect to 127.0.0.4 port 80 failed: Connection refused
* Failed to connect to MTEST port 80: Connection refused
* Closing connection 0
* The cache now contains 0 members
* Expire cleared
curl: (7) Failed to connect to MTEST port 80: Connection refused

The bug was born in commit 2d435c7.
@bagder
Copy link
Member

bagder commented Mar 16, 2015

Thanks a lot @jay, merged in commit 059b3a5 just now

@bagder bagder closed this Mar 16, 2015
@jay jay deleted the fix-happy-eyeballs-ipv4-only-builds branch March 16, 2015 21:47
@lock lock bot locked as resolved and limited conversation to collaborators Jan 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants