Фоновая нить IIS и SignalR

Question

Мне нужен фоновый поток, который выполняет некоторую работу и отправляет данные пользователям, подключенным к услуге через SignalR.

Я думал о размещении этого потока внутри IIS и порождении его при первом обращении к Application_Start или в отдельном рабочем процессе.

Если я размещаю его в IIS и создаю его при запуске приложения - Тема запускается только тогда, когда приложение впервые ударил. Мне нужно, чтобы он работал, как только я запускаю службу. - У меня нет контроля над этим потоком через графический интерфейс рабочего стола, я не могу остановить или приостановить его простым способом.

Если я размещу его в отдельном процессе, таком как служба Windows - У меня нет доступа к экземпляру службы SignalR - Я не хочу подключаться к сервису SignalR как пользователь, чтобы отправлять данные другим пользователям. Мне нужен другой подход к этому, который не подразумевает, что работник является клиентом для самого SignalR.

Что вы думаете об этом? Видите ли вы другое решение?

Answer 1

Мы подошли к этому так, чтобы создать отдельную конечную точку в веб-приложении, которое может вызывать ваша служба Windows.

Представьте, что в контроллере ASP.NET MVC существует следующий URI: http://[myserver]/api/TellUsers/[msg]. Внутри этого метода вы можете получить подключенные клиенты-концентраторы и выполнить вызов.

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

[Вставьте предупреждение о правильной проверке ошибок здесь.]

Конечно, вам не нужно использовать MVC. Любой общедоступный URI будет работать. Что касается его защиты, вы можете использовать любой допустимый метод защиты конечных точек ASP.NET.

Answer 2

Я знаю, что вопрос довольно старый, но:

По правде говоря, мне больше нравится пример "самого клиента", который у вас есть.Это дает вам контроль из разных точек, а не только из одного.Пример - несколько сервисов могут вызывать для управления сервисом.Я не вижу причин, по которым у вас нет администратора, который может вызывать «специальные» команды, которые другие пользователи не могут.

Это проверенный и проверенный дизайн для многих систем.Я бы придерживался этого.