IIS后台线程和SignalR

我需要一个后台线程做一些工作，并通过SignalR向连接到服务的用户发送数据。IIS后台线程和SignalR

我想在IIS中托管这个线程，并在Application_Start首次命中时产生它，或者在单独的工作进程中产生它。

如果我将它托管在IIS中并在应用程序的开始创建它 - 线程仅在应用程序第一次命中时启动。我一开始服务就需要它运行。 - 我无法通过桌面GUI控制此线程，我无法以简单的方式停止或暂停它。

如果我是主持人在一个单独的过程中，如Windows服务 - 我没有访问SignalR服务实例 - 我不想连接到SignalR服务为用户将数据发送给其他用户。我想了一个不同的方法来解决这个问题，并不意味着工作人员是SignalR本身的客户。

你对此有何评论？你有没有看到其他解决方案？

来源

2012-03-30 Cristian Toma

不希望服务充当用户的原因是什么？你如何期望在IIS中的后台线程上连接到集线器（坏主意，你可以看看http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in -asp-net.aspx） – redsquare 2012-03-30 16:38:52

原因是安全性和速度 – 2012-03-30 17:22:23

安全性？你可以使用Windows身份验证，速度？什么是客户端慢？ – redsquare 2012-03-31 06:20:48

我们已经接近的方法是在您的Windows服务可以调用的Web应用程序上创建一个单独的端点。

想象一下，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端点。

来源

2012-04-26 12:52:43 MikeC

我知道这个问题是比较旧的，但：

说实话我比较喜欢的“客户端本身”例如，你有。这使您可以从多个不同的点进行控制，而不仅仅是一个。例如 - 多个服务可以调用来控制服务。我看不出有任何理由，您不能拥有能够调用其他用户无法执行的“特殊”命令的管理员用户。

对许多系统来说，这是一个久经考验的设计。我会坚持下去。

来源

2013-05-08 10:26:48

IIS后台线程和SignalR

回答

相关问题