C++ API, unidirectional streaming: How to tell if receiver closed the connection?

[m...@stackrox.com]

Hi,

I'm having trouble using the GRPC C++ API for a unidirectional stream RPC (client streaming, client is written in C++, server in Go).

Unless I'm missing something, it seems that the only way to find out if the remote (receiving) end of the stream aborted the GRPC call is by actually calling Write(). For streaming connections that send data only infrequently (but which need to be streaming nonetheless, due to statefulness of a single "call" and ordering guarantees), this seems very unsatisfying. Even when using the stream to send keep-alives at regular intervals (which I do not believe should be done at the application level), the fact that a call to `Write

[m...@stackrox.com]

Whoops, hit reply to early.

Even when using the stream to send keep-alives at regular intervals (which I do not believe should be done at the application level), the fact that a call to `Write` might return true just after writing to the buffer might make even this approach unreliable.

Any help would be very much appreciated.

Note: I'm using the sync API, but I didn't find anything in the async API either.

[malte.i...@gmail.com]

Ok, it seems like the situation is even worse, and this is really frustrating.

Using a Go GRPC server (didn't test anything else), I cannot even get `Write()` to fail even when the remote server does not implement the method I'm calling! I'm sending a message every 5 seconds to a GRPC server that doesn't implement the method/service, and I keep getting `true` return values (code is running for >5m now). Now, I can call `Finish` at any time and will then in fact get the "unknown service xyz" in the status response, but for that I'd have to close the stream - doesn't work with my use case.

I somehow can't believe that this is really the state of affairs with the GRPC C++ API, but I've looked through most of the API and don't see a solution. I apologize if that sounds harsh, but if it is impossible to make a client-side streaming RPC call without knowing whether all the data gets effectively sent to /dev/null before closing this stream (regardless of session length), it seems that client-side streaming is effectively unusable from C++..? (This very use case works absolutely fine in Golang)

On Wednesday, September 19, 2018 at 4:55:40 PM UTC-7, m...@stackrox.com wrote:

[malte.i...@gmail.com]

One detail I forgot in my example, which is now happily running for >10m without reporting an error on Write(): The messages I send are indeed very small, but I'm passing `grpc::WriteOptions().set_write_through()` to every Write call, so buffering should not be the issue here (and if I understand things correctly, it shouldn't be even without that option).

[ple...@swissonline.ch]

Hi,

I face the same problem, did you find a solution ?

[m...@stackrox.com]

I did, sort of. I made the streaming bidirectional (basically rpc MyMethod (stream ClientMsg) return (stream google.protobuf.Empty) ), and attempting client-side recv's now gives an option to reliably check for error. I also wrapped the whole grpc interface into a select-style interface (as I didn't want to use threads and thought the async interface is overly complicated, especially considering I didn't really need that full-duplex functionality). I can share it here if you're interested (need to check w/ employer but shouldn't be an issue).

Hope that helps,

Malte

[men...@gmail.com]

I have the same issue look at this:  https://github.com/grpc/grpc/issues/17236

I have kinda solved (I need to do some further tests) observing the underlying channel status.

[men...@gmail.com]

Also I have to say I'm puzzled as well about the client streaming use case:  https://groups.google.com/forum/#!topic/grpc-io/7alTzx7YRKE

[Malte Isberner]

In my case the transport was perfectly fine. The was another stream over the same transport channel which worked as expected. So, I could get nothing from the transport channel status.

--
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/Xo_kqZwuDoA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@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/30122907-c20e-4454-9546-6cb03ea1f884%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[men...@gmail.com]

This approach doesn't decrease the client->server throughput ?

[ple...@swissonline.ch]

This is not a solution for me as the channel is used for others RPC calls, having a server cancelling a client stream should not change the channel status.

[Arthur Wang]

I  accidentally worked around the problem by define a bidirectional RPC and make client periodically sending an acknowledge message among the normal stream messages to the server , if the server can't give a positive response to that ack, consider it as shutdown.

--
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+u...@googlegroups.com.

To post to this group, send email to grp...@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/98d282c1-8511-4499-ba01-f1797e1b99e6%40googlegroups.com.