Home > Atmosphere, Comet, Websocket > Websockets or Comet or Both? What’s supported in the Java EE land

Websockets or Comet or Both? What’s supported in the Java EE land

In preparation for the Atmosphere Framework 1.0.0 release, I’ve started listing what Java EE (or WebServer) supports in terms of Native Comet and WebSockets. This blog describes who supports what. I’ve also added a section describing what transport (WebSocket, Http Streaming, Long Polling or JSONP) Browsers are supporting, again tested using Atmosphere. Of course, Atmosphere supports both matrix, but that’s not the goal of this blog. I’ve also not included SPDY or Server Side Events Support because they are yet to be implemented by the majority of Servers.

Server Supports

The following table describes what Atmosphere supports but it can also be seen as what available in Java EE in general. The third and fourth columns are describing if the server has native support for Comet and WebSocket, by either supporting the ugly Servlet 3.0 API or if they have native implementation. The same apply for WebSockets native support (there is no WebSocket standard yet). Last four columns list the “most” popular transport, e.g WebSockets, Http Streaming (also called Forever Frame), Long-Polling and JSSONP. Note that servers like Tomcat 5 doesn’t support native Comet or WebSocket, but Comet can always be emulated by blocking a thread (this is what Atmosphere is doing when deployed there).

(LP: long-Polling HS: Http Streaming)

Server Version Native Comet Native WebSocket WebSockets LP HS JSONP
Netty 3.3.x X X X X X X
Jetty 5.x X X X
Jetty 6.x X X X X
Jetty 7.x X X X X X X
Jetty 8.x X X X X X X
GlassFish 2.x X X X X
GlassFish 3.x to 3.1.1 X X X X
GlassFish 3.1.2 X X X X X X
Tomcat 5.x X X X
Tomcat 6.x X X X X
Tomcat 7.0.26 and lower X X X X
Tomcat 7.0.27 and up X X X X X X
JBoss 5.x X X X
JBoss 6.x X X X X
JBoss 7.x X X X X
WebLogic 10.x X X X X
WebLogic 11.x and up X X X X
Resin 2.x X X X
Resin 3.x X  X X X X
WebSphere 7.x X X X
WebSphere 8.x X X X

Supported Browsers

The current list of Browsers have been tested with Atmosphere using the atmosphere.js Javascript library and the transport they supports.

Browser Version WebSockets Long-Polling Http Streaming JSONP
Firefox 3.x to 8.x X X X
Firefox 9.x to 11.x X X X X
Chrome 12.x and lower X X X
Chrome 13.x and higher X X X X
Internet Explorer 6x to 9.x X X X
Internet Explorer 10.x X X X X
Opera 10.x and lower X X
Opera 11.x X X X
Safari 4.x X X X
Safari 5.x X X X X
Android 2.x and up X X X
Safari (iOS) 1.x to 4.x X X X
Safari (iOS) 5.x X X X X

Note that I haven’t listed private/commercial/proprietary WebSockets implementations like Kaazing and JWebSocket or Pusher or framework like Cometd (who only works properly on Jetty).

That’s it. If you are planning to use WebSocket and Java EE, I strongly recommend you look at Atmosphere instead of using private native API and get stuck on a server forever. For more information, ping me on Twitter!

