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

net: Dial with Happy Eyeballs (RFC 6555) #3610

Closed
mikioh opened this issue May 11, 2012 · 32 comments

Comments

Projects
None yet
7 participants
@mikioh
Copy link
Contributor

commented May 11, 2012

Even if it would be a part of RFC 6555, supporting RFC 6555 
makes someone who lives on both IPv4 and IPv6 dual stack 
environment happy.
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented May 11, 2012

@bradfitz

This comment has been minimized.

Copy link
Member

commented May 15, 2012

Comment 2:

Yes, we discussed this briefly on golang-dev in 5486078 as part of issue #240.  The
DialAttempt SoftTimeout.  We went with a considerably milder CL for Go 1 because the
deadline was coming too quickly to do the whole DialPlan thing comfortably.
@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2012

Comment 3:

Brad, do you still have the DialPlan sketch? Can you drop it in here?
@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2012

Comment 4:

Labels changed: added go1.1.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Oct 31, 2012

Comment 5:

DialPlan sketch (reconstructed from a poor photo and memory):
https://golang.org/cl/5486078/
@bradfitz

This comment has been minimized.

Copy link
Member

commented Oct 31, 2012

Comment 6:

Related, a user is discussing how DialTimeout is insufficient for them because they need
to set the DialTCP local address along with a timeout, and we have no API that can do
both.
Now that issue #2631 is being fixed by https://golang.org/cl/6815049, we can at
least properly set the dial timeout.
Adding DialTCPTimeout and DialUnixTimeout and DialIPTimeout (and everything Timeout)
would be unfortunate.  Using DialPlan (or something like it) would be preferred.
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Nov 6, 2012

Comment 7:

Well, I just wanted, still want to have a simple and improved Dial that runs 
both IPv4 and IPv6 racers under the hood. ;) I'm fine with DialPlan or whatever.
A question: Do you guys suppose that DialPlan would be a sort of connection 
pooling? (expect: no)
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Nov 6, 2012

Comment 8:

Looks like requirements for DialPlan would be:
R1. It must take various dial targets
a) DNS names
b) IP addresses
c) Combo of (a) and (b)
R2. It must run Happy Eyeballs dialing if the given target is a DNS name
R3. It must take various dial strategies (optional?)
a) Round-robin
b) Run through
R4. It must take various dial deadlines
a) Deadline for each dial
b) Deadline for entire dial list
Thoughts?
@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 6, 2012

Comment 9:

No connection pooling.
@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2012

Comment 10:

Labels changed: added size-l.

@gopherbot

This comment has been minimized.

Copy link

commented Jan 10, 2013

Comment 11 by paul@vanbrouwershaven.com:

Are there any plans to continue the development of this DialPlan function?
While the issue in DialTimeout is closed by https://golang.org/cl/6815049 it
has no option to specify a local address to bind to. This DialPlan function would make
it all much more flexible.
@bradfitz

This comment has been minimized.

Copy link
Member

commented Feb 19, 2013

Comment 12:

See also issue #4842 (TCP Fast Open)
@bradfitz

This comment has been minimized.

Copy link
Member

commented Feb 27, 2013

Comment 13:

This issue was updated by revision 752fec2.

Update issue #4842
R=golang-dev, r, dave, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/7365049
@dvyukov

This comment has been minimized.

Copy link
Member

commented Mar 7, 2013

Comment 15:

How is it blocked on 4056? The situation with thread creation may be better with the new
scheduler.
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Mar 7, 2013

Comment 16:

Ah, I misunderstood that happy eyeballs will require one more DNS lookup, not true.
Anyway, very happy to see new scheduler, yay!
@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2013

Comment 17:

Seems like there's still a lot left on this. I'm inclined to postpone it to Go 1.2
unless someone can argue that it's important and also that it's simple and can be done
quickly.
Thoughts?
@bradfitz

This comment has been minimized.

