IIS stops serving content with iisnode and socket.io

[sjgillil]

I am using websockets with a socket.io server (based on your dante example) for a simple chatroom.

I created a client page with ASP.NET. All it does is open a websocket, send messages from a textbox, display any broadcasted messages, and then close the connection when the page is unloaded.

The client page works fine until I get a few windows open (all connected to the server). At about 10 windows, or even if I reload the page about 10 times, IIS stops serving content on whatever port my application is on. The browser tries to load the page (unsuccessfully) without redirecting to an error page.

The only way for the application to go back to normal is to recycle the application pool.

I don't know how to fix it, and I don't know whether it is node.js settings, iisnode settings, socket.io settings, IIS settings, or even firewall settings that are causing the application to fail.

I have uploaded my app to an external web hosting server and it seems to work fine, but it keeps breaking on my Laptop.

(Note, my laptop has 16GB Ram, so it isn't running out of memory) @gissues:{"order":1.0308159722222223,"status":"backlog"}

[tjanczuk]

What is your OS, iisnode version, and node.js version? Is there a particular reason you are mixing ASP.NET and node.js in one application? Did you look at SignalR for ASP.NET?

[sjgillil]

I am using Windows 8 Pro (64 bit) and IIS 8. I was using iisnode v0.2.3 and Node.js v0.8.21 but I just updated to iisnode v0.2.4 and Node.js v0.10.1 a few hours ago and it is still behaving the same.

I can open 9 windows, and on the 10th window the port stops serving any content until I recycle the app pool.

I am using ASP.NET because of its Master pages, but the same thing happens when the client page is an html file.

I have looked at SignalR and wrote a similar chatroom with it, as well as with ASP.NET 4.5's new WebSocket classes.I haven't had any noticeable problems with either of these except for the lack of documentation.

I am using Node because I want to learn a new language (framework? it's javascript so its technically not a new language) and it is easier to do many things with Node than with SignalR.

I am not sure what the problem is exactly. I am convinced there is a configuration setting set somewhere that is limiting local connections to the chat server.

I have the same code uploaded to my Hosted Website (Arvixe.com Windows account), and I can get at least 30 windows open and I have yet to have any problems. They use slightly older versions of Node.js and iisnode. But they also use Servers, not laptops. I am not experienced enough to know why it works on they're site, but not on my local site.

[tjanczuk]

Client OSes (e.g. Windows 8) have a limit on the number of concurrent, incoming HTTP requests. I believe the limit is 10. The socket.io client always keeps one HTTP request open against the server (either WebSocket or HTTP long poll). That would explain why you cannot connect more clients.

The limit should not apply when you host your service on a server OS, e.g. Windows Server 2012.

[sjgillil]

Thanks, that helps a lot.

At least I know what is causing it now, and that I am not going to break my website when I deploy it!

P.S. thanks for iis node!

[queequac]

I am facing exactly the same issue.

Of course a desktop OS does not support more than 10 incoming requests, but nevertheless the behavior is completely different between iisnode and using node standalone.

With pure node the socket.io connection signals a 'disconnect' immediately when I reload the page or close the browser. On iisnode the connection signals the 'disconnect' when socket.io's pingTimeout applies, not any earlier. But it seems the connection is still around, because the situation does not relax afterwards. (By the way, the default pingTimeout is 1 minute, which is really awefull if it takes that long to realize that a client's real-time channel is actually not available anymore.)

Apparently the connection does not get closed properly in iis(node) until the application pool gets recycled.

(I am experiencing this on Win7-64)