On Sat, Aug 26, 2017 at 2:09 AM, yihao yang <yangyihao1...@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+unsubscr...@googlegroups.com.
> To post to this group, send email to grpc-io@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
> <https://groups.google.com/d/msgid/grpc-io/c5972d4e-c004-4976-8762-db1520cd1749%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/CAO78j%2B%2BZQfk9Pst78h7vk7BksLMzkDk0nmsj2qtKUE6n6YxmBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to