BWTP Rationale

The following points give the rational for why it was felt that an alternative to the websocket protocol was needed:

  • The BTWP protocol is very much an "IETF style" application protocol. In fact it is just RFC2616 with anything non bidirectional ripped out. It is not trying to be a revolution in web protocols, but simply to solve the problems at hand, without discarding decades of protocol experience. In constrast, the proposed Websocket protocol is a distinctly different protocol to HTTP.
  • The protocol document is written very much in "IETF style". In fact it is just RFC2616 with anything non bidirectional ripped out. BNF is used to specify the protocol and unlike the WebSocket proposal there are no binary blobs or algorithmic specifications.
  • The principal of "be strict in what you generate and forgiving in what your parse" is adhered to. In contrast, the proposed Webxocket protocol has taken an exacting approach and the authors require binary equivalence, so that even different orderings of headers in an upgrade request will be rejected.
  • Because of BWTPs similarity to HTTP, it is intended that existing HTTP clients, servers and intermediaries will be able to be minimally updated to support this protocol. This will not require entirely new protocol libraries to be developed.
  • Existing development and analysis tools will also be able to be easily updated, plus the protocol is mostly human readable.
  • BWTP supports full mime encapsulated payloads, so non text payload and/or compressed payloads can be sent without the need for client and server to make assumptions with regards to content. Websocket supports utf-8 and binary framing, but any more specific content types must either be assumed or transmitted in the body of the messages. Over the lifespan of the HTTP protocol, several compression algorithms have been commonly used, so it could be expected that new compression protocols will be developed in the lifespan of websocket. Currently websocket provides no way for a new compression protocol to be applied without updating the protocol specification and/or the application javascript.
  • BWTP has a default meta data mechanism, so that it can have detail per message meta data, but not at the expense of the redundant information sent in normal HTTP. The only meta data associated with a websocket protocol is from the original upgrade request (and then it is the binary equivalence of the spec will not allow any additional headers).
  • The minimal overhead per message is 11 bytes, which is a little more than the websocket proposal, but is hardly significant.
  • Connections may be easily multiplexed. Each message may have distinct URI associated with it, plus URI fragments may be used to create adhoc virtual channels to the same URI. This will allow multiple widgets, frames, tabs and windows in a browser to easily share a connection.
  • Content-Ranges are supported so that large content can be optionally segmented to allow efficient operations of virtual channels.
  • The protocol recognizes that intermediaries (proxies) may wish to be an active party on a bi direction connection. For example, this proposal allows an intermediary to initiate and orderly lossless close of the connection. I'm sure innovative proxy applications will be developed over time, just as they have been for HTTP.
  • BWTP well supports the current HTML WebSocket API but is also flexible and extensible so that non browser clients may use it and future APIs will not need protocol changes.
  • BWTP provides a simple virtual connection scheme that allows a single BWTP connection to be used for multiple WebSockets from a client to the same host.
  • BWTP provides a HTTP over BWTP mapping, so that a single connection can be used for both HTTP and BWTP messages. The HTTP is able to act as reverse HTTP (so that servers may send requests to clients) and virtual connections may be used to avoid HTTP response ordering limitations.