Latest WebSockets Release Interoperates with Firefox, Eclipse’s Jetty

We have updated the WebSockets prototype on our HTML5 Labs site, which brings the implementation in line with the recently released WebSockets 06 Protocol Specification.  

We have extended our interoperability testing so that now, along with LibWebSockets, we tested interoperability with Jetty, an open-source project providing an HTTP server, HTTP client, and javax.servlet container, developed by the Eclipse community, and we accepted the invitation of Patrick to test our code with a Firefox Mindfield version he built with an implementation of the 06 Protocol Specification.

We tested the WebSockets interoperability between our HTML5 Labs prototype client and Jetty server, which recently added support for the 06 version of the spec (you can find the Jetty code here.)

We also tested the WebSockets interoperability with a test Firefox build that supports the 06 protocol specification. We are hosting a chat demo page on Azure, which can be opened in Firefox and will use native browser WebSocket instead of the Silverlight-based one. 

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.

This fourth update of our WebSocket prototype brings ping-pong support: automatic client to server ping every 50 seconds. It also now supports the binary and fragment frames feature defined in the WebSocket protocol specification, but they are not yet exposed to javascript because the W3C API working group is still working on defining a set of APIs that can work with binary data. 

Jetty Testing

Our testing involved setting up Jetty server on Win2K8 server machine, and hosting a chat WebSocket endpoint, which has the same functionality as this chat sample

 We then directed our existing chat client web page to use the Jetty-hosted endpoint (instead of WCF-hosted endpoint), and we confirmed that the chat app was fully functional. 

This screenshot shows the chat page opening a WebSocket connection to ws://localhost:4502/chat



This screenshot shows Jetty server accepting the WebSocket connection from the browser


This screenshot shows the chat page connected to Jetty WebSocket connection


And, as I said earlier, we are hosting the Jetty chat endpoint on Azure, and have updated our existing chat demo to use it. To deploy the Jetty endpoint in Azure, we used the recently released Windows Azure Starter Kit for Java, developed by our Interoperability team.

Firefox Testing

Our testing involved hosting a chat WebSocket endpoint using the WCF-based HTML5 Labs prototype.

 We modified our existing chat page to use native browser WebSocket API (instead of the HTML5 Labs WebSocketDraft API), and we confirmed that the chat app was fully functional.  

This screenshot shows the chat page works in Firefox using native browser WebSocket API 

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.

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

Comments (4)

  1. Senthilkumar Peelikkampatti says:

    Very nice summary. Thanks. I would like to see where MS with respect to IE9. I am sure something is brewing at IE9 but like to know fallback option for already released IE9.  Do you have any plugins for testing it with IE?

  2. Greg says:

    I have been working with the Silverlight prototype to create a C# html/WebSocket server (no IIS).  It hopefully will work with high throughput web UI's, like the sort of controls one might use for controlling parameters in audio systems.  For instance, a volume control that one could quickly change with a mouse or touch UI.

    Troubleshooting my code and using WireShark, I had some 'packet issues'.  It seems to involve the Nagle algorithm setting (Socket.NoDelay), which solved the packets from my application.  Conversely, the Silverlight prototype does seem to use it, and hence, combines packets.  I'm not familiar with Silverlight, and I don't know if the code is available or has been included in the downloads.  Help!

  3. Pat says:

    At this time the websocket port 4502 seems to be blocked on that server.. (i.e. 80 routes through, 4502 just drops the syns).. I have a clean path internet.

  4. Michael says:

    First, I wanted to say that say that it's great to see websocket support in WCF. I'm wondering if there a time frame for when the WCF WebSocket code will be updated to work with current browsers such as the shipping version of Firefox 4, Chrome 10, etc? I've found that the only browser that works with the WCF WebSockets 11.03.10 drop is the Beta 13 version of Firefox. Both the shipping Firefox 4 and Chrome 10 fail to connect to a 11.03.10 WCF WebSocket service.

Skip to main content