Jump to content

Comet (programming)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Restepc (talk | contribs) at 16:16, 1 June 2008 (moved section, removed spam magnet note, will change extrernal links to references). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

[original research?]

Template:Otheruses2 Comet is a World Wide Web application architecture in which a web server sends data to a client program (normally a web browser) asynchronously without the client explicitly requesting it. It allows creation of event-driven web applications. Though the term Comet was coined in 2006, the idea is several years older, and has been called various names, including server push, HTTP push, HTTP streaming, Pushlets, Reverse Ajax, and others.

Comet applications use long-lived HTTP connections between the client and server, which the server can respond to lazily, pushing new data to the client as it becomes available. This differs from the traditional model of the web, in which a browser receives a complete web page in response to each request, and also from the Ajax model, in which browsers request chunks of data, used to update the current page. The effect is similar to applications using traditional Ajax with polling to detect new information on the server.

Comet does not refer to any specific technique for achieving this user-interaction model, but encompasses all of them—though it implies the use of browser-native technologies such as JavaScript as opposed to proprietary plugins. Several such techniques exist, with various trade-offs in terms of browser support and side effects, latency, and throughput.

Web application architectures

Web applications have always been less flexible and capable than desktop applications, due to the restrictions placed on their access to local and network resources, and the limitations of in-browser program environments. As web browsers have evolved, many of these limitations have been lifted or worked-around, bringing so-called rich Internet applications closer to desktop-application–like functionality.

One of these traditional limitations is that each chunk of information sent by a web server to a browser must be explicitly requested. Comet is one of the ways to address this limitation, allowing applications to respond to events external to the browser, such as updates to a data source, or messages sent by another user. Comet is best understood in comparison with web application architectures which suffer this limitation.

Browser compatibility

Because browsers are not designed with Comet in mind, comet's “transports” (methods of sending Comet events) are usually implemented through several unintended side-effects of browser-native objects , each with different benefits and drawbacks. Each of these requires specialized code on both the server, which must send specially-formed responses, and in the browser-side.[1]

The earliest Comet transport (in use as early as 2000) uses an invisible IFrame HTML element declared by the server to be infinitely long—hence “forever frame”—and as events occur, is gradually filled with script code that is executed as it is received.

The main benefit of the IFrame method is that it works in every common browser. A downsides is that the continually loading IFrame causes many browsers to display undesirable visual artifacts such as loading bars and wait cursors, though adding additional Iframes to the page will eliminate these artifacts in some browsers.[1]

Server-sent events

In 2005[citation needed], the Web Hypertext Application Technology Working Group (WHATWG), included as part of the draft HTML 5 specification a technology called server-sent events, it attempts to avoid the disadvantages of other Comet transports, while making Comet applications much more straight-forward to implement, both on the server side, and in the browser-side.[2]

The server-sent event portions of the HTML 5 specification stipulate both a new HTML element, event-source, and a new data format, called the DOM event stream. Browser scripting can be used to attach callback functions to multiple types of events. Because server-sent events can be received by an HTML element in the browser, the specification leaves room for future browsers to implement special behavior for some event types.

Alternatives

Instead of using browser-native technologies to provide persistent connections, some developers[who?] instead turn to plugins, such as Java applets or the proprietary Adobe Flash. These have the advantage of working identically across all browsers with the appropriate plugin installed and need not use HTTP connections. However, not all clients have the plugins installed—for instance, the Apple iPhone includes neither—and the use of protocols other than HTTP, and ports other than port 80, can cause them to be blocked by firewalls.

Scalability

Because Comet applications may send events at any time, they typically use more resources than other types of web applications, making them more difficult to scale[3].

Additionally, because Comet applications are often interactive, splitting tasks among servers is more difficult than for applications in which each user acts independently.

Some Comet applications are organized in terms of a publish/subscribe (pub/sub) architecture[3] , and some Comet servers are explicitly organized around publish/subscribe.

Real world use

In 2005 and 2006, some applications exposed Comet to a wider audience, like Meebo’s chat application, Gmail[citation needed], JotSpot and Renkoo.

