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 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/CADEy0h3xQU0qnwmAQX92WmCqNL9fiwO3n9oTErchs%2B5Lvh5ERg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to