Thanks for the feedback. I will look into writing a resolver and do a PR, since I have seen others with similar needs. In Java it's pretty easy to do what I planed, so maybe it helps others in the C++/C# world too. The nice thing is, that when it's done as resolver in core, it's also usable from C# without any needs of changing the C# implementation.
Once c-ares works with windows, I could change my gRPCLB endpoint into a DNS server if I don't need load balacing, right? But since I need both, I would then still need to add DNS information pointing to the gRPCLB endpoint for the load balancing and in the gRPCLB endpoint manage my services available. So for my use case, I think the name resolver will even then be the better option when I know the gRPCLB endpoint will not change. Am Dienstag, 14. November 2017 01:50:06 UTC+1 schrieb David Garcia Quintas: > > Well, it may be that c-ares finally works on windows (worth a nudge on > https://github.com/grpc/grpc/pull/12416). Barring that, or until that > happens, you have two options, both non-trivial and requiring playing with > and building the c-core code: > > - (HACK HACK HACK) Modify the logic around here > <https://github.com/grpc/grpc/blob/b0bad8f3864dc9c8745736fe68efe513b2b84932/src/core/ext/filters/client_channel/client_channel.cc#L419> > to > enable gRPCLB based on any condition you like. This is evil and of course > not officially supported :) > - Write custom name resolver for the C Core. Something we've been wanting > to do for a while is expose a semi-public API to implement custom resolvers > (still in the core, in C/C++) but haven't gotten around to doing it. Given > that your needs revolve around DNS, you wouldn't have to start from > scratch. Simply copy dns_resolver.cc, rename it and hack it up in any way > you need, then enable it for you deployment (in the same way that the > standard DNS resolver is registered. I/we can help you with this). While we > don't have a public resolver API, the current one hasn't changed in quite a > while, so having your needs encapsulated in your custom resolver would be > the cleanest and more future-proof way of doing things. > > On Monday, 13 November 2017 15:27:13 UTC-8, [email protected] wrote: >> >> If done at the application level (like I do it right now due to no other >> options), I lose every benefit of the channels like rediscovery in case the >> endpoint changes (which can and will happen). Instead it will try to >> reconnect to the old endpoint, waiting for it to return, which will not >> happen. That’s why I hoped to use the existing core features of gRPCLB. >> >> The only service with fixed port is my main service which right now works >> as nameservice and manages my modules. > > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. 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/8e481de7-0f30-49ec-ace9-4d6d300988b0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
