Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add some form of connection manager for the client #29

Open
lucasdicioccio opened this issue Jun 10, 2020 · 1 comment
Open

Add some form of connection manager for the client #29

lucasdicioccio opened this issue Jun 10, 2020 · 1 comment

Comments

@lucasdicioccio
Copy link
Member

This feature could be implemented in http2-client as well but for some context: typical usage of gRPC is for microservices within datacenters, where endpoints are replicated. The current design sticks all gRPC calls on a same http2 connection (hence, on a same TCP connection -- and if this connection crashes then the programmers as to restart a client passing all the parameters again). It would be nice to support some sort of connection-managers for balancing all RPCs over multiple http2 sessions (with some programmable control over how to pick a session, how many sessions to open etc.)

@greglaun
Copy link

The solution to this is largely specified by the gRPC design. The state machine tracking this information for a channel is specified in https://grpc.github.io/grpc/core/md_doc_connectivity-semantics-and-api.html.

gRPC has a "channel", which is a virtual connection to the an endpoint. An endpoint may be served by many servers. Channels have "subchannels", which are logical connections to a server. The subchannel maintains the actual TCP connection. If a channel dies, there is standard logic to either choose another subchannel, or to repair the connection.

When gRPC does reconnect, it uses an exponential backoff aproach described here: https://grpc.github.io/grpc/core/md_doc_connection-backoff.html.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants