What happens when grpc server calls Send repeatedly but grpc client never calls Recv?

Question

I have a grpc client application that might block from time to time which results in a situation where it would be unable to call the grpc Recv function for a while. What is the behavior seen on the grpc server in this situation? Does the grpc server's Send call block? Does it block until the Recv is called on the client?

Answer 1

The client and server can read and write messages in any order, and it is completely application specific. So answering your question, it the client blocks for a while, probably the message get dropped in the floor after a timeout.

Client- and server-side stream processing is application specific. Since the two streams are independent, the client and server can read and write messages in any order. For example, a server can wait until it has received all of a client’s messages before writing its messages, or the server and client can play “ping-pong” – the server gets a request, then sends back a response, then the client sends another request based on the response, and so on.

See how it is explained in the gRPC official documentation. Also take into account that there are language-specific details, so make sure you check the reference documentation for your language of choice.

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

Answer 2

And eventually if the reader is not reading as fast the sending is sending, flow control will kick in and the sender will be blocked (until the reader reads more).