Copy link
Member

commented Mar 12, 2013

Comment 18:

Later.
Most Go usage is on servers where IPv6 connectivity is relatively reliable.  It's
clients (at home, behind crappy NAT boxes and crappy ISPs) who need Happy Eyeballs the
most, so this is somewhat low priority, even though it'd be fun.
It's also likely that in a year's time, IPv6 will be much better deployed in the wild. 
If it gets done before Go 1.2, great, but it shouldn't block Go 1.1.

Labels changed: removed go1.1.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Mar 12, 2013

Comment 19:

Owner changed to ---.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 20:

Labels changed: added go1.2maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 21:

Labels changed: added feature.

@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Aug 3, 2013

Comment 22:

This issue was updated by revision f0291a8.

Update issue #5267
Update issue #5707
R=golang-dev, bradfitz, dave, fvbommel
CC=golang-dev
https://golang.org/cl/11958043
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Aug 4, 2013

Comment 23:

Status changed to Started.

@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Aug 30, 2013

Comment 24:

This issue was updated by revision 3c6558a.

Update issue #5267
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13368044
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Aug 30, 2013

Comment 25:

This issue was updated by revision 20692c2.

Update issue #5267
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13241046
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Aug 31, 2013

Comment 26:

This issue was updated by revision 7c59c8b.

Update issue #5267
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13374043
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Sep 2, 2013

Comment 27:

This issue was updated by revision c576bcb.

Update issue #5267
Update issue #5707
R=golang-dev, bradfitz, dave
CC=golang-dev
https://golang.org/cl/13465043
@robpike

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2013

Comment 28:

What is missing from this?
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Sep 4, 2013

Comment 29:

The review of the last CL in progress.
https://golang.org/cl/12416043/
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Sep 11, 2013

Comment 30:

This issue was closed by revision 89b2676.

Status changed to Fixed.

@pmarks-net

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2014

Comment 31:

This Happy Eyeballs implementation does not comply with
http://tools.ietf.org/html/rfc6555#section-4.1
"""
   Thus, to avoid harming IPv4-only hosts, implementations MUST prefer
   the first IP address family returned by the host's address preference
   policy, unless implementing a stateful algorithm described in
   Section 4.2.  This usually means giving preference to IPv6 over IPv4,
   although that preference can be overridden by user configuration or
   by network configuration [ADDR-SELECT].  If the host's policy is
   unknown or not attainable, implementations MUST prefer IPv6 over
   IPv4.
"""
Note that "MUST" is stronger than "SHOULD" in RFC-speak.
I wrote a test client, and repeated invocations show that IPv4 and IPv6
addresses are reported at random.  This behavior is considered harmful,
for the reasons laid out in section 4.1
Here's the test client I'm using:
package main
import (
        "net"
        "fmt"
)
func main() {
        dialer := net.Dialer{DualStack: true}
        conn, err := dialer.Dial("tcp", "ds.test-ipv6.com:80")
        if err != nil {
                panic("Dial")
        }
        fmt.Fprintf(conn, "GET /ip/ HTTP/1.0\r\n\r\n")
        buf := make([]byte, 4096)
        conn.Read(buf)
        println(string(buf))
}
@mikioh

This comment has been minimized.

Copy link
Contributor Author

commented Jul 30, 2014

Comment 32:

Yup, as described in the CL description, the current implementation is not compliant for
RFC 6555. It runs two TCP syn racers simultenaously without dealing with address family
preferences as described in Geoff Huston's slides. Please open new issue if you think we
should make it compliant to RFC 6555.
@pmarks-net

This comment has been minimized.

Copy link
Contributor

commented Jul 31, 2014

Comment 33:

Filed issue #8453.

@mikioh mikioh added fixed labels Jul 31, 2014

@rsc rsc added this to the Go1.2 milestone Apr 14, 2015

@rsc rsc removed the go1.2maybe label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 24, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.