We are exploring on signalr service, just we want to know what all the differences in configuration wise of advantages wise which will be better approach for signal.
signalr vs azure signal vs Kubernetes signalr?
Thanks
Related
I have some questions regarding SignalR Core on the server side;
My server is written in ASP.NET Core, and it uses SignalR for sending notifications to users. The server uses Controllers with endpoints that clients interact with.
1) Can I host the entire thing in Azure App Service and add the SignalR service to it? Or would it be better to split the SignalR code out to its own server, which is called from the "main" server when needed?
2) The SignalR Service has an option for "Serverless", which according to documentation doesn't support clients calling any server RPCs when in said mode. Could I run this thing in Serverless mode as I'm only using the sockets for sending notifications to the clients. Or is it reserved for Azure functions?
3) Is there a way to get the number of connections for a user in a SignalR hub? I would like to send a push message to the user if he doesn't have any connections to the server. If not - what is the recommended way of handling this? I was thinking of adding a singleton service that keeps count, but am unsure if this would work at scale, especially with the SignalR service.
Thanks.
1) Better use the Azure SignalR.
2) Use it with the hub.
3) If you use Azure SignalR, you can just see it from the portal. In the code, whenever you use Azure SignalR or not, you can save the user Id in some var and count the connections. If you have multiple hubs and servers, you need to do more (if using redis-backplane for example).
We have an Azure Function supporting a SignalR hub leveraging Azure SignalR Services to publish messages to connected signalR clients. We'd like to enable MessagePack protocol in the function but we could not find any documentation or guidelines to tell how to do it. Any ideas on how to approach this problem?
Interestingly Message Pack protocol is initiated and used when the client app negotiates with the function. Further information can be found here.
I am in a stage of using SignalR in my project and i don't understand when to use Self hosted option and when we should not use. As a example if I am willing to host my web application in server farm,
There will be separate hosting servers
Separate SignalR hubs in each IIS server
If we want to broadcast message into each client, how this is working in SignalR
The idea with SignalR running in multiple instances is that clients connected on instance A cannot get messages from clients connected to instance B.
(SignalR scaleout documentation)
However, when you scale out, clients can get routed to different
servers. A client that is connected to one server will not receive
messages sent from another server.
The solution to this is using a backplane - everytime a server recieves a message, it forwards it to all other servers. You can do this using Azure Service Bus, Redis or SQL.
The way I see, you use the self host option when you either don't want the full IIS running (because you have some lightweight operations that don't require all IIS heaviness) or you don't want a web server at all (for example you want to add real-time functionality to an already existing let's say forms application, or in any other process).
Be sure to read the documentation for self-hosting SignalR and decide whether you actually need to self host SignalR.
If you are developing a web application under IIS, I don't see any reason why you would want to self-host SignalR.
Hope this helps. Best of luck!
After posting a question about the best way to call server methods from clients and clients method from server using C#, I'm trying to start using SignalR but I'm not familiar at all with the web programming.
I would like to use a Windows service as SignalR server and .NET Windows applications as clients. I saw in some other questions asked 1 year ago (like this console app example and this other one) that the best solution would be to use Owin self-host on the server-side, and a HubProxy in the client applications.
Is it still the best approach?
Thanks!
Suppose I have 3 applications -
WebApp 1 - a NancyFX app that serves html pages. there's also a SignalR hub for messaging communications between the users of that app. (and sends messages to WebApp2 sometimes)
WebApp 2 - a NancyFX app that serves html pages. there's a SignalR hub to that receives messages from WebApp 1 and updates the users of WebApp 2.
WebApp3 - a self hosted WebAPI that doesn't have a SignalR hub, but sends messages to WebApp2 in order to update it's connected clients.
So my question - is keeping two hubs in WebApp2 and WebApp1 the way to go, or should I have a (scalable) dedicated SignalR server which hosts the hubs of WebApp2 and WebApp1 to facilitate communications?
Thanks..
Tough to say what's best for you, since we have no details about your load requirements or how authentication/authorization works in your application. However, I'll say this:
Your scenario could be viewed as similar to a more typical SignalR scale-out situation, where you have a single application deployed to a web farm behind a load-balancer. In this scenario, you use SignalR's scaleout ("backplane") feature for server-to-server communication so that outgoing messages reach clients no matter which server they happen to be connected to. Your situation is really no different, except you have three different applications in play. As long as all three of your applications are hosting the same hub class (via a shared hub assembly) and are connected to the same scaleout backplane, it ought to work fine.