The WHATWG's HTML 5 specification attempts to standardize the Comet transport[citation needed].

Implementations

There are several Comet implementations, both commercial and non-commercial: You must add a |reason= parameter to this Cleanup template – replace it with {{Cleanup|reason=<Fill reason here>}}, or remove the Cleanup template.


Open source:

  • Cometd – Comet framework sponsored by the Dojo foundation.
  • Orbited – cross-language scalable Comet server.
  • Meteor – Comet server written in Perl.
  • jQuery Comet Plugin – Comet plugin for jQuery.
  • Athena – part of the Divmod Nevow web framework; written in Python/Twisted.
  • Pushup – Comet server written in C++.
  • Pushlets – framework enabling server-side Java objects to push events to browser-side JavaScript, Java applets, or Flash.
  • Jetty-6 - Servlet server written in java with asynchronous features used for comet implementations directly or via activemq, cometd, DWR and others.
  • Apache Tomcat 6.0 – Advanced IO and Tomcat; Comet support allows a servlet to process IO asynchronously.
  • Asteroid (a small Comet) – Comet in Squeak (Smalltalk), by Diego Gomez Deck.
  • ShootingStar – event-based – Comet server implemented in Ruby and C.
  • Full-duplex Ajax – A module for the Lighttpd web server
  • ItsNat – a Java Ajax component-based web application framework, with Comet support.
  • Sun Microsystems GlassFish – Comet for Servlet/Java EE based applications, support DWR, Cometd, ICEFaces and IO asynchronously via Grizzly
  • Resin - Java Application Server with a Comet server API similar to Java Servlets.
  • Comep – a PHP Comet server implementation, by Aresch Yavari.
  • Xajax – a plugin for the Xajax library. Supports streaming of Xajax commands for IE/FireFox/Safari/Opera
  • Seaside Comet - Comet library for Seaside (Smalltalk), by Lukas Renggli.
  • pi.comet – Simple Comet Class
  • ErlyComet - Bayeux compliant functionality for Erlang.

Proprietary:

  • Caplin Liberator – Comet server written in C intended for financial trading. Liberator also has a Free Edition
  • KnowNow – Implementation of Comet. Link goes to a description of the KnowNow Enterprise Syndication Solution.
  • Lightstreamer – Comet solution. Push engine for live data distribution to rich internet applications.
  • Virgil’s Live is a Comet tookit for any zero client streaming data to web front end
  • Virgil’s One is a commercial Comet implementation (based on Live)for streaming market data for retail, wholesale, private banks, and brokers for IBM Websphere Portal
  • Kaazing Enterprise Comet provides an advanced environment for creating real-time Web applications that extend SOA's event and message delivery to the browser
  • The SmartClient messaging module.
  • Steve and Jay McDonald’s Fjax.
  • Ajax for IBM WebSphere Platform – Early Comet support for IBM WebSphere-based Products (6.1+)
  • Lingr – Browser-based chat community using Comet for realtime message notification
  • LiveCycle Data Services – previously named Flex Data Services, an enterprise solution from Adobe, supporting both Ajax and Flex.
  • Clipstream
  • CogStream.
  • Ajax Message Service from TIBCO – enterprise real-time messaging and SOA.
  • HTTP Pub-Sub Server – Comet support in BEA's WebLogic Server product (10.3+).

Unknown:

  • AjaxMessaging – Comet plugin for Ruby on Rails using Ajax and Messaging Oriented Middleware.
  • PushAsp – A general purpose Comet server for Asp.Net, Silverlight or plain html.
  • ICE Technology Corp’s iPush Server – Real-time push data to RIA's.

References

  1. ^ a b "Browser Techniques". Meteor website. Retrieved 2008-05-30.
  2. ^ Ian Hickson, et al. (2005–2008). HTML 5 specification, § 6.2: Server-sent DOM events. WHATWG. Retrieved 14 Dec 2007.
  3. ^ a b Michael Carter (24 October 2007). “Comet for Highly Scalable Applications”. Presentation at The Ajax Experience Boston. (Link goes to PDF slides). Retrieved 30 Nov 2007.