Categories: Atmosphere, Comet, Websocket
  1. April 21, 2012 at 6:24 pm

    Interesting post title. “WebSockets or Comet”. I’ve been thinking about writing about this for a while, and I’ve seen a number of comments and discussions previously about this (e.g. from Martyn Tyler of Caplin Systems and Jonas Jacobi of Kaazing). Can you really say WebSockets is an alternative to Comet when Comet servers use WebSockets? My current thinking is is that Comet is a paradigm, not only for server push but also for bi-directional communication. The need to do this with a web browser resulted in WebSockets – something which natively supported this in a way that HTTP did not. So, we have Comet to thank for WebSockets.

    The Wikipedia Comet entry (http://en.wikipedia.org/wiki/Comet_(programming)) states:

    > Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term, encompassing multiple techniques for achieving this interaction.

    Alex Russell’s original blog post (http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/) states:

    > Fundamentally, they all use long-lived HTTP connections to reduce the latency with which messages are passed to the server.

    > The architecture relies on a view of data which is event driven on both sides of the HTTP connection.

    All very HTTP related. But the second quote interestingly says “event driven on both sides”. This bi-directional communication, backed up by the diagram from the web post (http://infrequently.org/wp-content/Comet.png), seems to have been lost in the wikipedia entry.

    What I’m suggesting is that Comet is a paradigm for realtime bidirectional communication between a server and a client. Initially it used long-lived HTTP connections in addition to a second short-lived connection for command requests (e.g. subscribe) because it was the only solution. Comet servers now use WebSockets because they are available and help Comet (the paradigm) be achieved.

    I’m suggesting that HTTP Long-Polling or HTTP-Streaming (all using XMLHttpRequest, Script tag polling, IFRAMES, ActiveX objects) and WebSockets are transfer technologies that make the Comet paradigm possible.

    I’m suggesting that saying “Comet or WebSockets” and the Wikipedia article are incorrect and that this diagram better reflects the relationship between WebSockets and Comet:

    I’m prepared to be wrong. Interested in hearing your opinion.

  2. keaplogik
    April 25, 2012 at 6:38 pm

    The clear issue with your statement is that Websockets is a protocol, while Comet is a paradigm. Comet is a solution: communicating real time data over HTTP. The Websocket protocol does fit into this Comet paradigm, but can also solves other problems not applicable to Comet. WebSockets have their own security layer, and follow different rules. Comet or Websocket is a good comparison because, it is about: what else can Websockets solve? It solves the problem of hogging HTTP connections, true client to server push capabilities. It will be a standard and not a paridigm. A protocol, not a solution for Comet alone.

    • keaplogik
      April 25, 2012 at 6:53 pm

      keaplogik :
      The clear issue with your statement is that Websockets is a protocol, while Comet is a paradigm. Comet is a solution: communicating real time data over HTTP. The Websocket protocol does fit into this Comet paradigm, but can also solves other problems not applicable to Comet. WebSockets have their own security layer, and follow different rules. Comet or Websocket is a good comparison because, it is about: what else can Websockets solve? It solves the problem of hogging HTTP connections, true client to server push capabilities. It will be a standard and not a paridigm. A protocol, not a solution for Comet alone.

      double posted –

  3. keaplogik
    April 25, 2012 at 6:48 pm

    Websockets is an HTML 5 protocol. Comet is a paradigm of solving the transfer of real time data between client and server via HTTP. If we remove the HTTP from that statement, Websockets do fit into the Comet paradigm, but thats one solved problem. Websockets conform to their own rules (header data, encryption, etc..), don’t hog HTTP connections, and allow the server to not just stream content, but transfer content to the client in a way that is standard, or expected. Websockets may solve future issues that may not fit into your definition of Comet. We will have to wait and see, but to say Websockets is just a Comet paradigm is a little naive.

  4. April 27, 2012 at 5:06 pm

    I noticed that Weblogic 12.x is missing from the table of supported servers. Is it specifically NOT supported, or has it just not been qualified yet? I’m about to start on a project that will use Weblogic 12c and I would like to use Atmosphere with it.

    • April 27, 2012 at 5:11 pm

      Oh! Added 11.x and up. WebLogic 12 supports Servlet 3.0 so it will works pretty well with Atmosphere.
      Thanks!

  5. June 14, 2012 at 11:16 pm

    I try to use Weblogic 12c with Atmosphere but I always get:
    java.lang.IllegalStateException: The async-support is disabled on this request: weblogic.servlet.internal.ServletRequestImpl@19c1438[

    top of the trace:
    at weblogic.servlet.internal.ServletRequestImpl.startAsync(ServletRequestImpl.java:1830)
    at weblogic.servlet.internal.ServletRequestImpl.startAsync(ServletRequestImpl.java:1806)
    at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:527)

    I miss something?

  6. Alex
    August 17, 2012 at 1:39 pm

    So, does it mean that if there is not support for Web Sockets in Server Support and client will try to connect using HTML5 Web Socket the request will fail?
    So, if I would like to use Tomcat6 and socket.io or atmosphere.js as js client library and user uses the modern browser, so my application will fail, because socket.io/atmosphere.js will use Web Socket as the transport protocol, but browser doesn’t support it. Or you provide fallback (emulation) for web socket transport for the server if server doesn’t support it?

    Also here (https://github.com/Atmosphere/atmosphere/wiki/Supported-WebServers-and-Browsers) is mentioned: that Websocket emulation is not yet supported.
    Is it still not yet supported and what does it mean Websocket emulation in term of server?

    Thank you.

  1. April 22, 2012 at 6:58 pm
  2. April 23, 2012 at 8:02 am
  3. May 16, 2012 at 2:10 pm
  4. May 18, 2012 at 2:54 pm
  5. May 28, 2012 at 10:46 pm
  6. June 4, 2012 at 8:57 pm
  7. August 27, 2012 at 1:50 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 51 other followers

%d bloggers like this: