Navigation Menu

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

Jump to bottom

net: I would like Dialer.Dial to provide the time it took to do DNS lookups and TCP Connect #12476

Closed
sajal opened this issue Sep 3, 2015 · 5 comments
Closed

net: I would like Dialer.Dial to provide the time it took to do DNS lookups and TCP Connect #12476

sajal opened this issue Sep 3, 2015 · 5 comments
Labels
FrozenDueToAge
Milestone
Unplanned

Comments

@sajal
Copy link

sajal commented Sep 3, 2015

When using Dialer.Dial package, I would like to know how long did the DNS queries take to resolve. The reason to know this is because I am building a network debugging tool - TurboBytes Pulse.

My ugly hacky implementation : https://github.com/turbobytes/pulse/blob/master/misc/patch_dialtimer.go

I place the file above inside net package and it provides me the DNS and Connect timings, but it is not nice to ask users of my tool to patch their Go distribution.

I would be nice if Go would provide an alternate Dial method which provides timing data for various steps, as well as some debugging information about DualStack handling, failovers, etc.

Perhaps change Dial's signature to :-

type DialDebugInfo struct {
     DNSTime         time.Duration
     ConnectTime   time.Duration
     //Other fields ...
}

func (d *Dialer) Dial(network, address string, debug *DialDebugInfo) (Conn, error)

If debug is non-nill, then populate it with all sorts of useful information.
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Sep 3, 2015
@ianlancetaylor
Copy link
Contributor

The net package is already far too complex. Currently the net package doesn't provide any timing information at all, so this would add an entirely new kind of API that we would have to support forever. I really don't see this happening.

If you can figure out some way to implement this without making the net package more complex and without changing any of the existing API, please follow the proposal process to suggest it (https://github.com/golang/proposal#readme).

@minux
Copy link
Member

minux commented Sep 3, 2015 via email

@sajal
Copy link
Author

sajal commented Sep 3, 2015

I thought about doing that, but can't. When Dialer.Dial resolves the hostname, it gets all addresses, and tries to fallback to different IP if one of them is not available. It also implements DualStack (Happy eyeballs).

If I resolve by hand, I need to select an IP to connect to, and possibly would have reproduce the complex retry/fallback logic in the net package.

Resolving IP by hand would work if Dialer would have some Dial method which took a list of ips as input instead of single address. Tomorrow, I will make a new issue proposing just that.

@bradfitz
Copy link
Contributor

bradfitz commented Sep 3, 2015

Perhaps net.Dialer could have an optional Resolver, akin to how http.Client has an optional Transport, or http.Server has an optional ErrorLog`, etc.

@sajal
Copy link
Author

sajal commented Sep 4, 2015

The optional Resolver is an excellent idea. It could open up a lot of possibilities. Another (minor) requirement for me is to know which resolver IP was used to resolve the hostname for the connection... Implementing my own Resolver would solve that.

@sajal sajal mentioned this issue Sep 4, 2015
Open
@golang golang locked and limited conversation to collaborators Sep 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@bradfitz @sajal @minux @ianlancetaylor @gopherbot