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

Closed
wants to merge 1 commit into
from

Projects

None yet

2 participants

@jay
Member
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 curl/curl@2d435c7.

@jay jay connect: Fix happy eyeballs logic for IPv4-only builds
(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.
f64d9c4
@bagder bagder added a commit that referenced this pull request Mar 16, 2015
@jay @bagder jay + bagder connect: Fix happy eyeballs logic for IPv4-only builds
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 curl/curl@2d435c7.
059b3a5
@bagder
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 jay:fix-happy-eyeballs-ipv4-only-builds branch Mar 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment