如何取消gRPC bidi流媒体服务器的阻塞Recv（）调用？

Question

在Go语言的gRPC中提供双向流时，规范流处理程序如下所示：

func (s *MyServer) MyBidiRPC(stream somepb.MyServer_MyBidiServer) error {
    for {
        data, err := stream.Recv()
        if err == io.EOF {
            return nil // clean close
        }
        if err != nil {
            return err // some other error
        }
        // do things with data here
    }
}

具体来说，当Bidi RPC的处理程序返回时，即考虑服务器端关闭的信号。

这是一个同步编程模型——在等待来自客户端的消息时，服务器在这个goroutine（由grpc库创建）中保持阻塞状态。

现在，我想取消阻止这个Recv（）调用（最终在底层grpc上调用RecvMsg（）。ServerStream），并返回/关闭流，因为服务器进程已决定使用此客户端完成此操作。

不幸的是，我找不到明显的方法来做到这一点：

• 为我的服务生成的bidi服务器界面上没有类似Close（）或CloseSend（）或CloseRecv（）或Shutdown（）的函数
• 流中的上下文，我可以通过流获取。Context（），不公开用户可访问的取消功能
• 对于grpc接受的新连接，我找不到在“起始端”传递上下文的方法。服务器，在那里我可以插入我自己的取消功能

我可以关闭整个grpc。通过调用Stop（）调用服务器，但这不是我想要做的——只有这个特定的客户端连接（grpc.ServerStream）应该完成。

我可以向客户端发送一条消息，让客户端反过来关闭连接。但是，如果客户端已经脱离网络，这就不起作用了，这将通过超时来解决，超时必须很长才能保持总体健壮。我现在就想要它，因为我没有耐心，更重要的是，在规模上，悬挂无响应的客户端可能是一个很高的成本。

我可以（或许）翻阅grpc。ServerStream和反射，直到我找到transportStream，然后从中找出cancel函数并调用它。或者在溪流中挖掘。带有html" target="_blank">反射的Context（），并进行我自己的cancel函数引用来调用。对于未来的维护人员来说，这两种方法似乎都不可取。

但这些肯定不是唯一的选择吗？决定不再需要连接特定客户端并不是神奇的太空科学。我如何关闭这个流，以便Recv（）从服务器进程端调用un-block，而不涉及到客户端的往返？

Answer 1

不幸的是，我不认为有什么好方法可以满足你的要求。根据你的目标，我认为你有两个选择：

>

在goroutine中运行Recv，并在需要返回时从Bidi处理程序返回。这将关闭上下文并解除屏蔽Recv。这显然是次优的，因为它需要小心，因为您现在有代码在处理程序的执行范围之外执行。然而，这似乎是我能找到的最接近的答案。

如果您试图通过设置超时来减轻行为不端的客户端的影响，那么您可能可以将这项工作转移到具有KeepaliveEnforcementPolicy和/或KeepaliveParams的框架中。如果这与您希望关闭连接的原因一致，那么这可能是更好的选择，但在其他方面没有多大用处。