Geek Answers Handbook

How does Signal-R fit into the IIS activation model?

I study Signal-R, and this is what I had in my head all the time.

  • How does Signal-R fit into the IIS / ASP.NET life cycle?
  • How long do hubs live (I see that they have reconnection semantics)?
  • Does IIS Prevent AppDomain from Staying Connected?

As I understand it, IIS is designed to handle request-response scripts. The request goes to IIS, it finds the AppDomain, activates it, and then passes the request to it. And after downtime, turn off AppDomain. If the request takes too long, a timeout exception is thrown.

Now let's imagine that I have another application that transmits information through a TCP socket. I want my javascript clients to receive this information in real time, so I am building a Signal-R web application. I can create a TCP client when the application starts, but what guarantees that IIS will not close all this after a while of inactivity?

I could host the Signal-R application on the window service myself, but then I would have to use a different port, enable the cross-domain, etc. .... Many problems for deployment. But I'm interested in using the ASP.NET MVC application for this, since it seems to me that I am installing a drive wheel on a motorcycle.

Greetings.

+7
signalr
source share
2 answers

SignalR in the IIS / ASP.NET Life Cycle

Hub Object Life

From SignalR docs: http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-server#transience :

You do not instantiate the Hub class or call its methods from your own code on the server; all that is done for you by the SignalR Hubs pipeline. SignalR creates a new instance of your hub class each time it needs to handle a hub operation, for example, when a client connects, disconnects, or calls a method call to the server.

Since instances of the Hub class are temporary, you cannot use them to maintain state from one method call to the next. Each time the server receives a method call from the client, a new instance of your hub class processes the message. To maintain state through multiple connections and method calls, use some other method, such as a database, or a static variable of the Hub class, or another class that is not derived from the Hub. If you store data in memory using a method such as a static variable of the Hub class, the data will be lost when reusing the application domain.

Your long TCP client

This is not a problem with SignalR. Your TCP client can be disabled by IIS: http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in-asp-net.aspx/

I prefer the TCP client to work in the Windows service. The TCP client receives TCP broadcast messages and forwards the messages to the hub using the SignalR.NET client.

+6
source share

Hubs are recreated for each SignalR request, so if you need a persistent connection, you might have to look in using static vars or dictionary to store state. But as you indicate that ASP.NET can restart for various reasons.

It depends on what persistence you really need. If you have a connection that SHOULD remain alive at all times and cannot be demolished and restored, then hosting in IIS is not the right choice. However, if you can restore the same connection after shutting down, perhaps this may still work.

You can do a bit of work so that ASP.NET applications do not close in recent versions of IIS:

http://weblog.west-wind.com/posts/2013/Oct/02/Use-IIS-Application-Initialization-for-keeping-ASPNET-Apps-alive

If this is not enough to work as a separate service, this is an option. If you start the service on the same IP address, there are no problems with the cross domain. Here is more information about starting SignalR using the Windows service:

http://weblog.west-wind.com/posts/2013/Sep/04/SelfHosting-SignalR-in-a-Windows-Service

+1
source share

More articles:


All Articles