Comet (programming): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Enough. Stop trying to hide the existence of competitive terms.
wikilink reverse ajax
Line 23: Line 23:
| accessdate = 2008-06-10
| accessdate = 2008-06-10
}}</ref>
}}</ref>
''Reverse Ajax'',<ref>{{cite book
''[[Reverse Ajax]]'',<ref>{{cite book
|title = Comet and Reverse Ajax: The Next Generation Ajax 2.0
|title = Comet and Reverse Ajax: The Next Generation Ajax 2.0
|first = Dave
|first = Dave

Revision as of 16:24, 2 July 2008

Template:Otheruses2 In web development, Comet is a neologism to describe application architecture in which a long-held HTTP request allows a web server to push data to a client asynchronously and with no need for the client to explicitly request it. Comet is an umbrella term that encompasses numerous specific techniques for achieving this user-interaction model. These methods rely on browser-native technologies, such as JavaScript, rather than on proprietary plugins, but have few other unifying features. Each method has its own trade-offs in terms of browser support and side effects, latency, and throughput.

The Comet approach differs from the original 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 a browser requests chunks of data in order to update the current page. The effect is similar to that of applications which use traditional Ajax with polling to detect new information on the server, but Comet improves throughput and reduces latency and server load. Consequently, Comet enables the creation of event-driven web applications and real-time interaction to an extent that would otherwise be untenable.

Although the term was coined in 2006, the concept is several years older and has been known by various names, including Ajax Push,[1] Reverse Ajax,[2] and HTTP server push[3] among others.[4]

Traditional web architectures

Web applications have historically been less flexible and capable than desktop applications counterparts, partly because of limitations of creating dynamic user interfaces and constraints in the online environment. One limitation that Comet seeks to address is the inability of a web server to choose when to send updated information to a web browser.

Page-by-page model

Main article: World Wide Web

Traditionally, each chunk of information sent by a web server to a browser must be explicitly requested. Each time the user opens a web page, the browser initiates an HTTP connection to the web server, which returns the HTML code for the page and closes the connection. The browser then makes another HTTP request for each resource used by the page and the server responds to each in turn, e.g. images and stylesheets. For example Wikipedia is a web application built using this page-by-page web model.

Ajax with polling

Main article: Ajax (programming)

To overcome these limitations of the page-by-page model, many web applications turn to Ajax (asynchronous JavaScript and XML). The term Ajax, like Comet, refers to a user interaction model, “a way of thinking about the architecture of web applications”, rather than any specific technique (in the words of Jesse James Garrett, the term’s originator). Concretely, “an Ajax application eliminates the start–stop–start–stop nature of interaction on the Web by introducing an intermediary—an Ajax engine—between the user and the server.”[5] In the Ajax model, servers respond to each request in sequence, just as before, but the browser uses JavaScript to modify the current page rather than opening a new page. This limits the server’s response to only the relevant information (usually in XML or JSON format), dramatically increasing application responsiveness by avoiding redundant data transfer and eliminating whole-page re-rendering. Furthermore, since Ajax requests are handled asynchronously in the background, the user can continue to interact with the page as data is retrieved. An example of this technology is the Google Maps web application. In Google Maps, new tiles of map imagery are loaded as the user clicks and drags the map, and the user can continue to pan and zoom the map even before all tiles in range have loaded.

Ajax does not fully address the limitations of the traditional page-by-page web model, however, because the server still responds to each request by the browser as a single event, closing each connection as a response is served. Any changing information is only updated in response to explicit user actions. This problem becomes a major hurdle when designing applications which should update in real time, in response to some event on the server, such as another user sending it information.

It is possible to regularly poll the server, asking it if a new event has occurred (e.g. each five seconds asking the server “Any new events?”). This introduces an unhappy trade-off between latency and server load; the average event latency is half the poll interval (plus network latency and any time spent processing data), so increasing responsiveness proportionally increases the number of requests received by the server. At high polling frequencies, this wastes server resources and bandwidth processing many negative responses (“No new events, try again later”). Although applications with predictable information updates, or those which tolerate relatively infrequent updates, can use polling without excessive waste, the technology is nonetheless too unwieldy for most implementations.

Web server push

In 1995, Netscape Navigator introduced “server push” technology, allowing web applications to update images or HTML pages at will, by sending new versions of a resource as separate parts of a multipart HTTP response (at the same time, Netscape also introduced “client pull”, a way for Navigator to re-request a page after a specific amount of time, analogous to the ajax with polling model described above).[6] Other web browsers implemented this feature, such as Mozilla Firefox.

Implementation of Comet

Comet is an umbrella term for technologies that attempt to eliminate both the limitations of the page-by-page model and traditional polling. Instead, Comet applications can accomplish something approaching real-time interaction by relying on a persistent HTTP connection to provide the browser with updates as designated by the server. Holding one connection open for Comet can negatively affect the performance of the client and also presents scalability issues for the web server (see #Scalability). The HTTP 1.1 specification states that “A single-user client should not maintain more than 2 connections with any server or proxy”,[7] these guidelines are intended to improve response times and avoid congestion. However, holding one connection open for server sent events can impact performance; the browser may be unable to send a new user-initiated Ajax request while the browser loads, for example a series of images. This can be worked around by creating a distinct hostname (usually at a different subdomain) for Comet connections—these two subdomains might be hosted on the same physical server.

Browsers and proxies are not designed with server events in mind (see #Reliability). Web application developers mostly use several unintended side-effects of browser-native objects to implement Comet-like behavior, 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 JavaScript.[8][9] Comet, though, avoids many of these risks [which?], the drawback being that a given Comet transport is often an ad hoc approach that works for a limited class of compatible browsers.

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

Streaming

In an application using streaming Comet, the browser opens a single persistent connection to the server for all Comet events, which is handled incrementally on the browser side. Each time the server sends a new event, the browser interprets it, but neither side closes the connection. Specific technologies for accomplishing streaming Comet include the following.

“Forever frame” IFrame

The earliest Comet transport (in use as early as 2000, see History section below) uses an invisible IFrame HTML element (an inline frame, which allows a website to embed one HTML document inside another). This invisible IFrame is declared by the server to be infinitely long—hence “forever frame”—and as events occur, 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.[8]

The main benefit of the IFrame method is that it works in every common browser. Two downsides of this transport are first that it requires a kilobyte of data to be sent down the connection before the Safari browser (running on Mac OS X 10.4; this is fixed in the latest version of OS X) will begin incrementally rendering the IFrame or 256 bytes in Internet Explorer,[10] and second 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.[9]

By placing the incrementally-rendered IFrame inside an ActiveX object, it is possible to remove the negative side-effects of the IFrame transport in Internet Explorer.[11][8] The technique only works in Internet Explorer, however.

Multipart XHR

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.[12] 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 only included in Gecko-based browsers, though there is discussion of adding it to Webkit.[13] Additionally, it is currently impossible to determine when the multipart XHR connection has been closed.[14]

XHR streaming

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, with ready state 3 (this is the behavior of both Gecko- and Webkit-based browsers).[8][9] Note that for Webkit-based browsers, this requires at least 256 bytes of data at the beginning of the event stream, before Webkit will begin to incrementally render it.[10]

Ajax with long polling

None of the above streaming transports works across all modern browsers without causing negative side-effects in any—forcing Comet developers to implement several complex streaming transports, switching between them depending on the browser. Consequently many Comet applications instead opt for 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 new long polling request in order to obtain subsequent events.

Unlike with polling, long polling sends an event payload along with most poll responses. While in the worst case—frequently occurring events with small payloads—long polling incurs significant computational overhead[citation needed], Greg Wilkins found that in all cases, long polling either equals or outperforms polling.[15] Streaming has better performance still, as it eliminates much of the per-message overhead[citation needed].

Specific technologies for accomplishing long-polling include the following.

XHR long polling

For the most part, XHR long polling works like any standard use of XHR. The browser makes an asynchronous request of the server, and provides a function to be called when the server has responded. At the end of this callback function, 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.

Dynamic script tag long polling

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.[16] That is, if the main web page is served from one SLD, and the Comet server is located at another SLD, Comet events cannot be used to modify the HTML and DOM of the main page, using those transports. This can be worked around 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 XHR 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, and though the risk to the data provider (in our case, the Comet server) can be avoided using “JSONP”. As Bob Ippolito explains, “Your page is still toast if the remote host decides to inject malicious code instead of JSON data”.[17]

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 is the only cross-browser choice for developers looking to implement cross-domain Comet.[8][18]

Server-sent events

Template:Future All of the previously listed transports are ad hoc uses of browser features not originally intended for Comet. Since 2005, another alternative, produced by the Web Hypertext Application Technology Working Group (WHATWG), has existed as part of the draft HTML 5 specification. Called server-sent events, it attempts to avoid the disadvantages of other Comet transports, while making Comet applications more straight-forward to implement, both on the server side, and in the browser-side JavaScript.[19][20]

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. JavaScript 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, which could be used to make purely declarative Comet applications (that is, not requiring any imperative JavaScript at all). This is a controversial proposal; some developers feel that the additional complexity is unnecessary, because such applications are never likely to be purely declarative, and it is not difficult to just use JavaScript.

Publish/subscribe architecture

Many Comet applications can be organized in terms of a publish/subscribe (pub/sub) architecture. [which?] In pub/sub, message senders do not send messages directly to message receivers. Instead, published messages are classified into “channels”, to which interested users subscribe. Publishers are separated from subscribers by a pub/sub layer, which takes care of the details of sending messages published to each channel to its subscribers. Comet servers implementing the Bayeux protocol are explicitly organized around publish/subscribe, building it in to the Comet server directly.[21]

Scalability

Because Comet applications send events in real time, they typically use more resources than other types of web applications, making them more difficult to scale (grow to support large numbers of users). [citation needed]

This analysis shows that for the worst case, when the message rate is high, load and latency for Comet long-polling are identical to traditional polling, and for most cases the load and latency are significantly better than traditional polling.

— Greg Wilkins[15]
  • Comet relies on continually keeping at least one server–client connection open for each client. Traditional web servers, designed for the page-by-page application architecture, cannot cope with such large numbers of open connections. This is a vertical scalability problem: it is difficult to handle many users on each server. [citation needed]
  • Additionally, because Comet applications are often interactive, allowing arbitrary groups of users to communicate with each-other, splitting tasks among servers is more difficult than for applications in which each user acts independently. This is a horizontal scalability problem: it is difficult to add more servers to the application. [citation needed]

Reliability

Proxy servers and firewalls between the browser and web server can pose network problems. Firewalls are often configured to drop connections that have been open for too long (as a security heuristic), so many Comet frameworks tear down and recreate the Comet connection periodically. Naive intervening HTTP proxies may buffer pushed messages in chunks up to 32 or 64 kilobytes, necessitating a system for adaptive detection of intervening proxy buffer sizes.[citation needed]

History

Early Java applets

The ability to embed Java applets into browsers opened richer real-time options. An applet can open a raw TCP socket to the server from which it has loaded. This socket can remain open as long as the browser keeps open the document which hosts the applet. Event notifications can be sent in any format—text or binary—and decoded by Java code in the applet.

Despite their capabilities, however, Java applets never really took off. User interfaces in Java applets were often buggy and frustrating for users, suffering graphical glitches. Communications on ports other than port 80 are blocked by aggressive firewalls. Not all users had the proper version of the Java plugin installed in their browsers, or even any version at all. When possible, web application developers preferred to use browser-native technologies (see Disadvantages of Java applets). To mitigate these disadvantages, some developers—for instance, Caplin Systems in 1998—used Java applets merely as a transport mechanism, leaving application-specific interface logic to browser-native JavaScript.[22]

Early push applications

Circa 2000, developers began creating the first push applications using client-side JavaScript inside a Frame/IFrame. Pushlets, a framework created by the Dutch Just van den Broecke, was one of the first open source implementations, based on server-side Java servlets, and a client-side JavaScript library.[23] The 2000 startup KnowNow built several push demonstrations, and planned to create a platform on top of the Web, which would be used by other developers to implement real-time web apps. After releasing their mod_pubsub server prototype, KnowNow turned to enterprise applications.[24][citation needed] Bang Networks—a 1999 Silicon Valley start-up backed by Netscape co-founder Marc Andreessen and lavishly financed—attempted to create a real-time push standard for the whole Web, but ran out of cash and folded at the end of 2003.[citation needed] Lightstreamer, an Italian company, focused on the financial market with their Java-based server.[citation needed]

First Comet applications

In March 2006, software engineer Alex Russell coined the term Comet in a post on his personal blog. The new term was a play on Ajax (Ajax and Comet both being common household cleansers).[25] This umbrella term for previously existing concepts gained currency as a moniker, and Comet quickly became a prominent lecture topic at web-related technology conferences.[citation needed]

In 2006, some applications exposed Comet to a wider audience: Meebo’s multi-protocol web-based chat application enables 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; Comet-based chat is the centerpiece of the event-planning site Renkoo.[11][26] Meanwhile, Comet continued to make inroads into enterprise markets. For instance, new enterprise Comet companies and solutions were created such as the Java-based ICEfaces JSF framework. Others that had previously used Java-applet based transports, such as Caplin Systems, switched instead to pure-JavaScript implementations.[27][22]

Alternatives

It is important to note that browser-native technologies is inherent in the term Comet. Attempts to standardize non-polling HTTP communication have come from other sides:

  • The WHATWG’s HTML 5 specification attempts to standardize the Comet transport (see Server-sent events, above). If HTML 5 is implemented in many browsers, Comet developers will be able to avoid the current need to implement several transports.[19][20]
  • 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.[21]
  • The BOSH protocol by the XMPP standards foundation. It emulates a bidirectional stream between browser and server by using multiple synchronous HTTP connections.
  • The JSONRequest object, proposed by Douglas Crockford, would be an alternative to the XHR object, with support for Comet.[28]
  • Use of plugins, such as Java applets or the proprietary Adobe Flash (Java BlazeDS is a server plugin which streams events to Flash applications). These have the advantage of working identically across all browsers with the appropriate plugin installed, need not rely on HTTP connections, and face none of the security restrictions placed on browser-native transports[clarification needed].

See also

References

  1. ^ 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.{{cite speech}}: CS1 maint: location (link)
  2. ^ Crane, Dave (2008). Comet and Reverse Ajax: The Next Generation Ajax 2.0. Apress. ISBN 1590599985. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help); Unknown parameter |month= ignored (help)
  3. ^ Double, Chris (2005-11-05). "More on Ajax and server push". Different ways of doing server push. Retrieved 2008-05-05.
  4. ^ Nesbitt, Bryce (2005-11-01). "The Slow Load Technique/Reverse AJAX". Simulating Server Push in a Standard Web Browser. Retrieved 2008-05-05.
  5. ^ Jesse James Garrett (18 February 2005). “Ajax: A New Approach to Web Applications”. Adaptive Path. Retrieved 29 November 2007.
  6. ^ Alessandro Alinone (19 October 2007). “Comet and Push Technology”. Comet Daily. Retrieved 14 December 2007.
  7. ^ HTTP 1.1 specification, section 8.14. W3C. Retrieved 30 November 2007
  8. ^ a b c d e Jacob Rus (11 December 2007). “The Future of Comet: Part 1, Comet Today”. Comet Daily. Retrieved 14 December 2007.
  9. ^ a b c Andrew Betts (2007). “Browser Techniques”. Meteor website. Retrieved 29 November 2007.
  10. ^ a b Maciej Stachowiak (26 June 2007). “Re: XMLHttpRequest and readyState==3”. Webkit-dev mailing list. Retrieved 29 November 2007.
  11. ^ a b Alex Russell (12 February 2006). “What else is buried down in the depths of Google’s amazing JavaScript?”. Continuing Intermittent Incoherency. Retrieved 29 November 2007.
    For advice about avoiding garbage collection bugs when implementing Comet with htmlfiles, see:
    Michael Carter (25 October 2007). “HTTP Streaming and Internet Explorer”. Comet Daily. Retrieved 29 November 2007.
    Michael Carter (18 November 2007). “IE ActiveX("htmlfile") Transport, Part II”. Comet Daily. Retrieved 29 Nov 2007.
  12. ^ Johnny Stenback, et al. (March–April 2004). “Bug 237319 – Add support for server push using multipart/x-mixed-replace with XMLHttpRequest”. Mozilla Bugzilla bug tracker. Retrieved 29 November 2007. Also see:
    Alex Russell (6 August 2005). “Toward server-sent data w/o iframes”. Continuing Intermittent Incoherency. Retrieved 29 November 2007.
  13. ^ Rob Butler, et al. (June 2006). “Bug 14392: Add support for multipart/x-mixed-replace to XMLHttpRequest”. Webkit Bugzilla bug tracker. Retrieved 29 November 2007.
  14. ^ Alex Russell (21 December 2006). “Adventures In Comet and Multipart Mime”. Continuing Intermittent Incoherency. Retrieved 29 November 2007.
  15. ^ a b Greg Wilkins (6 November 2007). “Comet is Always Better Than Polling”. Comet Daily. Retrieved 29 November 2007.
  16. ^ Andrew Betts (4 December 2007). “Cross Site Scripting Joy”. Comet Daily. Retrieved 14 December 2007.
  17. ^ Bob Ippolito (5 December 2005). “Remote JSON – JSONP”. from __future__ import *. Retrieved 30 November 2007.
  18. ^ Alex Russell (22 July 2006). “Cross Domain Comet”. Continuing Intermittent Incoherency. Retrieved 30 November 2007.
  19. ^ a b Ian Hickson, et al. (2005–2008). HTML 5 specification, § 6.2: Server-sent DOM events. WHATWG. Retrieved 14 December 2007.
  20. ^ a b Jacob Rus (10 January 2008). “The Future of Comet: Part 2, HTML 5’s Server-Sent Events”. Comet Daily. Retrieved 1 April 2008.
  21. ^ a b Alex Russell, et al. (2007). Bayeux Protocol specification, 1.0 draft 1. Dojo Foundation. Retrieved 14 December 2007.
  22. ^ a b Martin Tyler (30 November 2007). “The Evolution of Comet at Caplin”. Comet Daily. Retrieved 19 February 2008.
  23. ^ Just van den Broecke (3 January 2007). “Pushlets: Send events from servlets to DHTML client browsers”. JavaWorld. Retrieved 14 December 2007.
  24. ^ Rohit Khare (August 2005). “Beyond AJAX: Accelerating Web Applications with Real-Time Event Notification”. KnowNow white paper (link from the Wayback Machine). Retrieved 14 December 2007.
  25. ^ Alex Russell (3 March 2006). “Comet: Low Latency Data for the Browser”. Continuing Intermittent Incoherency. Retrieved 29 November 2007.
  26. ^ 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.
  27. ^ Clint Boulton (27 December 2005). “Startups Board the AJAX Bandwagon”. DevX News. Retrieved 18 February 2008.
  28. ^ Crockford, Douglas (2006-04-17). "JSONRequest Duplex". An alternative to XMLHttpRequest for long lasting server initiated push of data. Retrieved 2008-05-05.

External links

Retrieved from "https://en.wikipedia.org/w/index.php?title=Comet_(programming)&oldid=223105609"