Recently there has been much interest in the emergence of the HTML5 WebSocket protocol, and what it will mean for the real-time web. It is clear that WebSockets will represent a huge leap forward for JavaScript developers who wish to stream data to browser-based clients. Its relative simplicity is markedly more attractive than the arcane and elaborate use of IFrame-based “Comet” push or XHR long-polling techniques. The availablity of WebSocket as a single uniform technique to push data to browsers is compelling, and we anticipate that many vendors will begin to expose server functionality through WebSocket interfaces, leading to a significant increase in interactive web applications.
While we have chosen to add WebSocket support to Nirvana Realm Server and the JavaScript Client API, we continue to use native protocols for all our other APIs. Read on to find out our take on the pros and cons of WebSockets in a real-time messaging environment.
The WebSocket Protocol and API
The WebSocket protocol is designed to provide a two-way connection for transmitting data between a web browser and a server-side process. It emerged as part of the HTML5 specification and is intended to be used by scripts in web pages. The duplex connection is provided without the need to open multiple HTTP connections using the invariably inefficient, over-complicated and often browser-specific approaches involving XMLHttpRequest or IFrames.
The WebSocket is created by upgrading a client request from the standard HTTP protocol to the WebSocket protocol. Once upgraded to a WebSocket, the persistent HTTP connection can be used to send data back and forth in full duplex mode without the overhead or restrictions associated with new or parallel HTTP connections.
Within the context of Javascript, data will still need to be transmitted in text-based formats as Javascript has no support for binary data types today. This has obvious drawbacks for RIAs that require either low latencies or high throughput. For this reason alone, although there are many others, developers will continue to look to non-scripting languages coupled with browser plugins when performance is important.
The WebSockets API and protocol are currently being standardised by the W3C and IETF respectively.
WebSocket Support in Nirvana and the JavaScript API
Nirvana has supported real-time push to browsers since 1999. When the XML HTTP object became available we utilized this and employed a technique that later became known as “Comet”. Comet, as mentioned previously, has many drawbacks so we are pleased to see the WebSocket initiative gathering support. We feel the WebSocket protocol offers genuine benefits over the current “hand-rolled” JavaScript solutions, and have accordingly chosen to add WebSocket support to our Nirvana Realm Server and associated Nirvana JavaScript Client API. Our JavaScript API will now use WebSocket communication by default, unless the browser does not have WebSocket support (in which case the API will silently switch to traditional Comet-based communication).
The simplicity of the WebSocket protocol is also its greatest weakness. The WebSocket protocol merely defines one “send” method, and three callbacks: onopen, onread, onclose. There are no standard mechanisms in the protocol for handling idle connections and timeouts, disconnections and reconnections, or multiplexing and fragmented messages. The web development community have raised many WebSocket criticisms, often stemming from a desire for WebSocket to provide more than a basic emulation of a TCP/IP socket. We feel, however, that WebSocket will only become a successful and widely used standard if it remains simple. Most of these concerns should be addressed in a messaging implementation instead:
-
Support for Idle Connections
There are two choices for implementors of the protocol:
- Leave connections open indefinitely which is a Denial Of Service (DOS) attack risk
- Close each connection after an inactivity timeout period (e.g. HTTP timeout, which defaults to 30 seconds)
In practice, this means the messaging implementation must support some kind of keepalive mechanism in order to keep valid connections open. If one accepts the premise that WebSocket should mirror a TCP/IP socket, then this seems reasonable. The Nirvana WebSocket implementation will handle this transparently for developers.
-
Support for Connection Recovery
Like HTTP/1.1, a WebSocket connection can be closed by either end of the connection at any point in time as part of the normal operation. When this happens, neither end can be sure about the status of messages which may have been in transit. Once again, as WebSocket is designed to mirror the behaviour of a TCP/IP socket, this seems like the correct behaviour to us. The messaging implementation needs to step in in order to handle this. This is something that the Nirvana implementation does transparently through our transactional semantics and guaranteed delivery features.
-
Multiplexing
The protocol does not provide any concept of multiplexing messages. Messages written to a WebSocket do not contain any identifiers that would allow them to be associated with a specific stream / classification of messages. This also means that there is no in-built support for message fragmentation.
WebSocket is emulating the standard TCP/IP socket and messaging vendors may choose to layer support for multiplexing on top of this in the same way as they do for sockets. The Nirvana implementation for WebSocket will support both multiplexing and message fragmentation.
The Nirvana Javascript API, while communicating via a WebSocket where possible, thus abstracts away from the basic WebSocket API entirely, providing considerable levels of robustness and functionality which are absent from the underlying WebSocket protocol. Developers do not need to code against the WebSocket API, but instead continue to use the Nirvana JavaScript API’s unchanged public methods. Developers can transparently upgrade their existing Nirvana RIAs to employ WebSockets and gain transport efficiency improvements with a standard upgrade and without changing any code.
WebSocket Support in Non-JavaScript Nirvana APIs
While the WebSocket protocol was designed for and targeted at JavaScript clients, there have been suggestions that support of WebSockets may also be useful in non-scripted languages. The logic behind this is simple: a server which chooses to expose functionality via a WebSocket can be used identically by any client which supports the relatively simple WebSocket protocol, and which can parse and generate the application-specific messages which need to be received or sent, irrespective of platform or technology.
As mentioned earlier, Nirvana Realm Server and the JavaScript Client API both support WebSocket communication out of the box. We have not implemented WebSocket support in any of our other language APIs, however. Why have we chosen to add WebSocket support only to the JavaScript API, and not to all our various Client APIs?
| Target Environments | Communication Protocols | Messaging Paradigms | Extended APIs | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Enterprise | Web | Mobile | Native or Comet | Pub/Sub | Msg Queues | P2P | Admin | JMS | |
| Java |  |
|
 |
