英文:
What is the effect of GRPC keepalive mechanism on the client program behavior?
问题
我有一个grpc异步客户端实现，通过流从服务器接收数据。
在设置与服务器的grpc::Channel之后，我会定期查询通道状态，使用grpc::Channel::GetState(false)。如果状态不是GRPC_CHANNEL_READY，我会确定与服务器的连接已丢失。
我怀疑grpc::Channel::GetState不总是可靠工作（在服务器流传输期间我看到了许多丢失的数据包）。
我想尝试grpc的保持活动机制。但是，除了如何设置它，我没有从文档中理解它会如何影响现有的代码行为。我的意思是 - 它确切地做什么？grpc::Channel::GetState会有不同的行为吗？我如何查询保持活动的ping pong状态？
英文:
I have a grpc async client implementation that receives data from the server via a stream.
After setting up a grpc::Channel to the server, I periodically query the channel state via grpc::Channel::GetState(false). If the state is not GRPC_CHANNEL_READY I determine the connection to the server is lost.
I have a suspicion that grpc::Channel::GetState does not always work reliably (I am witnessing a lot of lost packets during Server streaming).
My thought was to try out grpc keepalive mechanism. However, beside how to set it up, I did not understand from the documentation how will it affect existing code behavior. I mean - what does it do exactly? Will grpc::Channel::GetState behave differently? How can I query the status of the keepalive ping pong?
答案1
得分: 1
启用保持活动状态（keepalive）后，GetState 不会表现出不同的行为。
保持活动状态的作用是，当您有一个未完成的RPC调用时，它会每 GRPC_ARG_KEEPALIVE_TIME_MS 毫秒发送一个HTTP2 PING帧，并等待 GRPC_ARG_KEEPALIVE_TIMEOUT_MS 毫秒内收到一个ACK PING帧。如果在此时间内未收到ACK PING帧，它将关闭连接，该连接上的所有RPC调用都将失败（并可能会重试）。当发起重试（或任何新调用）时，将重新建立连接（除非选择了另一个现有连接）。因此，您无需查询保持活动状态ping pong的状态。
GRPC_ARG_KEEPALIVE_PERMIT_WITHOUT_CALLS 即使没有任何正在进行的调用，也会启用ping，但服务器可能不允许这样做。请确保客户端端的保持活动状态配置与服务器端保持同步。否则，服务器可能会在收到一定数量的意外ping后启动关闭连接。
请注意，保持活动状态是逐跳的，因此如果您有一个http2代理，它只会测试与代理的连接性，必须在代理上配置保持活动状态以测试下一跳。
英文:
With enabling the keepalive, the GetState will not behave differently.
What keepalive does is when you have an unfinished RPC call it will send an HTTP2 PING frame every GRPC_ARG_KEEPALIVE_TIME_MS and wait for an ACK PING frame for GRPC_ARG_KEEPALIVE_TIMEOUT_MS. If no ack ping is received within this time it will close the connection and all RPC calls on that connection will fail (and may be retried). When a retry (or any new call) is issued, a connection will be re-established (unless another existing connection is picked). So you don't need to query the status of keep alive ping pong.
GRPC_ARG_KEEPALIVE_PERMIT_WITHOUT_CALLS enables ping even when you don't have any calls in-flight, but server may not allow that. Make sure that client side keepalive configuration is in sync with the server side. Otherwise, server may initiate closing connection after getting some amount of unexpected pings.
Please note that keepalive is hop by hop, so if you have an http2 proxy it will only test connectivity to the proxy and keepalive must be configured on the proxy too to test the next hop.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论