Re: [grpc-io] Re: grpc stops forward progress if DNS resolve has 0 addresses

['Peter Hurley' via grpc.io]

Thanks for the reply.

> And would it be possible for you to upgrade your gRPC library and try to
reproduce this?
I didn't see any similar issue (marked fixed or not) in
https://github.com/grpc/grpc/issues; we were hoping the community could
confirm whether this has been observed and fixed already but went
unreported in github.

> v1.36.4 is over a year old, and a fair handful of bug fixes have gone in
since then.
We're using the still experimental TLSCredentials so every version bump is
non-trivial, and we've already found fixed a number of core bugs
ourselves, so it'll be a while before we're upgrading again in production.

> Regarding that, are you able to reproduce the conditions in which the
failure occurs, or are they maybe not fully understood? e.g., run a local
DNS server for testing, and modify its records.
Yeah, the exact conditions are not well understood, but almost certainly
happening during a restart of the local caching dnsmasq server due to
intermittent connection loss.


On Fri, Aug 5, 2022 at 8:35 PM 'AJ Heller' via grpc.io <
grpc-io@googlegroups.com> wrote:

> That's mysterious, do you know what the state of the DNS records are when
> this occurs? And would it be possible for you to upgrade your gRPC library
> and try to reproduce this? v1.36.4 is over a year old, and a fair handful
> of bug fixes have gone in since then.
>
> We've been unable to reproduce this failure in testing, and would
>> appreciate any pointers:
>>
>
> Regarding that, are you able to reproduce the conditions in which the
> failure occurs, or are they maybe not fully understood? e.g., run a local
> DNS server for testing, and modify its records.
>
>
>>
>>- what is supposed to re-kick a new DNS resolve if the server list is
>>empty?
>>- where to check in the resolver code for an empty server list?
>>- or any other ideas for how to track down the problem
>>
>>
>> We're using grpc v1.36.4 w/ libcares2 1.14
>>
>> Regards,
>> Peter Hurley
>>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/306779dd-0a68-4b95-851e-0a5979a4e872n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAKzaEUf00rkYWHD6aq1nks8WhVo59wrTcaspkMk2EHUDc1b0JQ%40mail.gmail.com.

[grpc-io] Re: Updates on gRPC C# (Grpc.Core) support

[Ville Vainio]

Just pitching in here that this is super important for us, as we are moving 
from WCF to gRPC specifically to allow gradual movement from legacy .NET to 
NET5+. I considered screaming loudly during the initial announcement, but 
apparently other people did that for me in the meantime ;).

After the maintenance period ends, it would be good to retain a way to make 
a release, in case there are some emergency changes that need to go in (and 
can be done without much effort). Or, there should be a natural way for 
people to make the builds on their own build machines if they need to use a 
self-patched version in their products. 

On Tuesday, May 3, 2022 at 12:25:07 PM UTC+3 Jan Tattermusch wrote:

