Consider deprecating Dial and DialContext and replacing with a NewClient

[dfawley]

Dial and DialContext have several differences from how gRPC works in other languages. A NewClient function that works more like other languages would differ in at least two ways:

1. Default to DNS resolver instead of passthrough.
2. Make target compliant with RFC 3986 (Revise URI scheme parsing to be RFC 3986 compliant #1911).
3. Start IDLE instead of CONNECTING.

If we create a NewClient, we'd probably also want to make matching ClientOptions instead of DialOptions, as some DialOptions (e.g. WithBlock or WithTimeout) do not make sense when not dialing synchronously.

[nhooyr]

Default to DNS resolver instead of passthrough.

Could you elaborate on what passthrough would be? Wouldn't all Dial's use a DNS resolver?

[dfawley]

Passthrough sends the entire target string (after "passthrough:///") to the dialer as the address, verbatim.

A DNS resolver would resolve the target (after "dns:///"), turn it into IP addresses & ports, and those would be handed to the dialer.

It just so happens that the default dialer (net.Dial) is able to do DNS name resolution, and so passing "google.com:22" will work just fine with it.

However, this passthrough method means we can't do things like load-balance across all the DNS results for that name.

You can see more about the resolver/balancer design in the gRFC here: https://github.com/grpc/proposal/blob/master/L9-go-resolver-balancer-API.md

[raphoester]

Hello guys, I notice that the DialContext method is now deprecated
I was using it a lot for my tests that included the presentation layer, eg :

conn, err := grpc.DialContext(
		context.Background(), "bufnet",
		grpc.WithContextDialer(
			func(context.Context, string) (net.Conn, error) {
				return s.lis.Dial()
			},
		),
		grpc.WithTransportCredentials(insecure.NewCredentials()),
	)
	// then create the client using the new conn
	client := someservice.NewSomeServiceClient(conn)

I tried replacing DialContext with NewClient, e.g :

conn, err := grpc.NewClient(
		"passthrough", // ?
		grpc.WithContextDialer(
			func(context.Context, string) (net.Conn, error) {
				return s.lis.Dial()
			},
		),
		grpc.WithTransportCredentials(insecure.NewCredentials()),
	)

But now i get a DNS error on RPC call from the client : rpc error: code = Unavailable desc = name resolver error: produced zero addresses

Can you please tell me where there is a doc to properly transition this use case ? thanks

[bcessa]

Hi @raphoester, in case you are still having this issue I solve it by setting
the default resolver scheme in my test files.

// set the default resolver schema to "passthrough" to prevent DNS resolution
// issues while testing; the default scheme used by grpc.NewClient is "dns".
func init() {
    resolver.SetDefaultScheme("passthrough")
}

This way you can prevent the DNS issues when replacing Dial for NewClient. In my tests I'm using a dialer similar to yours:

withDialer := func(l *bufconn.Listener) gRPC.DialOption {
    return gRPC.WithContextDialer(func(context.Context, string) (net.Conn, error) {
        return l.Dial()
    })
}

[ash2k]

This should work:

conn, err := grpc.NewClient(
		"passthrough:whatever",
		grpc.WithContextDialer(
			func(context.Context, string) (net.Conn, error) {
				return s.lis.Dial()
			},
		),
		grpc.WithTransportCredentials(insecure.NewCredentials()),
	)

I don't know why, but https://github.com/grpc/grpc/blob/master/doc/naming.md doesn't describe passthrough.

[atollena]

I don't know why, but https://github.com/grpc/grpc/blob/master/doc/naming.md doesn't describe passthrough.

This is because passthrough is go specific and does not exist in other implementations, including C and Java. This is also the reason for making NewClient use DNS by default. Ideally passthrough wouldn't exist and dns would be the default in Go even for Dial/DialContext, but this would be a breaking change that is not worth the trouble at this point.

[ash2k]

This is because passthrough is go specific and does not exist in other implementations, including C and Java.

I wonder how other implementations deal with cases where you don't want dns resolution at all. I.e. when you use a dialer that does something special like opening an in-memory pipe to a server. passthrough is the way to go here and that's what I use.

This is also the reason for making NewClient use DNS by default.

I think this makes sense. I also like that NewClient() doesn't start connecting to the server straight away.

[dfawley]

The other languages have a real in-memory transport that they support. I believe C++ uses a separate resolver, and Java uses a completely different channel builder (i.e. they don't pass a target string at all).

For Go, I'd love to one day add support for other transports besides HTTP/2 (#906). An "inmemory" transport would come with an "inmemory" resolver that you'd specify as the scheme for the channel and emit a single "inmemory" address to connect to.

The bufconn was never really intended for end users, BTW. Just for our internal testing. :)

[ash2k]

For anyone who might need something like this - I have this implementation. It's a net.Listener + dialer (DialContext()) so you can connect a server and a client(s) via net.Pipe(). No buffering is done. Anyway, sorry for off topic.

[puneet-traceable]

Is this change compatible with forward-proxies?
I see a difference in cases when forward-proxies allow/block based on hostnames to connect to upstream servers.
When I use NewClient instead on Dial the domain is resolved upfront and only resolved ip is sent as target, so the proxy is not able to correctly apply these policies.
Attach a tcpdump screenshot

What is the best to change the behaviour back?

[dfawley]

@puneet-traceable can you file a new issue for this please?

[puneet-traceable]

@puneet-traceable can you file a new issue for this please?

Filed a new one #7556