Thanks Kuldeep ! On Apr 26, 2017 11:14 PM, "Kuldeep Melligeri" <kuldeepmellig...@gmail.com> wrote:
> I have posted an complete example for asynchronous streaming API, hope it > helps > > https://groups.google.com/forum/#!topic/grpc-io/2wyoDZT5eao > > > > On Thursday, 27 April 2017 01:35:04 UTC+5:30, Vijay Pai wrote: >> >> 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/ms >>> gid/grpc-io/18da9b2d-a425-4c7f-8aeb-8a03c4bec1ca%40googlegroups.com >>> <https://groups.google.com/d/msgid/grpc-io/18da9b2d-a425-4c7f-8aeb-8a03c4bec1ca%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/CAOOzfuzSD4fFSk97bxVx-EH6D6jKwkhokqQKXwZKT6Me4oiZoQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
