IIS and SignalR background thread

I need to have a background thread that does some work and sends data to users connected to the service via SignalR.

I was thinking about hosting this topic in IIS and showing it up when I first run Application_Start or in a separate workflow.

If I host it in IIS and create it at the start of the application - The thread only starts the first time the application is clicked. I need it to work as soon as I start the service. - I have no control over this thread through the desktop GUI, I cannot stop or pause it in an easy way.

If I host it in a separate process such as a Windows service - I don't have access to the SignalR service instance - I don't want to connect to the SignalR service as a user to pass data to other users. I take a different approach to this, which does not imply that the worker is a client of SignalR itself.

What is your opinion on this? Do you see any other solution?


source to share

2 answers

We addressed this to create a separate endpoint in the web application that your Windows service can call.

Imagine the following URI exists in an ASP.NET MVC controller: http: // [myserver] / api / TellUsers / [msg] . Inside this method, you can get the connected hub clients and make the call.

public void TellUsers(string msg)
   var connectionManager = AspNetHost.DependencyResolver.Resolve<IConnectionManager>();
   var demoClients = connectionManager.GetClients<MyHubDerivedClass>();


[Insert a warning about correct error checking here.]

Of course, you don't need to use MVC. Any public URI will work. As far as security is concerned, you can use any valid method for securing ASP.NET endpoints.



I know the question is pretty old, but:

In truth, I really like the "client" example. This gives you control from many different points, not just one. Example. Several services can call to operate the service. I see no reason why you don't have an administrator who can invoke special commands that other users cannot.

This is a proven design for many systems. I would stick with that.



All Articles