Closed JamesNK closed 1 year ago
@JamesNK as this is parented by a Theme, perhaps it should be an Epic (or be under a gRPC epic)
Same parent as https://github.com/dotnet/core/issues/5493 perhaps.
@JamesNK any requirements on the client networking stack here?
@JamesNK any requirements on the client networking stack here?
I'm pretty sure there will be. Post 5.0 release I'll talk to @karelz about it
@JamesNK it would be good to now gain clarity here on libraries asks.
@danmosemsft I've created an issue about the big System.Net.Http feature required here - https://github.com/dotnet/runtime/issues/45246
Will discuss with @karelz @scalablecory @geoffkizer.
Bulk closing .NET 6 epics and user stories. If you think this issue was closed in error, please reopen the issue and update it accordingly.
Some load balancers don't work effectively with gRPC. L4 (transport) load balancers operate at a connection level, by distributing TCP connections across endpoints. Because gRPC calls happen on a single connection, all load gets sent to one server.
An example of this issue is Kubernetes. If a pod has multiple replicas, the gRPC connection will be made to one pod replica, and all calls will go to that pod replica. gRPC with default Kubernetes load balancing is broken.
There are two options to effectively load balance gRPC:
Proxy load balancing works today with gRPC in .NET. A lot of people will choose this option. However a proxy introduces complexity and performance penalties. Many customers have asked for support for client-side load balancing.
Other first-class gRPC implementations support client-side load balancing (grpc-go, grpc-java, C++). grpc-dotnet would aim to provide equivalent functionality.
Note: Changes to HttpClient maybe required to properly support client-side load balancing.
Reasons for client-side load balancing:
Dev features/work: