-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
proposal: net: should provide an interface for dialing #9360
Comments
It's the same issue as with Resolver field of default Dialer, it should be an interface |
Dialer probably should continue to be a concrete type - the whole point is to expose control over the configuration settings in the struct. But any APIs that are written to take a Dialer only for the ability to Dial should probably take an interface that Dialer satisfies instead (or just a func). |
Agree with @rsc: we should have a concrete |
This would allow "mocking" the TCP stack and reproducing low-level error conditions for other network packages (think about SSH control flow and other protocols), definitely a nice addition. |
Data point: in the meantime some of us use interfaces like xnet.Networker to Dial/Listen with plain TCP or TLS/TCP or other networks in uniform way. |
I'd like to DialWithDialer using a dialer provided by ipsn/go-libtor and cretz/bine, or just a x/net/proxy.Dialer would already be a start. Would a patch be welcome that defines a tls.Dialer interface and uses that for DialWithDialer, as @rsc suggests above? I guess the Timeout and Deadline usage could be guarded behind a type assertion? It would be lovely to have tls/crypto decoupled from TCP! :) |
Yeah, this thing would be good. |
Looking at this issue again, it's rather vague. If someone can define a clear new API to implement in the net package or elsewhere, that would be helpful. |
net.Dialer sounds like it's close to making transports pluggable the way e.g. http.Client / http.Transport behave, but reading further one realizes that net.Dialer is hardcoded to basically be net.Dial with timeouts. This makes e.g. crypto/tls DialWithDialer less useful; I can't just easily replace the whole transport layer with something that e.g. doesn't touch the host TCP stack (think unit tests, Tor, stream protocols constructed on top of UDP, and such).
Note that tls.DialWithDialer doesn't just dialer.Dial, it also accesses the Timeout field. By the time Go2 comes around, maybe /x/net/context will have grown into something that can unify this sort of behavior.
Of course, the workaround is to dial manually and use tls.Client, but then one is responsible for all the little details that are inside tls.DialWithDialer.
Naturally, I don't expect Go1 to change existing APIs, though something new might be workable. Sorry for the ramble, just felt like writing down my hopes of reusability being crushed.
The text was updated successfully, but these errors were encountered: