When we should use SignalR self hosted and when we should not?

By : Damith
Source: Stackoverflow.com

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

By : Damith


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!

This video can help you solving your question :)
By: admin