Comet (programming)

From Wikipedia, the free encyclopedia
Jump to: navigation, search

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.[1][2] Comet is an umbrella term, encompassing multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins. The Comet approach differs from the original model of the web, in which a browser requests a complete web page at a time.[3]

The use of Comet techniques in web development predates the use of the word Comet as a neologism for the collective techniques. Comet is known by several other names, including Ajax Push,[4][5] Reverse Ajax,[6] Two-way-web,[7] HTTP Streaming,[7] and HTTP server push[8] among others.[9]

History[edit]

Early Java applets[edit]

The ability to embed Java applets into browsers (starting with Netscape 2.0 in March 1996[10]) made real-time communications possible, using a raw TCP socket[11] to communicate between the browser and the server. This socket can remain open as long as the browser is at the document hosting the applet. Event notifications can be sent in any format — text or binary — and decoded by the applet.

First Comet applications[edit]

In April 2001 Chip Morningstar began developing a Java-based (J2SE) web server which used two HTTP sockets to keep open two communications channels between the custom HTTP server he designed and a client designed by Douglas Crockford; a functioning demo system existed as of June 2001.[12] The server and client used a messaging format that the founders of State Software, Inc. assented to coin as JSON following Crockford's suggestion. The entire system, the client libraries, the messaging format known as JSON and the server, became the State Application Framework, parts of which were sold and used by Sun Microsystems, Amazon.com, EDS and Volkswagen.[13]

In March 2006, software engineer Alex Russell coined the term Comet in a post on his personal blog.[14] The new term was a play on Ajax (Ajax and Comet both being common household cleaners in the USA).[15][16][17]

Even if not yet known by that name, the very first Comet implementations date back to 2000,[18] with the Pushlets, Lightstreamer, and KnowNow projects. Pushlets, a framework created by Just van den Broecke, were one of the first[original research?] open source implementations. Pushlets were based on server-side Java servlets, and a client-side JavaScript library.[19] Bang Networks — a Silicon Valley start-up backed by Netscape co-founder Marc Andreessen — had a lavishly-financed attempt to create a real-time push standard for the entire web.[20]

In 2006, some applications exposed those techniques to a wider audience: Meebo’s multi-protocol web-based chat application enabled users to connect to AOL, Yahoo, and Microsoft chat platforms through the browser; Google added web-based chat to Gmail; JotSpot, a startup since acquired by Google, built Comet-based real-time collaborative document editing.[21] New Comet companies and enterprise solutions were created, such as the Java-based ICEfaces JSF framework (although they prefer the term "Ajax Push"[5]). Others that had previously used Java-applet based transports switched instead to pure-JavaScript implementations.[22]

Implementations[edit]

Comet applications attempt to eliminate the limitations of the page-by-page web model and traditional polling by offering real-time interaction, using a persistent or long-lasting HTTP connection between the server and the client. Since browsers and proxies are not designed with server events in mind, several techniques to achieve this have been developed, each with different benefits and drawbacks. The biggest hurdle is the HTTP 1.1 specification, which states that a browser should not have more than two simultaneous connections with a web server.[23] Therefore, holding one connection open for real-time events has a negative impact on browser usability: the browser may be blocked from sending a new request while waiting for the results of a previous request, e.g., a series of images. This can be worked around by creating a distinct hostname for real-time information, which is an alias for the same physical server. This strategy is an application of domain sharding.

Specific methods of implementing Comet fall into two major categories: streaming and long polling.

Streaming[edit]

An application using streaming Comet opens a single persistent connection from the client browser to the server for all Comet events. These events are incrementally handled and interpreted on the client side every time the server sends a new event, with neither side closing the connection.[3]

Specific techniques for accomplishing streaming Comet include the following:

Hidden iframe[edit]

A basic technique for dynamic web application is to use a hidden iframe HTML element (an inline frame, which allows a website to embed one HTML document inside another). This invisible iframe is sent as a chunked block, which implicitly declares it as infinitely long (sometimes called "forever frame"). As events occur, the iframe is gradually filled with script tags, containing JavaScript to be executed in the browser. Because browsers render HTML pages incrementally, each script tag is executed as it is received. Some browsers require a specific minimum document size before parsing and execution is started, which can be obtained by initially sending 1-2 kB of padding spaces.[24]

One benefit of the iframe method is that it works in every common browser. Two downsides of this technique are the lack of a reliable error handling method, and the impossibility of tracking the state of the request calling process.[24]

XMLHttpRequest[edit]

The XMLHttpRequest (XHR) object, the main tool used by Ajax applications for browser–server communication, can also be pressed into service for server–browser Comet messaging, in a few different ways.

In 1995, Netscape Navigator added a feature called “server push”, which allowed servers to send new versions of an image or HTML page to that browser, as part of a multipart HTTP response (see History section, below), using the content type multipart/x-mixed-replace. Since 2004, Gecko-based browsers such as Firefox accept multipart responses to XHR, which can therefore be used as a streaming Comet transport.[25] On the server side, each message is encoded as a separate portion of the multipart response, and on the client, the callback function provided to the XHR onreadystatechange function will be called as each message arrives. This functionality is included in Gecko-based browsers, there is discussion of adding it to WebKit.[26] Internet Explorer 10 also supports this functionality.[27]

