The WebSocket protocol, design by committee and requirements tracing

I've been working with the WebSocket protocol recently, updating the code that implements the protocol in The Server Framework to the latest version of the draft standard (the HyBi 09 version). Whilst this looks like it's almost a real standard, there are still lots of potentially open issues as can be seen from the HyBi discussion mailing list.

It's quite clear from some of the less cohesive parts of the draft spec (and more so from the mailing list) that the protocol is very much a design by committee effort. This is both good and bad: It's good that the protocol includes support for a wide range of use cases and, well, it's bad that the protocol is more complex because it includes support for a wide range of use cases...

It would be fascinating (and time consuming) to read through the discussion lists from the start and track the reasons behind the various changes and evolutionary steps that the protocol has gone through. Unfortunately, at present some of the elements of the protocol require you to do that if you want to understand why they exist. Without reading all of the discussion list there's a lack of traceability from the various elements of the protocol to the various use case requirements that caused them to be included. Given the evolution of the protocol it's likely that some areas of the protocol have become detached from the original requirements (as other areas have been modified and now no longer support the original requirements, for example, the idea that WebSockets is a message based protocol is undermined by defining a message in terms of an infinite number of fragments without any form of message length indication).

All of this means that implementing the protocol from the current RFC is harder than it needs to be and often the wording of the RFC itself will lead you towards designs that don't work well with the actual protocol. Ideally all of these loose ends will get cleaned up before the standard is ratified but the protocol has been in draft form for a long time and I'm sure some would prefer it to be ratified as is rather than go through yet another round of changes...

I've been accumulating several rants about the protocol and I'll be presenting them as stand alone blog entries (mainly because they've each grown too large to be joined together in one entry). Often the solution to my frustrations would simply be a modification of the descriptive portions of the RFC text to give a little more explanation as to the thoughts behind the decisions.

Leave a comment

About this Entry

Movable Type upgrade annoyance was the previous entry in this blog.

WebSockets is a stream, not a message based protocol... is the next entry in this blog.

I usually write about C++ development on Windows platforms, but I often ramble on about other less technical stuff...

Find recent content on the main index or look in the archives to find all content.

I have other blogs...

Subscribe to feed The Server Framework - high performance server development
Subscribe to feed Lock Explorer - deadlock detection and multi-threaded performance tools
Subscribe to feed l'Hexapod - embedded electronics and robotics
Subscribe to feed MegèveSki - skiing