Any C++ example for AsyncStreaming Client?

[Anirudh Kasturi]

Hello folks,

Can you please give me pointers to an example that has an AsyncStreaming Client?  

Also, when the client is streaming data to the server, we will be basically streaming multiple messages.  Is there a default timeout when the channel sees no more messages for a certain amount of time so that we can shut it down?

I would like to understand the state machine of the client async streamin.  How does the client keeps streaming messages to the server and when does it go to the FINISH state?  For each message the client sends the server has a response.  In that case is it better to use pure async or asycn streaming?

Best,

Anirudh

[Anirudh Kasturi]

Any updates on this? 

[Vijay Pai]

Hi there,

Many of the test codes use C++ async streaming; for example test/cpp/end2end/async_end2end_test or test/cpp/qps/qps_worker .

On Thu, Apr 13, 2017 at 11:25 AM Anirudh Kasturi <anirud...@gmail.com> wrote:

Hello folks,

Can you please give me pointers to an example that has an AsyncStreaming Client?  

 

Also, when the client is streaming data to the server, we will be basically streaming multiple messages.  Is there a default timeout when the channel sees no more messages for a certain amount of time so that we can shut it down?

There is no default timeout - the point of the async API is to give the program maximum control. You can set a deadline on the Next operation by using CompletionQueue::AsyncNext rather than just plain next. You can also shut down the stream any time you want.

 

I would like to understand the state machine of the client async streamin.  How does the client keeps streaming messages to the server and when does it go to the FINISH state?

Can you describe this further? From your paragraph above, it seems like you are doing client-side 1-directional streaming, but the next sentence looks like bidirectional streaming. If it's bidirectional streaming, your flow will look something like:

1. Initiate the RPC with its completion queue and tag

2. Do CompletionQueue::Next (or AsyncNext) for completion queue tags

3. When you get your desired tag back, the RPC is initiated

4. At that point, you can issue a Read, a Write, or one of each concurrently. If you do one of each concurrently, make sure that they get different tags

5. Do CompletionQueue::Next and process the tags that come off it

6. Loop to step 4 as long as you want to

7. When you are done with Writes on this stream, initiate a WritesDone. It's actually done when its CQ tag comes back

8. When you are fully done with this stream, initiate a Finish. It's actually done when its CQ tag comes back

The process is similar for client-side 1-directional streaming, but obviously without Reads during the main loop and with an actual response object on the Finish (and not just a status).

 For each message the client sends the server has a response.  In that case is it better to use pure async or asycn streaming?

It is not always the case that the server will have a response for every client send. If you mean that that's how your application is structured, then that will allow you to make a pretty straightforward state machine for your structures that control the stream. In general, sync streaming is easier for most cases (since no completion queue manipulation) but hits scalability limits since each stream gets its own thread and its own completion queue. I would think that sync streaming will be a better choice up to a few thousand concurrent streams; after that async streaming would be preferable so that you can control threading from the application.

 

Best,

Anirudh

--
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+u...@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/18da9b2d-a425-4c7f-8aeb-8a03c4bec1ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kuldeep Melligeri]

I have posted an complete example for asynchronous streaming API, hope it helps

https://groups.google.com/forum/#!topic/grpc-io/2wyoDZT5eao

[Anirudh Kasturi]

Thanks Kuldeep ! 

[Arpit Baldeva]

Here is a more complex example :) - https://groups.google.com/forum/#!topic/grpc-io/DuBDpK96B14 

It implements server side but concepts remain closely the same. 

[Anirudh Kasturi]

Thanks a lot Vijay !  That was a helpful insight.  

Best,

Anirudh

Hi there,

Best,

Anirudh

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.

[Anirudh Kasturi]

Thanks Arpit.  I did look at this thread earlier :)

Was helpful in implementing my server side stuff.

Best,

Anirudh

You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/pGx33aLmaCg/unsubscribe.
To unsubscribe from this group and all its topics, 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/46d06f27-b796-4f6d-96b9-7c535cae3c93%40googlegroups.com.

[yihao yang]

Hi, Vijay:

I'm a little confused with the concurrency of async stream read/write/finish, the questions are listing below:

1. Can I call async stream's Read/Write multiple times event the completion queue not returned?

2. When I need to finish the stream on a write error, what should I do to the ongoing read? and what should I do to the ongoing write when occurs a read error?

3. Are there any different error handling operations need to be done from server side and client side? (as I know, both need to call stream->WriteDone()  on write error and then stream->Finish() )

Thanks for you help,

Yihao
在 2017年4月26日星期三 UTC-7下午1:05:04，Vijay Pai写道：

[Vijay Pai]

Hi there,

Thanks for your questions.

1. You can only call 1 read and 1 write for a given stream (RPC) concurrently without waiting for the completion queue event to return. In the case of read, it returns when data is ready to be processed by the application. In the case of write, the guarantee is that the return implies that it is safe for the application to overwrite the message buffer that was passed in.  It hasn't necessarily been sent to the other side yet, but it is committed to doing so by being in a buffer in the library or kernel.

