TCP sessions with gRPC

Question

Sorry if this question is naive. (gRPC novice here). But, I would like to understand this.

Let's say I have a gRPC service definition like this:

service ABC {
  // Update one or more entities.
  rpc Write(WriteRequest) returns (WriteResponse) {
  }
  // Read one or more entities.
  rpc Read(ReadRequest) returns (stream ReadResponse) 
  {
  }
  // Represents the bidirectional stream 
  rpc StreamChannel(stream StreamMessageRequest)
      returns (stream StreamMessageResponse) {
  }
}

Our potential use case would be the server built using C++ and the client using Java. (Not sure is that matters).

I would like to understand how the TCP sessions are managed. The Stream Channel would be used for constant telemetry data streaming between the client and the server. (Constant data transfer, but the bulk from the server to the client).

Does the StreamChannel have a separate TCP session, while for every Write and Read a new session would be established and terminated after the call is done?

Or is there a single TCP session over which all the communication happens?

Again, please excuse me if this is very naive.

Thanks for your time.

Answer 1

Since gRPC uses HTTP/2, it can multiplex multiple RPCs on the same TCP connection. The Channel abstraction in gRPC lets gRPC make connection decisions without the application needing to be strongly-aware.

By default, gRPC uses the "pick first" load balancing policy, which will use a single connection to the backend. All new RPCs would go over that connection.

Connections may die (due to I/O failures) or need to be shut down (various reasons), so gRPC handles reconnecting automatically. Because it can take a very long time to shut down a connection (as gRPC waits for RPCs on that connection to complete), it's still possible that gRPC would have 2 or more connections to the same backend.

So for your case, all the RPCs would initially exist on the same connection. As time goes on new RPCs may use a newer connection, and an old, long-lived StreamChannel RPC may keep the initial TCP connection alive. If that long-lived StreamChannel is closed and re-created by the application, then it could share the newer connection again.

Answer 2

I also posted the same question in grpc.io, and the response I got was inline with the marked answer. Summary: If there is no load-balancing, all the RPCs use the same session. The session remains connected across requests. The session establishment happens the first time a call is attempted on the channel.