> Hello gRPC C# Users!
>
> In May 2021 we announced  that 
> Grpc.Core (the original C# implementation of gRPC) became "maintenance 
> only" and that grpc-dotnet will be the recommended implementation going 
> forward. We also announced that Grpc.Core will become deprecated in the 
> future.
>
> While all the above is still the plan, we are making some adjustments 
> based on the user feedback we received. We also wanted to publish more 
> details about the plan and its technical execution. All the important 
> updates are summarized in the following sections of this announcement.
> Grpc.Core maintenance period will be extended by 1 more year (until May 
> 2023)
>
> Originally we planned to deprecate the Grpc.Core implementation in May 
> 2022, but the feedback we received from users has indicated that extending 
> the maintenance period would make sense. Without going too much into the 
> details, the main points of the feedback can be summarized as:
>
>- 
>
>The main blocker for deprecating Grpc.Core is the lack of support of 
>the legacy .NET Framework in grpc-dotnet. The desire to migrate off the 
>legacy .NET framework is often there, but migrating workloads from .NET 
>Framework to .NET Core / .NET 6 simply takes time and effort.
>- 
>
>Grpc.Core is a very important technology for enabling migration off 
>.NET Framework (since it enables piece-by-piece migration by 
>interconnecting components on newer .NET platforms with components that 
>remain on .NET Framework), so supporting it for a little longer can 
>(somewhat paradoxically) help users migrate off it faster.
>
>
> As a result, we are delaying the deprecation of Grpc.Core until May 2023 
> (1 year from now, and 2 years after the original announcement). Until 
> then, Grpc.Core will remain to be supported in the "maintenance mode", as 
> described below.
>
> Since the plan to deprecate Grpc.Core has been now publicly known for a 
> while and since the main reason we are extending the maintenance period is 
> to deal with the issues related to the legacy .NET Framework (and migration 
> off it), we also want to clarify what exactly will be covered by the 
> "Grpc.Core maintenance" going forward:
>
>- 
>
>The main goal of keeping Grpc.Core alive is to maintain the ability to 
>run gRPC C# clients and servers on the legacy .NET Framework on Windows. 
>This will be taken into account when considering issues / fixes.
>- 
>
>We will only provide critical and security fixes going forward. This 
>is to minimize the maintenance costs and reflects the fact that 
> grpc-dotnet 
>is the recommended implementation to use.
>- 
>
>There will be no new features for Grpc.Core. Note that since Grpc.Core 
>is moving to a maintenance branch (see section below), there will also be 
>no new features coming from the native C-core layer.
>- 
>
>There will be no new platform support and portability work. The focus 
>will be on continuing support for the legacy .NET Framework on Windows 
>(where there is no alternative implementation to use) and the list of 
>supported platforms will not be expanded (e.g. we will not work towards 
>better support for Unity, Xamarin, Alpine Linux etc.). We will likely drop 
>support for platforms that have been so far considered as "experimental"  
>(e.g. Unity and Xamarin), since they are also hard to test and maintain.
>- 
>
>Work to support new .NET versions (.NET6, NET 7, …) will be kept to a 
>minimum (or not done at all) since those .NET versions fully support 
>grpc-dotnet.
>- 
>
>No more performance work: Since the main purpose of Grpc.Core is to 
>maintain interoperability with legacy .NET framework, there will be less 
>focus on performance. We do not expect any significant performance drops, 
>but performance may degrade over time if tradeoffs between performance vs 
>maintainability are needed.
>
>
> Grpc.Core moves to a maintenance branch in the grpc/grpc repository (while 
> other actively developed packages move to grpc/grpc-dotnet repository)
>
> To simplify the maintenance of Grpc.Core, 

[grpc-io] Re: gRPC C++ how to enforce different authentication for methods in same service

[Philipp T]

>How are those authorized people identified? Authorization requires user 
authentication and it is best done with mTLS.

At the moment im using a self signed certificate to authenticate those who 
should have access to the *YouNeedCreds* method

On Monday, 1 August 2022 at 19:20:43 UTC+2 sanjay...@google.com wrote:

> > but make some functions accessible to specific people
>
> How are those authorized people identified? Authorization requires user 
> authentication and it is best done with mTLS.
>
> > and encrypt the traffic for specific RPCs. 
>
> All traffic can be encrypted even when you don't want to enforce user 
> authorization for other RPCs. I don't see a requirement for plaintext 
> communication for certain RPCs.
>
> On Saturday, July 30, 2022 at 7:16:01 AM UTC-7 Philipp T wrote:
>
>> Hey thanks for your reply.
>>
>> Off the top of my head I could think of the following use-case. 
>>
>> I have a service running on a pie which I use to control my lights. The 
>> service has 3 functions, IsLightActive(), TunLightOn() and TurnLightOff. I 
>> should be the only person who can call TurnLightOn() and TurnLightOff() and 
>> the traffic should be encrypted (because lets say I dont want people to 
>> know what the proto message looks like). On the other hand, anyone should 
>> be able to call IsLightOn() regardless of who they are and there is no need 
>> to encrypt the traffic. 
>>
>> Basically I want to use a single service, but make some functions 
>> accessible to specific people and encrypt the traffic for specific RPCs. 
>>
>> Thanks :)
>>
>> On Wednesday, 27 July 2022 at 20:21:25 UTC+2 sanjay...@google.com wrote:
>>
>>> > on how this works in C++ (how do you actually read this file so that 
>>> the gRPC service applies the configurations), 
>>>
>>> Check this out 
>>> https://github.com/grpc/proposal/blob/master/A2-service-configs-in-dns.md
>>>
>>> > *a single service where different PRCs have varying authentication 
>>> requirements,*
>>>
>>> Do you really mean authentication requirements or authorization 
>>> requirements? Can you give a concrete use-case? Authentication is at 
>>> connection level and then you can use gRPC Authorization API (
>>> https://github.com/grpc/proposal/blob/master/A43-grpc-authorization-api.md
>>> )
>>>
>>> On Saturday, July 23, 2022 at 12:59:54 PM UTC+5:30 Philipp T wrote:
>>>
 Hello, Im pretty new to gRPC but I was wondering if the following is 
 possible

 I have a proto file which contains a single service with two RPCs which 
 looks as follows:

 *service MyService {*
 *// This function requires credentials*
 *rpc YouNeedCreds(Empty) returns (Empty) {}*

 *// This function should be callable by anyone without credentials*
 *rpc NoCredentialsNeeded(Empty) returns (Empty) {}*
 *}*

 *My question is, is it possible, using C++ to have a single service 
 where different PRCs have varying authentication requirements, without 
 having to deploy to something like google cloud (I just want to run it 
 between 2 computers on the same network)? *

 I have seen references to using .yaml files to configure services (like 
 this one 
 ),
  
 but I have not found any examples on how this works in C++ (how do you 
 actually read this file so that the gRPC service applies the 
 configurations), and I don't intend on deploying this on google cloud. I 
 just want to run this on my local network and use the device IP to connect 
 to the service. 

 At the moment I create the server by creating using 
 grpc::SslSecureCredentials and passing them to the .AddListeningPort 
 method 
 provided by the grpc::ServerBuilder.

 Hopefully this is somewhat helpful, thanks in advanced for.

>>>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/50a8a064-786f-48f6-b405-bc5ada2990a9n%40googlegroups.com.

[grpc-io] failover when Deadline Exceeded

[Damon Lee]

Hi, 
I faced the issue that
when the server cannot communicate with infras(db, kafka, ...)
the client receives deadline exceed error and does not run failover as the 
failover is triggered only when the server is not connectable. 

I want to close the connection with deadline exceed and connect to another 
server ready for failover. 

As I think there are two options, but not quite great. 
1. error check for deadline exceed for all client grpc codes
2. server close connection faster than deadline exceed 

Is it possible to trigger failover when deadline exceed triggered as the 
connection closed? what about a custom loadbalancer? 

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/4eabfc56-f65a-43f9-9778-82dfc4128a20n%40googlegroups.com.