2. Can you clarify what you mean by read error or write error? Error status is not complete until Finish. Note that a CQ result of !ok is not the same as an error - it can be a normal part of operation indicating that there will be no further messages coming from that side of the stream. It might indicate an error, but it might also indicate an OK status in normal operation.

3. The server side doesn't ever call WritesDone; that is a client-side thing. The server-side only calls Finish.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/6a956236-0f47-420f-b55f-d3edf69408de%40googlegroups.com.

[yihao yang]

Hi Vijay,

thank you for answering, have some more confusion.

The background is I' am using GRPC 1.0.0.

For Ques1, when I did the test, I found that I cannot issue another read util the previous read done event is got by completion queue. That means I only can issue the next async read request when the previous one returned by the server. otherwise, I will get an assert coredump.

For Ques2, thank you for telling me the CQ result is not an error. So can I treat that an !Ok from CQ means the stream finished in server side? And what will happen when the bi-directional stream gets some failure (will it like CQ cannot get some events infinitely)?

Have two more question when I went further:

1. When I call Finish on both sides, do I need to handle outstanding (or unconsumed) read/write done events first?

2. Are there any big bugs fix report of each release? Any suggestion on which version of GRPC should I choose?

thanks,

Yihao

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.

[Vijay Pai]

Hi Yihao,

No problem, I'm glad to answer.

1. Indeed, you can't issue another read on the same stream until the previous one is completed at the completion queue. That's what I meant by at most 1 concurrent read. You can have a write on the same stream at the same time.

2. !ok means that that side of the stream is finished - if it returns !ok on a Read, then the other side is done writing; if it returns !ok on a Write then the other side is done reading. If the client does a read and it returns !ok, then that means the server-side is completely done with the RPC (since the server doesn't have a separate WritesDone) and the client can collect status by calling Finish. In general, if you're done with the RPC (e.g., if you cancel the RPC or know that you aren't getting anything from the other side), you can call Finish to get the final grpc::Status.

3. Finish means that you want the completion status of the RPC. It doesn't, however, force the other side to be done. You should either process any reads and writes on the stream or cancel the stream before calling Finish. Otherwise, Finish won't return.

4. Great question! Each release has its release notes that explain what has changed, and those include bug fixes, new features, and performance optimizations. I would recommend using the most recent release version that you can; especially as a C++ user, I imagine that you would benefit a lot from improved performance and I believe that C++ performance has improved by a factor of 2 since 1.0.0.

Regards,

Vijay S. Pai

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/6a956236-0f47-420f-b55f-d3edf69408de%40googlegroups.com.
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+u...@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/CAKVAn%2BCY6LJziF7z-BAC5LGxhuf5%2BZArAE1b9_1cTOiT0WFxRg%40mail.gmail.com.

[Vijay Pai]

Hi there,

I got an off-thread followup question which I thought I would also post here since it seemed relevant to this discussion:

Question: "Still not clear on what will happen when the network has some problem. For example, I want to use the bi-directional stream to maintain a session. How can I say the session should be expired if the network is partitioned or the server/client are crashed. Can I just check how long has no event came? Will there have some other situation?"

Response: This is getting into advanced (and interesting) topics. By default, channels in gRPC are reliable in the sense that they will try to reconnect to survive TCP failures unless the failure is known to be permanent. So this issue is not actually in the streaming API - it is an issue in the channel API itself. You can check the current connectivity of a channel, as well as receive a notification on the CQ when the connectivity state changes. These functions are documented at http://www.grpc.io/grpc/cpp/classgrpc_1_1_channel_interface.html . Hope that helps!

- Vijay

[anassa...@gmail.com]

Hi, I am new to this forum. I have some issues implementing client side streaming. Lack of ready to run example on the grpc website or other sources forced me to write one on my own, but facing alot of issues. Were you able to accomplish the client side Asynchronous Streaming. Please reply as and when feasible. 

[Mya Pitzeruse]

The route_guide example often includes examples for all api call types.

https://github.com/grpc/grpc/tree/master/examples/cpp/route_guide

--

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+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/9d79a739-465a-487d-b369-ab622b39a136o%40googlegroups.com.

--

Mya Pitzeruse

Principal Software Engineer - Service Infrastructure

Gender Pronouns: She, Her, Hers

mjp...@indeed.com

Indeed - We help people get jobs.

Indeed.com

Facebook  |  Twitter  |  Instagram

[anassa...@gmail.com]

Thanks for the quick reply. The link you mentioned has given examples for bidi sync streaming and not bidi-asyn-streaming.

[Patrice Chalin]

Hi, Have you tried the Asynchronous-API tutorial linked to on the C++ languade page: 

https://grpc.io/docs/languages/cpp/?

--

[anassa...@gmail.com]

it does'nt involve streaming. 

To unsubscribe from this group and stop receiving emails from it, send an email to grp...@googlegroups.com.