Sort of but not entirely. The client is definitely interested in getting messages back, hence the use of the streaming api. However it will be part of the normal lifecycle for the client to want to close down, complete, cancel whatever we want to call it. When this happens the server needs to know of the clients intention to stop receiving messages and tear everything down. I can do this with the cancellation api but not without exceptions on the client and the server. Jan suggested using the bidirectional streaming so the client can call CompleteAsync. This works when the server sends back a response and then waits for the next request. My use case is a little different as the server will keep that stream open by never returning a completed task from the initial request, it just writes to the response stream. Perhaps it's just not supported out the box.
-- 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/ba3dff60-3f4f-4bd8-b525-1412a770c164%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.