Instead of creating a multipart response, and depending on the browser to transparently parse each event, it is also possible to generate a custom data format for an XHR response, and parse out each event using browser-side JavaScript, relying only on the browser firing the onreadystatechange callback each time it receives new data.

Ajax with long polling[edit]

None of the above streaming transports work across all modern browsers without negative side-effects. This forces Comet developers to implement several complex streaming transports, switching between them depending on the browser. Consequently many Comet applications use long polling, which is easier to implement on the browser side, and works, at minimum, in every browser that supports XHR. As the name suggests, long polling requires the client to poll the server for an event (or set of events). The browser makes an Ajax-style request to the server, which is kept open until the server has new data to send to the browser, which is sent to the browser in a complete response. The browser initiates a new long polling request in order to obtain subsequent events. Specific technologies for accomplishing long-polling include the following:

XMLHttpRequest long polling[edit]

For the most part, XMLHttpRequest long polling works like any standard use of XHR. The browser makes an asynchronous request of the server, which may wait for data to be available before responding. The response can contain encoded data (typically XML or JSON) or Javascript to be executed by the client. At the end of the processing of the response, the browser creates and sends another XHR, to await the next event. Thus the browser always keeps a request outstanding with the server, to be answered as each event occurs.

Script tag long polling[edit]

While any Comet transport can be made to work across subdomains, none of the above transports can be used across different second-level domains (SLDs), due to browser security policies designed to prevent cross-site scripting attacks.[28] That is, if the main web page is served from one SLD, and the Comet server is located at another SLD (which does not have cross-origin resource sharing enabled), Comet events cannot be used to modify the HTML and DOM of the main page, using those transports. This problem can be sidestepped by creating a proxy server in front of one or both sources, making them appear to originate from the same domain. However, this is often undesirable for complexity or performance reasons.

Unlike iframes or XMLHttpRequest objects, script tags can be pointed at any URI, and JavaScript code in the response will be executed in the current HTML document. This creates a potential security risk for both servers involved, though the risk to the data provider (in our case, the Comet server) can be avoided using JSONP.

A long-polling Comet transport can be created by dynamically creating script elements, and setting their source to the location of the Comet server, which then sends back JavaScript (or JSONP) with some event as its payload. Each time the script request is completed, the browser opens a new one, just as in the XHR long polling case. This method has the advantage of being cross-browser while still allowing cross-domain implementations.[28]

Alternatives[edit]

Browser-native technologies are inherent in the term Comet. Attempts to improve non-polling HTTP communication have come from multiple sides:

  • The HTML 5 draft specification produced by the Web Hypertext Application Technology Working Group (WHATWG) specifies so called server-sent events,[29] which defines a new JavaScript interface EventSource and a new MIME type text/event-stream. Experimental implementation of this feature was introduced in Opera 9.[30]
  • The HTML 5 WebSocket API working draft specifies a method for creating a persistent connection with a server and receiving messages via an onmessage callback.[31]
  • The Bayeux protocol by the Dojo Foundation. It leaves browser-specific transports in place, and defines a higher-level protocol for communication between browser and server, with the aim of allowing re-use of client-side JavaScript code with multiple Comet servers, and allowing the same Comet server to communicate with multiple client-side JavaScript implementations. Bayeux is based on a publish/subscribe model, so servers supporting Bayeux have publish/subscribe built-in.[32]
  • The BOSH protocol by the XMPP standards foundation. It emulates a bidirectional stream between browser and server by using two synchronous HTTP connections.
  • The JSONRequest object, proposed by Douglas Crockford, would be an alternative to the XHR object.[33]
  • Use of plugins, such as Java applets or the proprietary Adobe Flash (using RTMP protocol for data streaming to Flash applications). These have the advantage of working identically across all browsers with the appropriate plugin installed and need not rely on HTTP connections, but the disadvantage of requiring the plugin to be installed
  • Google announced[34] a new Channel API for Google App Engine,[35] implementing a Comet-like API with the help of a client JavaScript library on the browser. It could be later replaced by HTML5 WebSocket, however.

See also[edit]

