Consider a "standalone" SignalR backplane solution

[davidfowl]

We can start with a basic implementation that is a standalone application that needs to be hosted in order to function, no fancy clustering just yet. Everyone connects to the SignalR backplane service and we treat it like a remote cache.

One downside of doing it this way is that the backplane service would need to be scaled out as well...

[grahamehorner]

I’m looking into something similar, with #ServiceFabric hub-spoke configurations and mesh, also looking at the possibility of a #ServiceFabric in memory #EF provider

[KPixel]

Is this similar to the idea I discussed here #684, replacing Redis with SignalR itself?

[davidfowl]

@KPixel basically, there are questions on how to scale out the signalr used for messaging though.

[analogrelay]

Retargetting this to focus on an on-premise "standalone" backplane, primarily for cases where Redis and Azure SignalR is infeasible (i.e. On-Premise Windows).

[legistek]

Wondering if there's anything new on this since August? Is there any way to use SignalR with a load balancer other than Redis caching right now? I would like a solution that doesn't require any additional infrastructure beyond IIS and maybe SQL Server.

FWIW having no replacement for SQL backplaning is the only thing blocking me from updating to ASP.NET Core from Framework.

[analogrelay]

There are no new plans right now, but your feedback is noted! This thread is where we'd discuss any new plans.

We are looking at planning for 5.0 and while I can't make any promises, it's good to know you have interest in this and that it's blocking migration for you. We'll consider that in our planning process.

[leonkosak]

I would also prefer SQL backplane for not so intensive cluster environments - SQL Server and Postgres.

[szalapski]

I would like to see this, especially if it is much simpler than spinning up a redis instance.

[mezzo1981]

Any news on this topic for supporting a simple Backplane or bring back the SQL Backplane?

[ascott18]

If anyone's still after this, I created a SQL Server backplane for SignalR Core. Its effectively a fork of the Redis provider, with the underlying transport swapped out to use the techniques used by the classic SignalR SqlServer backplane.

The same caveats and limitations of the original still apply - if you have huge amounts of volume, this probably isn't a great solution. Service Broker is required for immediate responsiveness and to avoid periodic polling, so if you're running against Azure SQL Database then this is probably not a good fit.

https://github.com/IntelliTect/IntelliTect.AspNetCore.SignalR.SqlServer

[Nalin-Bhatia]

Any news on this topic for supporting a simple Backplane ? Out clients also have windows based environments and its difficult to use linux based redis.

[davidfowl]

No we don't have a solution for on-prem windows that can't use redis. Do your nodes have interconnectivity (can each of your instances directly talk to each other?)

[legistek]

FYI I've gone to using Redis on Windows Server through WSL and that works fine.

[davidfowl]

Also using docker is a pretty good solution.

[Nalin-Bhatia]

@davidfowl

• Yes our nodes can have interconnectivity. Are you suggesting any workaround in that case ?
• Docker solution - are you suggesting hosting Docker using Hyper-V in windows or is there any other method ? Can you point me to some article in this. I see this article which talks about hosting linux on windows through Hyper-V
  --> https://ubuntu.com/tutorials/windows-ubuntu-hyperv-containers#1-overview

@legistek

• "Redis on Windows Server through WSL" - Is it a good solution for production, from performance perspective? In our case some big clients will use this system, so heavy load is expected. I read somewhere that WSL is not meant to be used in production, but i am not sure. It will be great to hear your experience.