Back in early 2010 I wrote an immensely long piece called HTML5; a section called How To Spec? took a baffled look at one of the many HTML5 sub-projects, WebSockets.
I was puzzled because the structure of the spec read like nothing I’d ever encountered; in particular nothing I’d ever seen in the IETF, where the work was sort of being done. I went so far as doing a strawman alternate draft in a more conventional style, as an exercise in comparison.
Subsequently, I got involved slightly in the IETF working group, and found that the process was as strange as the spec it was producing; an attempt to embed the idiosyncratic WHATWG process in the IETF context; which is at least as idiosyncratic, but well-worked out and has produced some pretty good results, for example the Internet.
It was obvious that there was a pretty complete disconnect between the two worlds; both in the ways that issues were addressed, and in the goals. I have never understood why the WHATWG has tried to embed parts of its work in other organizations like W3C or the IETF; and after observing this episode, I still don’t.
I’m not going to revisit the bizarre turns the conversation took; but today I ran across a long-buried browser tab containing the announcement of RFC6455, the WebSockets protocol, as a finished IETF work product. It’s in the traditional IETF style and was built in the traditional way. So long strange stories sometimes if not always have ends.
I should note that to this day, there are some who are extremely skeptical of the benefits, indeed the architectural soundness, of WebSockets, seeing it as another attempt to use Port 80 to route around all those annoying security restrictions that get in people’s way.
I don’t know, myself; I haven’t worked on any apps in recent years that needed this sort of persistent-binary-connection architecture. I have noted a buzz of conversation in the last few days around BrowserQuest, a Mozilla.org offering based on lots of HTML5 gooey goodness notably including WebSockets. So maybe they really are a big deal.
Contributions
Comment feed for ongoing:
From: Julian Reschke (Mar 29 2012, at 00:09)
It's worth noting that the protocol went through multiple incompatible changes, and that Safari, even in it's latest and greatest incarnations, does *not* support the version defined in the RFC.
[link]
From: Francis Stephens (Mar 29 2012, at 05:59)
Not related to the question of spec and standards processes but it is interesting to ask the question of whether web sockets are architecturally sound.
It certainly seems that for games like BrowserQuest they are more or less necessary. But they do have a crucial property that a long lived connection lives on one server - for a long time.
I have a location service where users are notified about other nearby users. However, whenever I look at scaling the server responsible for this across multiple threads or machines, I am always concerned by this massive fan-in effect. Where multiple servers or threads will have to send nearby notifications back to a single process to have that information sent down a specific connection. This seems like it may become a bottleneck.
I don't know how this approach will turn out. I have thought about using Server-Sent Events instead, but that is newer than websockets and is getting less attention, so I don't feel secure that the support will be there.
I think that forgoing long lived connections is a very useful tool for simplifying and scaling up web services. If we use websockets unwisely we could end up painting ourselves into a corner.
Anyone has any thoughts on this? Some experience would be great to hear about.
[link]
From: Ron Hochsprung (Mar 29 2012, at 11:23)
I just used the latest Safari to test the Web Sockets eco server, and it reported that "This broswer spports WebSockrt". And, I was able to connect and send an echo request and get a response.
This was also true with Safari on my iPad 3.
[link]
From: Jonas (Mar 29 2012, at 22:32)
I believe that we sometimes forget that HTML5 is designed to better support development of Web applications, not Web sites. In comparison to traditional desktop applications the Web has s far lacked a few important "native" components to enable Web applications to be truly interactive. One of these components was an alternative way of communication. WebSocket is not here to replace HTTP nor was it designed to. It is here to help us build applications that otherwise would be stuck in old school client-server (TCP-based) environment and to enable us to build new cool applications - games, social networks, CRM, Ads, or e.g. http://vimeo.com/38902371
[link]
From: Randell Jesup (Mar 30 2012, at 06:22)
You should also take a look at WebRTC, an effort that started at WhatWG and has now moved to a combination of IETF (for the bits-on-the-wire parts) and W3 (for the JS API parts).
While WebSockets is all about client-server communication in place of TCP sockets, WebRTC is all about peer-2-peer audio/video (and data!) communication. While the obvious targets are Skype and WebEx type applications, there are many more ways it can be used, for example in games. It can even be used in pure data-only connections, and supports not just TCP-like channels, but also unreliable and partly-reliable datagrams. (The underlying protocol is SCTP, running over an encrypted DTLS connection, all over UDP+ICE.)
[link]
From: KL (Mar 30 2012, at 06:50)
@Francis: for notifications (from server to client, not client to server) you don't need WebSockets.
There's EventSource (AKA Server-Sent Events) which a creates light-weight, persistent, *HTTP-compatible* connection between server and the client.
EventSource JS API is basically the same as for WebSockets.
So as long as you don't need real-time sending, EventSource is faster (shorter handshake, less overhead), easier (handles network errors, retries for you) and more architecturally sound (it's not HTTP-like fudge, it *is* HTTP).
[link]