When using streams in GRPC (Swift), is there any guarantee about the delivery of individual messages within the stream?
Let's say as a client I stream messages to the server, do I know if the server has correctly received (and processed) the message? Or would I need to implement my own ack system and stop sending new data before I did not get some ack back for previous messages? Seems like reinventing TCP...
There is no ACK system, and reinventing TCP would always be necessary. TCP tells you that the other side has received the message, but not that it processed it. A "process complete" message always requires a specific acknowledgement, and grpc doesn't provide a specific mechanism for this.
Thanks, Cory!
Seems like at least the Java implementation has some support for flow control on streams?
Another way to phrase this, is that only the entity that knows when processing is complete semantically is able to provide such an ack with any real meaning.
This would by definition be the application layer.
A good way to think of it is that the server needs to perform some additional asynchronous task before having completed the request, only the server will know when that is done.
Flow control is not acknowledgement of processing. And HTTP/2 flow control, which gRPC uses, is definitely not that as it works in terms of windows, so there is no sense in which anything is acknowledged.
Yes, thanks. I was thinking the same, but I got confused by this sentence from the docs:
gRPC utilizes the underlying transport to detect when it is safe to send more data. As data is read on the receiving side, an acknowledgement is returned to the sender letting it know that the receiver has more capacity.
So here, "acknowledgement" really just means the message was written so some buffer on the receiver, but not that the receiver has successfully read the message from the buffer.
Correct. This is a backpressure & flow control mechanism, not a reliability one.