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 <https://github.com/grpc/grpc/releases> 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 On Tue, May 23, 2017 at 8:58 PM yihao yang <[email protected]> wrote: > 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 > > On Mon, May 22, 2017 at 12:28 AM, Vijay Pai <[email protected]> wrote: > >> 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/CAKVAn%2BCY6LJziF7z-BAC5LGxhuf5%2BZArAE1b9_1cTOiT0WFxRg%40mail.gmail.com > <https://groups.google.com/d/msgid/grpc-io/CAKVAn%2BCY6LJziF7z-BAC5LGxhuf5%2BZArAE1b9_1cTOiT0WFxRg%40mail.gmail.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/CADEy0h3T-TjMnhbDutSj9AnCuO%3Dc60AcEnm-Y9oMRXACRjmNnQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