References[edit]

  1. ^ Krill, Paul (September 24, 2007). "AJAX alliance recognizes mashups". InfoWorld. Retrieved 2010-10-20. 
  2. ^ Crane, Dave; McCarthy, Phil (October 13, 2008). Comet and Reverse Ajax: The Next-Generation Ajax 2.0. Apress. ISBN 978-1-59059-998-3. 
  3. ^ a b Gravelle, Rob. "Comet Programming: Using Ajax to Simulate Server Push". Webreference.com. Retrieved 2010-10-20. 
  4. ^ Egloff, Andreas (2007-05-05). Ajax Push (a.k.a. Comet) with Java Business Integration (JBI) (Speech). JavaOne 2007, San Francisco, California: Sun Microsystems, Inc. Retrieved 2008-06-10. 
  5. ^ a b "Ajax Push". ICEfaces.org. Retrieved 2008-07-21. 
  6. ^ Crane, Dave; McCarthy, Phil (July 2008). Comet and Reverse Ajax: The Next Generation Ajax 2.0. Apress. ISBN 1-59059-998-5. 
  7. ^ a b Mahemoff, Michael (June 2006). "Web Remoting". Ajax Design Patterns. O'Reilly Media. pp. 19; 85. ISBN 0-596-10180-5. 
  8. ^ Double, Chris (2005-11-05). "More on Ajax and server push". Different ways of doing server push. Retrieved 2008-05-05. 
  9. ^ Nesbitt, Bryce (2005-11-01). "The Slow Load Technique/Reverse AJAX". Simulating Server Push in a Standard Web Browser. Retrieved 2008-05-06. 
  10. ^ Netscape.com from 1996 (via Archive.org)
  11. ^ [1][dead link]
  12. ^ Elko II: Against Statelessness (or, Everything Old Is New Again). Habitat Chronicles (2009-09-06). Retrieved on 2014-04-12.
  13. ^ Elko I: The Life, Death, Life, Death, Life, Death, and Resurrection of The Elko Session Server. Habitat Chronicles (2009-09-05). Retrieved on 2014-04-12.
  14. ^ Alex Russell (3 March 2006). “Comet: Low Latency Data for the Browser”. Alex Russell’s blog. Retrieved 29 November 2007.
  15. ^ K. Taft, Darryl (2006-05-12). "Microsoft Scrubs Comet from AJAX Tool Set". eWEEK.com. Retrieved 2008-07-21. 
  16. ^ Orbited: Enabling Comet for the Masses: OSCON 2008 - O'Reilly Conferences, July 21 - 25, 2008, Portland, Oregon
  17. ^ Enterprise Comet & Web 2.0 Live Presentation
  18. ^ "CometDaily: Comet and Push Technology". 
  19. ^ Just van den Broecke (3 January 2007). “Pushlets: Send events from servlets to DHTML client browsers”. JavaWorld. Retrieved 14 December 2007.
  20. ^ Borland, John (2001-04-01). "Will the "refresh" button become obsolete?". CNET Networks. Retrieved 2008-07-22. 
  21. ^ Dion Almaer (29 September 2005). “Jotspot Live: Live, group note-taking” (interview with Abe Fettig). Ajaxian. Retrieved 15 December 2007.
    Matt Marshall (15 December 2006). “Renkoo launches event service — in time to schedule holiday cocktails”. Venture Beat. Retrieved 15 December 2007.
  22. ^ Clint Boulton (27 December 2005). “Startups Board the AJAX Bandwagon”. DevX News. Retrieved 18 February 2008.
  23. ^ HTTP 1.1 specification, section 8.1.4. W3C. Retrieved 30 November 2007
  24. ^ a b Holdener III, Anthony T. (January 2008). "Page Layout with Frames that Aren't". Ajax: The Definitive Guide. O'Reilly Media. p. 320. ISBN 0-596-52838-8. 
  25. ^ Johnny Stenback, et al. (March–April 2004). “Bug 237319 – Add support for server push using multipart/x-mixed-replace with XMLHttpRequest”. Mozilla bug tracking. Retrieved 29 November 2007. Also see:
    Alex Russell (6 August 2005). “Toward server-sent data w/o iframes”. Alex Russell’s blog. Retrieved 29 November 2007.
  26. ^ Rob Butler, et al. (June 2006). “Bug 14392: Add support for multipart/x-mixed-replace to XMLHttpRequest”. Webkit bug tracking. Retrieved 29 November 2007.
  27. ^ XMLHttpRequest enhancements (Windows). Msdn.microsoft.com (2012-07-19). Retrieved on 2014-04-12.
  28. ^ a b Flanagan, David (2006-08-17). "13.8.4 Cross-Site Scripting". JavaScript the Definitive Guide. The Definitive Guide. O'Reilly Media. p. 994. ISBN 0-596-10199-6. 
  29. ^ Ian Hickson, ed. (2007-10-27). "6.2 Server-sent DOM events". HTML 5 - Call For Comments. WHATWG. Retrieved 2008-10-07. 
  30. ^ Bersvendsen, Arve (2006-09-01). "Event Streaming to Web Browsers". Opera Software. Retrieved 2009-06-01. 
  31. ^ Hickson, Ian (2009-04-23). "The WebSocket API". w3c. Retrieved 2009-07-21. 
  32. ^ Alex Russell, et al. (2007). "Bayeux Protocol - Bayeux 1.0draft1.". Dojo Foundation. Retrieved 2007-12-14. 
  33. ^ Crockford, Douglas (2006-04-17). "JSONRequest Duplex". An alternative to XMLHttpRequest for long lasting server initiated push of data. Retrieved 2008-05-05. 
  34. ^ App, The. (2010-12-02) Google App Engine Blog: Happy Holidays from the App Engine team - 1.4.0 SDK released. Googleappengine.blogspot.com. Retrieved on 2014-04-12.
  35. ^ Paul, Ryan. (2010-12-06) App Engine gets Streaming API and longer background tasks. Ars Technica. Retrieved on 2014-04-12.

External links[edit]