Comet Gazing: WebSocket

by Comet DailyAugust 7th, 2008

Comet Gazing is a semi-regular feature on Comet Daily. We pose a question to our Contributors and post the answers.

This time, we’ve asked our contributors the question: “With the recent addition of WebSocket to the HTML 5 recommendation, what impact will this have on your Comet implementation in both the short and long term? Do you see your approach to your preferred protocol changing as a result? What is your general impression of WebSocket?”

Martin Tyler

Web Sockets is an interesting development. For Caplin Liberator this will likely become a new transport, without anything public changing. This would hopefully provide a reliable streaming transport without relying on the various so called Comet hacks. The StreamLink for Browsers API (Javascript API) would not change to a user of the API, just because a socket-like API is available does not mean that is what should be presented to the user of a higher level API.

In the long term, I do not see this changing much. As more browsers implement WebSocket it would likely become the standard transport, but Liberator and StreamLink for Browsers are unlikely to change from a users perspective.

Frank Salim

WebSocket is already Kaazing’s preferred protocol! The protocol and API have many advantages that will liberate Comet from hacks. The interface resembles the familiar Berkeley Socket API that is the standard for all TCP networking. It includes framing to simplify JSON and XML-based messaging but does not prohibit carrying stream-oriented protocols in chunks. We take advantage of this fact to tunnel application layer protocols over WebSocket.

The Kaazing Enterprise Gateway is a WebSocket server supporting both native and emulated WebSocket connections. For browsers without native WebSocket capabilities, the client library provides a WebSocket using Flash. This allows us to use the standard protocol today. In cases where this is not possible (for instance, if the Flash plugin is not installed), the client falls back to two-connection, streaming transports. In both the native and emulated cases, the WebSocket API is exposed to JavaScript and Flex. Looking forward, this provides a seamless transition to WebSocket support in browsers.

Michael Carter

I’m a firm proponent of the WebSocket standard. I see WebSocket serving two major purposes:

  1. In the short-term, WebSocket will provide a performance boost to existing Comet Servers.
  2. More importantly, WebSocket allows developers to very easily extend existing servers so as to allow full-duplex browser communication. A Message Queue (or XMPP, IMAP, etc.) could simply listen for WebSocket connections, and talk directly to the browser.

Among Orbited’s top priorities is the facilitation of the second goal. As such, Orbited provides a WebSocket API in the browser that, when invoked, creates a fully compliant WebSocket connection not just to Orbited, but to the target WebSocket server. This allows an application developer to write a WebSocket server today, put Orbited in front, and everything will work, even through intermediaries like firewalls and proxies. Then, when the browser supports WebSocket natively, we can just remove Orbited and everything will still work (also through firewalls and proxies). Thus the primary purpose of Orbited is to actually facilitate the adoption of standards, not just to comply.

Kris Zyp

The WebSocket is a brilliant addition to the HTML 5 recommendation. It essentially solves all of the low-level transport issues of Comet, and yet leverages HTTP mechanisms to span proxies and upgrade the connection. WebSocket provides full duplex communication over a single TCP/IP connection (client and server can both send messages at any time), framing of messages, cross-site communication, and no legacy connection limit problems. Dojo will implement WebSocket support as soon as there is a web browser implementation (beta) available. Persevere leans on Jetty for socket handling, but both Jetty and Persevere will probably implement WebSocket support as soon as there is a browser implementation available.

The proposed RESTful Comet protocol, HTTP Channels, used by Persevere and implemented in Dojo is readily adaptable to a WebSocket. HTTP Channels will have JSON-based derivative that uses the same REST data notification semantics in the JSON format, and this will be easier to work with from the browser when used with a WebSocket. WebSocket will provide a significant improvement to HTTP Channels based data notification system.

Joe Walker

I like WebSocket very much. In theory it allows you to remove all the nasty nasty Comet hacks from your code and just use something simple. In practice the hacks will need to stay there until all the old browsers have gone away, but over time things will get simpler. In addition to being simpler, a WebSocket is also 2-way, and that’s not something you can hack your way around today.

The down-side in Java land is that while the individual servlet engines all support thread-dropping when doing Comet, and I’m sure they will be equally fast in implementing support for WebSocket, the servlet spec is a long way behind. The current version (2.5) doesn’t support thread-dropping, and it looks like the next revision (3.0) not only won’t be released for a long time, but also probably won’t support the WebSocket.

One day Comet in Java won’t be a dragon with multiple heads and multiple tails. WebSocket looks like a great step towards chopping of lots of troublesome heads. I look forward to similar server-side enhancements.

One Response to “Comet Gazing: WebSocket”

  1. Martin Tyler Says:

    One thing we face as suppliers of Comet servers in the corporate world is the various policies companies have with regards to production deployment.

    One of those often means they insist on putting a ‘reverse proxy’ in front of any web server (or comet server). We really dont recommend this since it will often reduce the capabilities of the Comet server in some way, but at the basic level they still work with Comet servers behind them, since its all standard HTTP. Often these are used to handle HTTPS with the onward communication to the Comet server in HTTP.

    WebSocket cleverly gets around client side proxy servers by using the CONNECT method which is intended for HTTPS, but is basically just asking the proxy to open up a socket to the specified server and not get in the way at all (since its encrypted data it can really get in the way, so why try).

    Howver, with reverse proxies on the server side, sitting in front of the Comet server, they will surely need specific support for WebSockets. This may be an obstacle to WebSocket usage.

Copyright 2015 Comet Daily, LLC. All Rights Reserved