Does the client streaming happen independent of server streaming?

[kingluo]

Tonic wraps the client streaming into Stream, e.g. https://github.com/hyperium/tonic/blob/master/examples/src/routeguide/client.rs#L52. It's kind of different from golang grpc, where you could control when to send message to server, e.g. https://github.com/grpc/grpc-go/blob/master/examples/route_guide/client/client.go#L97.

I am wondering whether the client streaming is independent of server streaming (or single response retrieval)? In grpc spec, it should be independent. But how about toinc?

BTW, IMO, wrapping the client streaming into Stream object is a bit inconvenient. Think that if your request comes from other sources, then you need to use channel between your sources and that Stream object. In fact, the server streaming is straightforward instead, you could control it in loop just like golang, e.g. https://github.com/hyperium/tonic/blob/master/examples/src/routeguide/client.rs#L86. Why not make them consistent?

[LucioFranco]

In the example you showed it is a stream built from an iterator there is no async work going on. You can pass in anystream you like so you could pass in the https://docs.rs/tokio-stream/latest/tokio_stream/wrappers/struct.ReceiverStream.html type and you can then use a channel to achieve the same thing go has. This implementation is much more flexible than the go one its just the example is showing a simple use case here.

[kingluo]

@LucioFranco Thanks for your reply. And yes, I know the Stream could be async block rather than a simple iteration upon array.
Let me clarify my questions again. Let's take pure client streaming as example: as grpc client, I have three requests in total to send, but when I sent two of them, I expect to receive the response first, and then send out the last request. Or, sometimes I wish to send out all of requests and then try to receive the response. In grpc spec, the request/response is decoupling. In golang, I could control the timing myself, because you could call send/recv explicitly, but in toinc, I am confused. Because the client streaming is wrapped into Stream and passed to call() and then it seems that I could not control send/recv in one place.
So, it becomes one new question: how do I control send/recv in a whole to fit my need?

[LucioFranco]

Streams are pull based so items only come out when you request them. I would suggest reading might make streams more clear https://tokio.rs/tokio/tutorial/streams. The incoming messages will be handled but if you don't pull them out then the h2 window fills up. Grpc does the same thing. so everything you request a message on the stream you are pulling it out. The same is for submitting they go into a buffer to then be written to the wire.

[kingluo]

Thanks for your reply.
I know stream is pull-based. But my question is how to control the send/recv timing.
Let's take run_route_chat as exmaple:
https://github.com/hyperium/tonic/blob/master/examples/src/routeguide/client.rs#L83
The response object is returned only after you pass request stream and call the grpc method.
So both stream handlings are separated.
Then how to do this: send two requests and receive one response and so on.
In contrast, go version is creating stream object first, and then you could invoke Recv() and Send() upon that object, so you have full control how the send/recv sequence looks like.
https://github.com/grpc/grpc-go/blob/master/examples/route_guide/client/client.go#L121

[kingluo]

And a releated question: It seems that request streaming only yield data, but has no way to know whether the data is sent successfully or not, if not, how to get the error?
Go version could do it easily: https://github.com/grpc/grpc-go/blob/master/examples/route_guide/client/client.go#L141

[davidpdrsn]

Sounds like you're making it sound more complicated than it is. You gotta return a Stream. Tonic doesn't care what type of stream you use, as long as it yields the right type of items.

It can be backed by a channel that some other async task holds the send half of and sends data when it becomes available.

How you do that is all up to you. Tonic is very flexible when it comes to this.

And a releated question: It seems that request streaming only yield data, but has no way to know whether the data is sent successfully or not, if not, how to get the error?

If you're using a channel Sender then the send will fail if the message couldn't be sent.

[kingluo]

Thanks for @LucioFranco and @davidpdrsn.
You help me a lot to make my program:
https://github.com/kingluo/lua-resty-ffi/tree/main/examples/rust

BTW, here is my blog post about how to implement grpc client library for openresty/Nginx using tonic:
http://luajit.io/post/implement-grpc-client-in-rust-for-openresty/