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 
"" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

Reply via email to