client: detect max_concurrent_streams coming from the server

[ChuntaoLu]

Pretty much the same question as in #3127, is it still not possible today? Tagging @dfawley for historical context.

[dfawley]

Yes, same answer... We do have a sketch of a design to incorporate the max streams information in gRPC to create new connections when it's blocked on max streams, but it's not a high priority for us right now.

What is your use case / why do you need this information?

[ChuntaoLu]

What is your use case / why do you need this information?

My use case is that the server sets a value, and requests can queue up on client side when traffic volume is high enough. We want to have a connection pool where each connection doesn't have more concurrent streams than what server sets.

[dfawley]

That sounds similar to the situation that prompted the design mentioned above. Can you give us any more information on your system / constraints? E.g.s:

• Are you connecting through a reverse proxy?
• Do you also run the servers in question or are they owned by a third party?
• What kind of MAX_CONCURRENT_STREAMS settings are you seeing when you are throttled (are they limiting to an especially low value or using the default settings)?
• Are you mostly making unary RPCs?
• Do you use any long-running/indefinite streams?
• What would you do if we provided the max streams information? E.g. would you just create more connections to the same address, or would you connect to new addresses?

Thanks!

[ChuntaoLu]

• Are you connecting through a reverse proxy?

Yes

• Do you also run the servers in question or are they owned by a third party?

Third party.

• What kind of MAX_CONCURRENT_STREAMS settings are you seeing when you are throttled (are they limiting to an especially low value or using the default settings)?

It seems to be static at 128, but I am not very certain about that.

• Are you mostly making unary RPCs?

Yes

• Do you use any long-running/indefinite streams?

No

• What would you do if we provided the max streams information? E.g. would you just create more connections to the same address, or would you connect to new addresses?

We will keep track of the concurrent streams on a given connection so that it won't reach the limit. If it reaches the limit, we create new connections to the same address.

[github-actions]

This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.

[ChuntaoLu]

This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.

#6576 (comment)

[dfawley]

Thank you for the info. It seems like your use case would be satisfied by design I was alluding to, and it does come up periodically, but unfortunately it is not currently a priority for the team. Let's fold this under grpc/grpc#21386 as it would require a cross-language effort to implement.

FWIW there's an implementation in google's cloud client libraries that can do connection pooling, which may be of interest to you:

https://github.com/googleapis/google-api-go-client/blob/caea95689f82049822552cd649765335123831e0/transport/grpc/pool.go#L30