SignalR streaming from server to specific client
See original GitHub issueIs your feature request related to a problem? Please describe.
I have a use case when server initiates a workflow with the client. Conventional SignalR call gives ability to pick specific client during invocation (MyHub.Clients.Client("clientid").SendAsync), but streaming doesn’t (or it is not documented).
Describe the solution you’d like
To have ability to stream to a specific client.
Describe alternatives you’ve considered
I don’t see a workaround since my application is distributed and if I do not “set up” a stream to the client on the first call (e.g. do Client("clientid").SendAsync and then open stream from the client), the response might be routed to random application instance which is unacceptable.
Additional context
There is a ASP.NET Core application deployed to two regions - US and EU. It runs behind Traffic Manager and contains a SignalR hub and uses Azure SignalR Service (single US instance) as backplane for scaling purposes.
The hub interacts with the client in synchronous way - calls value-returning method and waits until it returns. The locking mechanism is implemented on top of in-memory collection of tasks, and thus there are problems when server-to-client communication originates on one instance (say EU), but client-to-server “response” is returned to another (US) - first application instance is locked indefinitely, because it never receives the response for the request, and second instance does nothing because it cannot map the response to any previous request. I’ve tried brand new ServerStickyMode=Required mode for Azure SignalR, but it does not help since my client is permanently in US -> Connect is always hitting US application -> all responses are “stuck” to US instance as well. I suspect streaming can help me with this scenario.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:5
- Comments:7 (5 by maintainers)

Top Related StackOverflow Question
Pre-planning notes: I don’t see us having the resources to look at this in 5.0. It needs spec changes, new protocol messages, versioning considerations, etc. and we’re tight on resources this release because of other projects.
We’ll queue this for some discussions in 5.0. No committments yet, but we’ll talk about options here.