Using DNS Authority in C# client

[Duncan Mole]

Hi,

I am pretty new to gRPC so apologies if this information is already in the public domain and I have just failed to find it. I am looking at the DNS Authority syntax defined here: https://github.com/grpc/grpc/blob/master/doc/naming.md and trying to get it working with the C# client.

If I could get this working it would be a massive boon for us, allowing us to utilise an existing Consul cluster which already does health checking as a full blown service catalgue. I have tested with the GRPC nuget package 1.7.1 (and 1.8.0-pre) and it seems impossible to get it working. From what I have read, it is implemented in the newer resolver c-ares DNS resolver. As setting the environment variable GRPC_DNS_RESOLVER to 'ares' seems to have no effect (confirmed by log line "dns_resolver.cc:307: Using native dns resolver"), I presume the native build of Core provided with the nuget packages does not have the c-ares resolver enabled?

Is this Core functionality to be exposed via the C# API anytime soon? Or is it already there and I am just not using the correct magic incantation?

Thanks for any help and info

Duncan

[Duncan Mole]

I guess this unmerged PR is a pre-req: https://github.com/grpc/grpc/pull/12416 ??

[falco...@gmail.com]

AFAIK, c-ares should work on linux using the env flag, but for windows it still needs the PR you mentioned to get merged. Your best option would be to add a custom resolver in C++ which is then also available in C#. I run into the same problem and tried to solve it on a similar level, by adding a resolver for GRPCLB without the DNS layer. I also thought about doing it with Consul and adding a resolver, but found it easier to just implement the GRPCLB interface in C# since I then can have everything in one executable. Since the C# implementation is relying on the C core resolvers, I can now just use "grpclb://<ip_of_grpclb>:<port_of_grpclb>/<endpointname>".

I have made that public in this PR: https://github.com/grpc/grpc/pull/13639

I don't yet know if the team even likes to add that, but since c-ares is still lacking under windows and since there is no resolver support in C# directly, this seemed like the best option right now, since you can make a very low-level implementation of GRPCLB, just using it like a DNS server and later improve it or replace it with real load balancing strategies.

[falco...@gmail.com]

I just forgot to write the main idea I wanted to write... Sorry, still a bit tired...

For the time until c-ares is merged, you could use the version from my PR and doing a simple GRPCLB implementation in C# that is just interacting with the HTTP interface from consul. Just to get things going and use the infrastructure you already have. And once c-ares is merged, swap to the native implementation by just removing the "grpclb://" part. Not sure if grpc is falling back onto DNS right now in case the scheme is unknown or if GRPCLB is not answering.

[Duncan Mole]

Thanks for these posts. I think I understand the direction you are pointing me in. I will have a play and see if I can get it working with your PR. 

Any word from the team on when the c-ares resolver will be merged? Or is that the sosrt of thing I ought to ask in the mmunity meeeting?

[falco...@gmail.com]

Just because it's related, I have an open issue (Name resolver support for C# missing) which also has all those links in it and which I use for keeping this topic together and up2date. So you could subscribe to it to be notified when there is a good option in addition to Making c-ares work under Windows.

And another thing I'm impatiently waiting for is Support for interceptors in C#. So in case you need to do something like logging, this issue could also be of interest to you.

Other then that, I'm also hoping there will be an information about the roadmap of those issues :)

[Duncan Mole]

Thanks for the links. I had actually come across them yesterday as I was trying to get up to speed with this stuff yesterday. I think I will add someting to the agenda of the next community meeting rather than demanding timelines on the PR which seems kind of pushy :-)

Regarding interceptors - I am lucky here as we have our own service DSL->code genning tool (I am swapping out an old transport for gPRC) so I can weave logging and JWT based authorisation pretty easily. Interceptors might make the genned code prettier but it'd really be aethestics at this point.

[Duncan Mole]

After playing with your PR a bit it seems it is *exactly* what I need. As we have a blue/green deployment, resolving addresses for external clients involves first looking up the live colour.

Thanks again for your help on this.

On Wednesday, 6 December 2017 09:32:28 UTC+1, falco...@gmail.com wrote:

[falco...@gmail.com]

Glad I could help you :) I hope that they mind adding it into master. It makes deployment and management of simple infrastructures so much easier if you don't have to also care about DNS.

I'm using the NuGet-Package Grpc.HealthCheck for health-checking right now. Every GRPC service registered to the GRPCLB is offering that service showing the health of all the services + a generic health. The GRPCLB itself is also implementing the health service, but showing if the endpoint in total is healthy (at least one endpoint is servicing the service name with a good generic health response). This is done as periodic task which is just requesting the health service of the endpoints. Since you already have service health in consul this should be even easier for you to do :)

[Duncan Mole]

Cool. I will take a look at the stuff next.

[falco...@gmail.com]

This could also interest you: https://github.com/bsm/grpclb

It's a GRPCLB implementation that already has a Consul backend implementation.

[Duncan Mole]

Yeah. Could be a good source of inspiration once I learn how to grok Go ;-)

Thanks

[coder...@gmail.com]

Hi Benjamin,

sorry for hijacking this old thread, I understood about your point regarding adding own resolver. I have wrote my own resolver in cpp and now I am using `GRPC_DNS_RESOLVER ` to tell the gRPC to pick my resolver. But I gRPC is not picking the resolver, it is always `native`. Do you know why ?

[Benjamin Krämer]

You would also have to register the resolver. You can have a look at my PR that wasn't merged yet since it's still undecided how the API should look like:

https://github.com/grpc/grpc/pull/13639/files

[Benjamin Krämer]

Please make sure to use „Reply to all“ to also include the mailing group. I don’t know what exactly might be the problem. I hope someone else on here can help you by forwarding your reply back to the list.

Am 10.09.2018 um 16:47 schrieb Harish Gangaraju <coder...@gmail.com>:

Thanks a lot for the reply.

I have made both secure and unsecure registrations, just like your PR, but when I run my client app I just see call to `\grpc\src\grpc\src\core\ext\filters\client_channel\resolver\dns\native\dns_resolver.cc`. I have kept my resolver in a seperate directory under `\grpc\src\grpc\src\core\ext\filters\client_channel\resolver\dns\`. 

I know that we have to make a change to the scheme (which basically tells which resolver to pick), but I don't know where exactly. If you know then PLMK.

Thnaks

On Mon, Sep 10, 2018 at 4:23 PM Benjamin Krämer <falco...@gmail.com> wrote:

You would also have to register the resolver. You can have a look at my PR that wasn't merged yet since it's still undecided how the API should look like:

https://github.com/grpc/grpc/pull/13639/files

--
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/wG0Anut5foA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/34634d80-bf2c-419f-bd9f-b19a8c3acf87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Benjamin Krämer]

I just remember one part that you may do wrong or forgot to change. Please have a look here: https://github.com/grpc/grpc/pull/13639/files#diff-95a6267c94be812577498d9af5749732R301

This includes information on what scheme to register. The last thing in line #301 is the "grpclb". What have you written there in your resolver? I'm not sure if you can overwrite the dns:// and default schema, but by writing anything there (like I did with "grpclb") you can create a new scheme to use. So when defining your channel and want to use your DNS resolver (in this case labeled "grpclb") you can use "grpclb://<authority-ip>:<authority-port>/<endpoint>" or "grpclb://<endpoint>" instead of just "<endpoint>" to use it.