当 grpc 服务器重复调用 Send 但 grpc 客户端从不调用 Recv 时会发生什么？答案

【问题标题】：What happens when grpc server calls Send repeatedly but grpc client never calls Recv?当 grpc 服务器重复调用 Send 但 grpc 客户端从不调用 Recv 时会发生什么？
【发布时间】：2020-08-14 10:23:43
【问题描述】：

我有一个 grpc 客户端应用程序，它可能会不时阻塞，这会导致它在一段时间内无法调用 grpc Recv 函数。在这种情况下，grpc 服务器上的行为是什么？ grpc 服务器的发送调用是否阻塞？在客户端调用 Recv 之前它会阻塞吗？

【问题讨论】：

请详细说明您面临的问题类型。还要放一些代码让大家看清楚

标签： grpc grpc-go

【解决方案1】：

客户端和服务器可以以任何顺序读取和写入消息，并且完全是特定于应用程序的。因此，回答您的问题时，客户端会阻塞一段时间，超时后消息可能会掉到地板上。

客户端和服务器端流处理是特定于应用程序的。由于两个流是独立的，所以客户端和服务器可以读取并以任何顺序编写消息。例如，服务器可以等到它在写它之前已经收到了一个客户的所有消息消息，或者服务器和客户端可以玩“乒乓”——服务器收到请求，然后发回响应，然后客户端发送基于响应的另一个请求，依此类推。

请参阅 gRPC 官方文档中的解释。还要考虑到特定语言的详细信息，因此请务必查看您选择的语言的参考文档。

https://grpc.io/docs/guides/concepts/#rpc-life-cycle https://grpc.io/docs/guides/concepts/#synchronous-vs-asynchronous

【讨论】：

【解决方案2】：

最终，如果阅读器的阅读速度不如发送者的速度，那么流量控制将启动，发送者将被阻止（直到阅读器阅读更多内容）。

【讨论】：

是否有关于这种行为的进一步文档？