Server-to-client streaming

The spec says

In gRPC a client application can directly call methods on a server application on a different machine as if it was a local object, making it easier for you to create distributed applications and services.

I need to implement a flow where server calls a client method and waits for response. Caveat - I don’t want to use timeouts (Sleep/SpinWait) and can’t use TaskCompletionSource as synchronization primitive because system will be distributed and one cannot put TCS to Redis or some other distributed cache. I know this is not something that is currently implemented, but maybe it is planned or at least there are ideas how to tackle this problem? Thanks in advance for the response. p.s. Having both client and server on the each side of the conversation appears to be the solution, but it’s definitely not an efficient one.

[kskalski]

Why not just use a stream where client connects (and keeps the call open) and then waits for a message from server (answering it and then waiting for next one)?

[philliphoff]

If I understood correctly you want the process that performed a TCP Connect to behave as a server and the process that performed the TCP Listen to behave a client. This is currently unsupported by by both Kestrel and HttpClient which makes it impossible for us to support it in this project. To achieve what you’re trying to do, I’d recommend using an existing TCP Tunneling solution.

We’ve had a similar question come up in the context of Dapr, in part as a mitigation for firewalls between application and Dapr sidecar (where, ideally, the gRPC API need not change into a streaming-based API). It’s been a couple years, does anyone know if this limitation still exists? (We’ve been able to achieve this scenario on the Go side, but now looking at .NET.)

@shirhatti @JamesNK