Thanks Arpit. I did look at this thread earlier :) Was helpful in implementing my server side stuff.
Best, Anirudh On Thu, Apr 27, 2017 at 9:53 AM, Arpit Baldeva <[email protected]> wrote: > 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. > > On Wednesday, April 26, 2017 at 11:16:31 PM UTC-7, Anirudh Kasturi wrote: >> >> Thanks Kuldeep ! >> >> On Apr 26, 2017 11:14 PM, "Kuldeep Melligeri" <[email protected]> >> 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 <[email protected]> >>>> 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 [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> 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 >>>>> <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 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 > [email protected]. > To post to this group, send email to [email protected]. > 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 > <https://groups.google.com/d/msgid/grpc-io/46d06f27-b796-4f6d-96b9-7c535cae3c93%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 [email protected]. To post to this group, send email to [email protected]. 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/CAOOzfuzvAfwejXCbxK3iR5V5QQ3zKG_hhuo-Y9dsXdt4_fb%2BCQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
