There is very limited information on azure signalR service. I need to clarify a question so any help would be highly appreciated.
how azure signalR service actually scale out ? I mean, as far I have worked on it. it seems that you have to include a primary key of azure signalR service to your hub. you can host you hub anywhere. So how hub scales out.?
SignalR Service manages all the client connections, as well as certain state information such as group membership. Your ASP.NET Core application establishes a connection to the SignalR Service instance.
When the application wants to send a message to connected clients, it uses this connection to instruct the service to do so. The service can also invoke hub methods via this connection.
You can read more about the service protocol.
When a client initiates a connection, it calls a negotiate endpoint on your ASP.NET Core application, which redirects the client to connect to the SignalR Service instance instead.
Because the ASP.NET Core application only needs to execute hub logic and most of the heavy lifting is done by SignalR Service, your application does not typically have to scale out to handle more SignalR connections. You can scale it based on the needs of the web traffic (serving web API and MVC requests, for example), and you can scale the service based on the needs of your SignalR traffic.
This is the documentation that I found and followed to have a signalr hub that worked across multiple App Service instances but behaving as a single hub.
You need to create a "backplane" in Azure using Storage queues and topics.
Details here: https://learn.microsoft.com/en-us/aspnet/signalr/overview/performance/scaleout-with-windows-azure-service-bus
#anthonychu is this still needed / applicable??
Related
I have set up the Azure SignalR Service for REST API. There are three modes under settings: Default, Serverless, Classic. I can't find any information about what each of these items sets. The only one thing I got so far, that if I use Azure SignalR for Azure Functions or REST APIs it's preferable to use Serverless option.
From documentation:
Change the Service Mode setting to Serverless only if you are using Azure SignalR Service through Azure Functions binding or REST API. Leave it in Classic or Default otherwise.
Serverless mode is not supported for ASP.NET SignalR applications. Always use Default or Classic for the Azure SignalR Service instance.
Could you please help me to find what each of these options sets?
According to the docs on Github, it determines whether a hub server connected to the SignalR service is needed or allowed:
Default mode requires hub server. When there is no server connection available for the hub, the client tries to connect to this hub fails.
Serverless mode does NOT allow any server connection, i.e. it will reject all server connections, all clients must in serverless mode.
Classic mode is a mixed status. When a hub has server connection, the new client will be routed to hub server, if not, client will enter serverless mode.
Because there isn't a hub server under serverless mode, the things you can do are limited to sending messages to specific clients or broadcast to all clients from a connected client. Also, as there is no hub, messages from clients to SignalR service will be sent over HTTP instead of Websockets, which may have performance concerns as detailed here.
Let's say, I have an enterprise application runs on Azure Web App Service. Among 100+ pages, I have 3-5 pages needs to be served real-time. to benefit from real-time capabilities of Azure SignalR Service, I want to make clients land on my SignalR application (which runs on RignalR Service). But I couldn't find any related example-article about it. How can I invoke a Hub method outside of the code? Any other approach to solve my problem is more than welcome. My main concern here is the performance of real-time pages.
If you have an ASP.NET Core SignalR Server (i.e. you have classes deriving from Hub in your application), you can't directly send messages to clients via the Azure SignalR Service. You'd have to provide an API in your ASP.NET Core application that does that.
Azure SignalR does also support a "serverless" mode in which you don't have a Hub on the server at all. In that model, clients connect directly to the service (instead of first connecting to your app) and then you can send messages to those clients using the REST API. This is a relatively new scenario so there isn't a lot of documentation. There are some blog posts and videos online on the subject, but not a lot of documentation.
If you already have an ASP.NET Core app, I'd suggest doing this by adding a REST API to your own application that allows other services in your application to send messages by calling this API. In the implementation of this API, you can use IHubContext<T> to send the messages.
I'm reading the very limited information about Azure SignalR service as well as the quick start guide and want to make sure I'm understanding this correctly.
We still seem to have a hub and if I understand this correctly, the function of Azure SignalR service is to simply push the messages to connected clients.
In my case, I store the history of chat so by hitting the hub first, I'm able to still use my backend logic to persist chat history or do any other processing that I may want. Then simply allow Azure SignalR service to push the data to connected clients.
The main benefit seems to be handling the scaling of the service.
Am I getting this right?
Yes, you are totally right.
You will use exactly the same API of ASP.NET Core SignalR to write your business logics, which means you can persist whatever you want when the messages from clients hit your hubs.
Azure SignalR Service will be the underlying transport between your app server and connected clients. For example, when you want to broadcast messages to all your clients, you actually only send one message to Azure SignalR Service and the service will broadcast the message to all clients for you. So that you don't have to worry about the scale-out. Azure SignalR Service will handle the scaling-out for you.
You understand correctly.
SignalR is not yet ready for production (when speaking about ASP.NET Core), SignalR for ASP.NET MVC has been around for a while (stable).
SignalR consists of 2 pieces: server and client. The server is as you describe: a "hub" that you can use to push information to clients.
On a webpage you load a piece of generated javascript (generated automatically from your hub definitions). Basically you let your website visitors (clients) connect to the hub through signalR's mechanism (signalR will choose the proper way to connect depending on the browser), and then 'subscribe' to the different methods you have active in your hub.
The workings are simple: whenever you call code in your hub (can be from clients, or from backend code) communication is automatically handled for you to all subscribed clients.
Note: If you are running this on an azure web app: enable the "always on" setting, and set the "websockets" toggle to "enabled", otherwise you'll see strange behaviour.
Note2: The RC version for signalR core 1.0 has just been released (7th of may 2018) so it might be a while before this software starts becoming stable and available through the public nuget/npm channels.
I have a service fabric cluster with a web API with signalR and a reliable actor setup.
I also have a separate MVC application that hits the web API.
I can connect to the signalR just fine with MVC app just fine and everything works well. But when I hit the API with the reliable actor which should then trigger a signalR broadcast to the group the MVC app is connected to, nothing comes across on my MVC app. I know it is hitting the API as I have it logging to be sure.
I have set the load balancer to Session persistence to Client IP. I am suspecting that the signalR hub might not be the same 'hub' or its on another node? Is there any way I can force it to all be on the same one so this communicates? Am I forgetting anything? Please let me know if I need to include more information.
The answer I found was SignalR Scaleout with Redis
Basically this uses redis to share signalR messages across all nodes in the service fabric.
Simply set up Redis, reference Microsoft.AspNet.SignalR.Redis and add this to your startup:
GlobalHost.DependencyResolver.UseRedis(new RedisScaleoutConfiguration(redisConnectionString, "SignalR"));
We've been writing services to access our on-premises databases through Azure Service Bus Relay for awhile now. That means that we've had to deploy them as WCF services. Our web site development is moving to node.js and I would like to begin deploying our API services on node as well. However, while the Azure NPM package has good support for queues/topics on Azure Service Bus, I can find no mention of the relaying capabilities. I've had a look at the code for the Azure SDK on github, but again, relay seems to be conspicuously absent.
Is it possible to use Azure Service Bus Relay with a node.js backend?
Now Azure support Node.js. You can find the infomration from here. This link is the samples for Node.js.
Right now, Relay only supports a WCF service. You can try to use Clemens Vasters' post on Port Bridge to get your scenario working. In his post, he describes creating a WCF client / service that will forward requests to a specific port.