A few confusing questions about the grpc stream

[yihao yang]

Hi,

I have some confusing questions about the grpc stream. Hope some one can help.

1. For example of sync stream. Does the client/server side send() mean the message is sent out to the network card? Is it possible that the sent out msg get lost and the sender don't know it?
2. Is it possible that a send() failed but the receiver receives the message later on?
3. When a send() or recv() failed, is it ok to re-issue the send() and recv() function and will the following send()s and recv()s succeed?
4. Is it possible that the recv() hangs and actually the sender side has network partition with the receiver? Does stream have a timeout?
5. How grpc::channel detect the connection_state change?

I am using both grpc-go and grpc-c++. I think they may have some differences on the behaviors. 

Thanks,

Yihao

[Josh Humphries]

On Sat, Aug 26, 2017 at 2:09 AM, yihao yang <yangyi...@gmail.com> wrote:

Hi,

I have some confusing questions about the grpc stream. Hope some one can help.

1. For example of sync stream. Does the client/server side send() mean the message is sent out to the network card? Is it possible that the sent out msg get lost and the sender don't know it?

HTTP/2 supports flow control to effectively limit the rate of sending messages. This is handled transparently in GRPC. This differs from language to language. Go will block until the message is sent. Java (whose APIs are all async/non-blocking) will buffer the message in the sender side in memory, but exposes optional API for interacting with flow control (which allows code to effectively wait until the receiver is ready and the message can actually be sent).

1. Is it possible that a send() failed but the receiver receives the message later on?

No. When send() fails, it is because the stream is broken. The stream can no longer be used. 

1. When a send() or recv() failed, is it ok to re-issue the send() and recv() function and will the following send()s and recv()s succeed?

No. After a streaming method fails, the stream is broken. To re-try, the caller must re-issue the stream invocation and potentially re-send (and re-receive) all messages in the stream. The actual logic will depend on the spec (or implementation details) of the server's stream handler -- what it does when a stream is aborted with the messages it has already received, etc. 

1. Is it possible that the recv() hangs and actually the sender side has network partition with the receiver? Does stream have a timeout?

Yes, this is possible. I think many runtimes now support "keep alives" (which can use HTTP/2 ping frames vs. TCP keep-alive packets) to detect this condition. Also, a stream can have a timeout, but the timeout is not for a single send or receive operation but for the entire stream (e.g. a timeout of 10 seconds means the entire streaming operation must complete and close in 10 seconds or else it will be aborted with a "deadline exceeded" error). 

1. How grpc::channel detect the connection_state change?

I don't know the C++ API; I use Go and Java. So I'm afraid I don't know this one. Go has no such APIs. Java's is very different. I am guessing the connection state is related to actual state of a network connection, and this is known/detected based on a simple state machine for the connection with transitions based on results of network calls.

 

I am using both grpc-go and grpc-c++. I think they may have some differences on the behaviors. 

While the APIs are different (blocking vs. async, error-handling, features exposed) and take advantage of different language features, the overall semantics for GRPC should be more-or-less the same across platforms.

 

Thanks,

Yihao

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c5972d4e-c004-4976-8762-db1520cd1749%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.