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. On Sun, May 21, 2017 at 4:22 PM yihao yang <[email protected]> wrote: > > 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写道： >> >> 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/6a956236-0f47-420f-b55f-d3edf69408de%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/6a956236-0f47-420f-b55f-d3edf69408de%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/CADEy0h24JUf_5C6%2B93LDKH1OA5op%2BZbjCvo9sO%2BACNzFnhMemQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
