The WebSockets Prototype Gets Another Update
As we continue to move forward with updating the prototypes on our HTML5 Labs site as quickly as possible, I am happy to tell you that we have once again updated the WebSockets prototype, a move that brings the implementation in line with the recently released WebSockets 05 Protocol Specification.
The 05 spec introduces some changes to the masking algorithm. Specifically, the masking key is no longer derived from the information that client and server exchange during the handshake, but is now fully contained within each frame.
WebSockets is a technology designed to simplify much of the complexity around bi-directional, full-duplex communications channels, over a single Transmission Control Protocol (TCP) socket. It can be implemented in web browsers, web servers as well as used by any client or server application.
Also, as we strongly believe that interoperability is very important, we have tested our implementation with another 05 WebSockets implementation that uses C++ and runs on Linux: libwebsockets.
In order to verify this, we setup a Fedora Linux machine with libwebsockets in our Interoperability lab. We also set up another Windows 2008 R2 machine in the lab, and installed our WebSockets 05 prototype bits on it. Libwebsockets already comes with client and server samples, so we decided to use those for testing.
The configurations we tested are:
Server: libwebsockets
Client: html5labs prototype
In this configuration we ran the test libwebsockets server on Fedora Linux, which accepts a client connection and sends incrementing integer values to the client every 50ms. The server resets the counter to 0 whenever it receives “reset” from the client.
This screenshot shows the libwebsockets test server starting and then confirming the handshake
This screenshot shows the HTML5 Labs test client starting and then confirming the handshake
For the client we created a .NET console application, which uses Microsoft.ServiceModel.WebSockets.DesktopClient.dll (the library that we have been releasing with the WebSockets prototypes). The application creates a WebSocket connection to the Fedora machine, and receives incrementing integers from the server. When it reaches the count of 200, it sends “reset” to the server.
Server: html5labs prototype
Client: libwebsockets
In this configuration we created an equivalent .NET application, which acts as a server and sends incrementing integers to the client every 50ms. This application uses Microsoft.ServiceModel.WebSockets.dll (the library that we have been releasing with the WebSockets prototypes). We ran the client sample on the Fedora machine, which creates a WebSocket connection to the Win2008 server machine, and receives incrementing integers.
This screenshot shows the HTML5 Labs test server starting and then confirming the handshake
This screenshot shows the libwebsockets test client starting and then confirming the handshake
This prototype forms part of our HTML5 Labs Web site, a place where we prototype early and not yet fully stable drafts of specifications developed by the W3C and other standard organizations. The WebSocket API is currently being standardized by the W3C and the WebSocket protocol is being standardized by the IETF.
We believe that the HTML5 Labs approach has advantages over placing unstable specifications directly in the browser. First, developers can build on Internet Explorer 9 without worrying that their site will break as the underlying specs change. Second, we will iterate very quickly in HTML5 Labs and expect the standalone approach with prototypes to be closer to the latest specs. As an example with WebSockets, most browsers are still on the outdated versions of WebSockets-00 or older.
Building these prototypes in a timely manner will also help us have informed discussions with developer communities, and give implementation experience with the draft specifications that will generate feedback to improve the eventual standards.
Claudio Caldato,
Principal Program Manager, Interoperability Strategy Team