Native | |
|
|
|
|
| C# .NET | |
|
|
Native | |
|
|
|
|
| C++ | |
|
|
Native | |
|
|
|
|
| Excel VBA | |
|
|
Native | |
|
|
|
|
| JavaScript | |
|
|
Native (WebSocket) or Comet | |
|
|
|
|
| Adobe Flex | |
|
|
Native | |
|
|
|
|
| Microsoft Silverlight | |
|
|
Native | |
|
|
|
|
| iPhone | |
|
|
Native | |
|
|
|
|
| Android | |
|
|
Native | |
|
|
|
|
| .NET Compact Framework | |
|
|
Native | |
|
|
|
|
| Blackberry & J2ME | |
|
|
Native | |
|
|
|
|
As a middleware vendor, our role is to abstract our APIs and messaging functionality from the underlying communications stack, while ensuring that each platform utilizes the optimum transport protocols available to it. Our non-JavaScript APIs (Java, C#, C++, Silverlight, .NET CF, iPhone, Android, BlackBerry and more) already support Nirvana’s native binary protocols over raw or proxied sockets, using perfectly good communication stacks. Nirvana’s native socket protocols are highly optimized, provide fine-grained control at the packet level, and are as a result, extremely efficient; the additional overhead of a WebSocket wrapper would simply limit configuration options and needlessly introduce additional complexity and latency. WebSocket-based communication is therefore an inappropriate choice for these languages and APIs.
Growing Pains
Other minor issues still remain to be resolved. For example, the HTTP headers used to upgrade a plain HTTP connection to a WebSocket connection must be sent in a specific order; these orders may not always be respected by any intermediate proxy servers, resulting in corrupted handshake requests (and thus no WebSocket connections).
There have also been protestations about how the standard is managed, and by whom. The protocol emerged from WHATWG (a browser-vendor consortium chaired and led by a single Google employee, worryingly lacking in direct involvement from infrastructure suppliers of web servers, firewalls, proxies or load balancers), before being submitted to the IETF, who have traditionally managed the major Internet protcols such as HTTP, FTP, and SMTP. The IETF moved to take responsibility for the protocol, but the WHATWG appear unwilling to hand over editorial control. It is our opinion that the best way forward is for this protocol to be managed under the auspices of the IETF.
We believe that such teething problems will doubtlessly be resolved in due course, but in the meantime serve to highlight the present infancy of the protocol.
More Reading
Greg Wilkins of the JETTY foundation has been a strong voice commenting on the WebSocket protocol. His articles and blog posts provide a great overview of the standardization debate, as well as thoughts on how to improve WebSocket.
