Should we trust IIS for WebSocket ?
IIS 8 has already support WebSocket as I mention previously in my blog post. But I take a look at my notes again and see that there is a problem with IIS for maintaining long running service. I’m not familiar with IIS internal structure and still learning about that lately.
The problem is in IIS Recycle.
Here’s a couple discussion from NServicebus mailing list about that.
Here’s from another blog.
Take a look at the first commenter
Monday, June 16, 2008 11:23 PM by Rob Eisenberg
Just for the record…this type of HTTP push technique is often referred to as Comet. The real question is, how scalable is the server going to be? From everything I’ve been able to determine, it’s pretty much impossible to build a scalable Comet server for IIS. This is due to the way connections and threads are handled. I’ve tried to get some information from Microsoft about this, but they don’t have answers yet. Only time/experimentation will tell if the server is scalable enough to build a multi-player game or chat application. I’m hopeful, because the amount of work it takes to create a truly scalable socket server is tremendous.
I track it down from Udi Dahan blog post
You also quickly notice that is the reason why publishing message from the web server is a bad idea after dig deeper into NServiceBus.
The mostly used websocket server in .NET is SuperWebSocket. I see a interesting discussion about should we host websocket server into IIS or standalone windows service.
You’d better deploy it as a Windows Service. Because if you host it in IIS, you don’t know when the IIS will recycle the application pool.
So ? What do you think ?