Comment 1:

I believe this is a dup of issue #3610. At least it's very related.

Comment 2:

Yeah, it's related, but that one appears a lot more expansive and more
performance-focused, whereas this is relatively simple and about correctness.

Comment 3:

They have almost identical implementations, though.
Actually, now that the dial code's been cleaned up a bunch, both are pretty easy.

Comment 4:

Maybe. I don't know about how to implement either of these, but this one should require
no API changes, and thus I hope it could be in 1.1.1, whereas the other one sounds like
people are pushing it back to 1.2.

Comment 5:

Fast, Cheap, Good; pick any two.
F C G
- - v  DNS TTL lookup (for correctness)
v - v  Native, net-embedded DNS resolver (no more cgo threads)
v - v  DNS-related record caching (for future dialings)
- v -  Run multiple dial-racers at each dial
v - v  TCP connection pooling w/ scoreboards (for future dialings)
I guess the example algorithm in RFC 6555 (section 6) without
any preferences (TTL, scoreboards, addrsel policies, etc) is
enough at first.

Comment 6:

Um. All this bug really needs is a for loop.

Comment 7:

What does it mean to "try all resolved addresses" ?

Comment 8:

It means that if a name resolves to addr1, addr2, addr3, net.Dial
should not give up if it can't connect addr1, but rather try addr2 and
addr3 before giving up.

Comment 9:

David, for the purposes you care about (localhost resolving to both 127.0.0.1 and ::1),
the Dial code already tries to deal with that:
func firstFavoriteAddr(filter func(IP) IP, addrs []string) (addr IP) {
        if filter == nil {
                // We'll take any IP address, but since the dialing code                                             
                // does not yet try multiple addresses, prefer to use                                                
                // an IPv4 address if possible.  This is especially relevant                                         
                // if localhost resolves to [ipv6-localhost, ipv4-localhost].                                        
                // Too much code assumes localhost == ipv4-localhost.                                                
                addr = firstSupportedAddr(ipv4only, addrs)
                if addr == nil {
                        addr = firstSupportedAddr(anyaddr, addrs)
                }
        } else {
                addr = firstSupportedAddr(filter, addrs)
        }
        return
}
To be clear, in your case, is the problem that the listener is on [::1]:nnn and the Go
net package is dialing 127.0.0.1:nnn?

Comment 10:

Yes, the listener in my scenario is only on [::1]:port, so always
picking 127.0.0.1:port is failing to find it.

Comment 11:

Labels changed: added go1.2maybe, removed go1.1maybe.

Comment 12:

Labels changed: added feature.

Comment 13:

This is a bug, not a feature. The net package is not behaving in the correct way.

Labels changed: added go1.2, removed go1.2maybe.

Comment 14:

I'm fine either way; fixing this by old dual stack style or by happy eyeball style.
old dual stack style:
for _, ip := lookupIP {
  dialTCP(...)
}
happy eyeball style:
ips := lookupIP
for _, ip := range ips {
  go func() { dialTCP; wire<-sig }
}
select {
case winner := <-wire:
...
}

Comment 15:

See the key on the label entry. "Feature" means "Feature or feature-sized work; not okay
during release freeze."

Comment 16:

Owner changed to @mikioh.

Comment 17:

Status changed to Started.

Comment 18:

Two CLs are CLs.
net: pick a pair of different address family IP addresses for DNS registered name
https://golang.org/cl/12414043/
makes eyes open on control plane,
net: implement Happy Eyeballs connection setup for TCP
https://golang.org/cl/12416043/
runs two dialers simply by using channel and goroutine.
The latter includes the former for convenience.

Comment 19:

Labels changed: added priority-soon, removed priority-triage.

Comment 20:

https://golang.org/cl/12414043/ was abandoned. smaller CLs coming. Probably not
in time for 1.2 but leaving open for now.

Comment 21:

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

Comment 22:

Labels changed: added releaseblocker.

Comment 23:

This issue was closed by revision 89b2676.

Status changed to Fixed.