A few months ago, I wrote a post about websockets and IIS7, explaining how some extensive hacking is needed to get websockets working and providing a link to an application that would accomplish just that. That post was very popular - Microsoft developers are obviously looking for ways to implement web sockets, and there is not a lot of documentation out there to assist them yet.
With the release of Windows Server 2012, Microsoft is now including native support for WebSockets. Unfortunately the 2008 hack (released by HTML5Labs) is now deprecated, and has been removed from the developer's website. Because there is so much interest, and no longer a fix to implement websockets in IIS7 that I am readily aware of, I am going to start putting together some information for developers here on IIS8. This post will just have the basics, and I will expand on the topic through later posts.
To get started, it is necessary to enable the WebSocket Protocol Module. The module is available as a Server 2012 feature. Launch Server Manager, select Manage, then click Add Roles and Features. Click Next. Select Role-based or feature-based installation, then select your server from the Destination Server Page. Click Next to skip past Roles and go straight to Features (If you haven't already enabled the IIS8 Server Role, do that before skipping the roles page). From Features, navigate to Internet Information Services --- World Wide Web Services --- Application Development Features --- WebSocket Protocol, Select it, click Next and then click Install. Features can also be added through PowerShell, by launching an elevated PowerShell session and using the Install-WindowsFeature command(Here is a link to a complete guide on adding Features and Roles in Server 2012).
With the Feature enabled, you are now ready to begin. So far, I am familiar with two ways of handling WebSockets requests. One is to use IHttpContext3's GetNamedContext API to point requests to the IWebSocketContext interface. Alternatively, you may also use the .NET 4.5 framework's new System.Web.WebSockets namespace and call the AspNetWebSocket class. We will expand further on these two topics in the next post on this topic.
While I prepare the next post, I would recommend consulting Brian Raymor's excellent post on WebSocket API implementation.
And for developers who are still stuck with Windows Server 2008 - I have not forgotten you! I am still looking for good published hacks, however for the time being, it may be worth checking out SignalR as one alternative to websockets, which relies on APM functionality for fast connections that can be deployed in 2008 and using older browsers.
With the release of Windows Server 2012, Microsoft is now including native support for WebSockets. Unfortunately the 2008 hack (released by HTML5Labs) is now deprecated, and has been removed from the developer's website. Because there is so much interest, and no longer a fix to implement websockets in IIS7 that I am readily aware of, I am going to start putting together some information for developers here on IIS8. This post will just have the basics, and I will expand on the topic through later posts.
To get started, it is necessary to enable the WebSocket Protocol Module. The module is available as a Server 2012 feature. Launch Server Manager, select Manage, then click Add Roles and Features. Click Next. Select Role-based or feature-based installation, then select your server from the Destination Server Page. Click Next to skip past Roles and go straight to Features (If you haven't already enabled the IIS8 Server Role, do that before skipping the roles page). From Features, navigate to Internet Information Services --- World Wide Web Services --- Application Development Features --- WebSocket Protocol, Select it, click Next and then click Install. Features can also be added through PowerShell, by launching an elevated PowerShell session and using the Install-WindowsFeature command(Here is a link to a complete guide on adding Features and Roles in Server 2012).
With the Feature enabled, you are now ready to begin. So far, I am familiar with two ways of handling WebSockets requests. One is to use IHttpContext3's GetNamedContext API to point requests to the IWebSocketContext interface. Alternatively, you may also use the .NET 4.5 framework's new System.Web.WebSockets namespace and call the AspNetWebSocket class. We will expand further on these two topics in the next post on this topic.
While I prepare the next post, I would recommend consulting Brian Raymor's excellent post on WebSocket API implementation.
And for developers who are still stuck with Windows Server 2008 - I have not forgotten you! I am still looking for good published hacks, however for the time being, it may be worth checking out SignalR as one alternative to websockets, which relies on APM functionality for fast connections that can be deployed in 2008 and using older browsers.