Jump to content

Talk:Comet (programming)/Sandbox

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Talk:Comet (programming)
This is an old revision of this page, as edited by Restepc (talk | contribs) at 01:52, 20 June 2008 (→Scalability: major trim...I must get a hair cut). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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 any need for the client to explicitly request it. It allows creation of event-driven web applications, enabling real-time interaction which would otherwise require much more work. Though the term Comet was coined in 2006,[a] 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 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 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, but throughput is improved and latency and server load are decreased.

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.


Browser compatibility

Because until recently, browsers were not designed with Comet in mind, web application developers mostly use several unintended side-effects of browser-native objects to build Comet “transports” (methods of sending Comet events), 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.[1][2]

The specific transport or transports best for any given use depends on which browsers are targeted, the desired performance of the solution, need for cross-domain use, tolerance for user interface side-effects, and the stringency of proxy servers and firewalls between the client and server.

“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.[1]

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,[3] 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.[2]

Htmlfile ActiveX object

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.[4][1] 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.[5] 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.[6] Additionally, it is unfortunately currently impossible to determine when the multipart XHR connection has been closed.[7]

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).[1][2] 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.[3]

XHR long polling

Because 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—many Comet applications instead opt for long polling, which is easy to implement on the browser side, and works in every browser which supports XHR.

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 connection open to 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.[8] 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”.[9]

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, and closes the connection. Each time the script connection is closed, 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.[1][10]

Server-sent events

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 much more straight-forward to implement, both on the server side, and in the browser-side JavaScript.[11][12]

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).[e]

General considerations

The HTTP 1.1 specification states that “A single-user client should not maintain more than 2 connections with any server or proxy”,[13] and this recommendation is followed by most browsers, including Internet Explorer and Firefox. Holding one connection open for Comet can therefore 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.

Alternatives

Instead of using browser-native technologies to provide persistent connections, some developers instead turn to plugins, such as Java applets or the proprietary Adobe Flash.[f] These have the advantage of working identically across all browsers with the appropriate plugin installed, need not use HTTP connections, and face none of the security restrictions placed on browser-native transports. These strengths, however, are also the main drawbacks of proprietary plugins: 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 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).

  • 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.
  • 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.

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]

In clustered server environments (see Horizontal scalability above), messages must be routed to whichever Comet server a given browser is connected to, and for some applications, message delivery is critical even in the event of a server crash. In enterprise Java systems, this is typically handled by Message Oriented Middleware, often encapsulated by JavaSpaces.[citation needed]

History

Sending real-time messages is not a new idea, even in the web context.

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).[14] Microsoft Internet Explorer copied this feature. The main use of server push was in webcams; each frame was pushed to browsers as a part of the multipart message.

While it was real-time, Netscape’s server push cannot really be defined as Comet, as it relied on complete replacement of pages. This also limited its adoption for general applications.

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).[14][15] 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.[16]

Early Comet applications

Circa 2000, developers began creating the first pure-JavaScript Comet applications, using the Frame/IFrame transport. Pushlets, a framework created by the Dutch Just van den Broecke, was the first open source Comet implementation, based on server-side Java servlets, and a client-side JavaScript library.[15] The 2000 startup KnowNow built several Comet 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 Comet server prototype as mod_pubsub, KnowNow turned, like other Comet implementations of the time, to enterprise applications.[17][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]

While these early implementations made a splash in the Silicon Valley popular imagination, Comet’s impact didn’t at the time live up to the headlines. Comet instead found a niche in financial trading and similar enterprise markets, and for the next several years, remained in that niche, unable to expand to large-scale consumer-oriented applications.

Popularization

In 2005 and 2006, several prominent 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.[4][18] Meanwhile, Comet continued to make inroads into enterprise markets.[h]

In March 2006, Alex Russell invented the name Comet, bringing attention to the approach, and providing an umbrella term for any techniques supporting the Comet user-interaction model. The term quickly gained currency, and Comet became a prominent lecture topic at web-related technology conferences. In late 2007, the website Comet Daily assembled a group of Comet server implementors to write articles about Comet techniques and usage.[20]

Standardization attempts

Attempts to standardize Comet have come from two 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.[11][12]
  • The Bayeux protocol, defined by the Dojo foundation, 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]


Notes

  1. ^ The term Comet was coined by Alex Russell in a March 2006 blog post, as a play on Ajax (Ajax and Comet are both common household cleansers).[19] Though the concept is much older, and has been known by various names, the Comet moniker has come to dominate recent discussion.
  2. ^ Because web browsers are by far the most common applications used to access the web, and because traditionally non-browser user agents have had little support for Comet, the term browser will be used throughout this article instead of the more generic terms client application or user agent. Browser in this context should be understood to imply web user agents in general.
  3. ^ This is not criticism of Wikipedia.
  4. ^ 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.”[22]
  5. ^ 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.[12]
  6. ^ As part of their effort to make Flash and Flex a complete alternative to open-standards–based web technologies, Adobe has open-sourced the Java BlazeDS server plugin, which streams events to Flash applications.
  7. ^ This is for example the approach taken by Comet servers implementing the Bayeux protocol.[21] See the Standarization attempts section.
  8. ^ New enterprise Comet companies and solutions were created, for instance the Java-based ICEfaces JSF framework, and others which had previously used Java-applet based transports, for instance Caplin Systems, switched instead to pure-JavaScript implementations.[23][16]

References

  1. ^ a b c d e f Jacob Rus (11 December 2007). “The Future of Comet: Part 1, Comet Today”. Comet Daily. Retrieved 14 Dec 2007.
  2. ^ a b c Andrew Betts (2007). “Browser Techniques”. Meteor website. Retrieved 29 Nov 2007.
  3. ^ a b Maciej Stachowiak (26 June 2007). “Re: XMLHttpRequest and readyState==3”. Webkit-dev mailing list. Retrieved 29 Nov 2007.
  4. ^ 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 Nov 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 Nov 2007.
    Michael Carter (18 November 2007). “IE ActiveX("htmlfile") Transport, Part II”. Comet Daily. Retrieved 29 Nov 2007.
  5. ^ 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 Nov 2007.
  6. ^ Rob Butler, et al. (June 2006). “Bug 14392: Add support for multipart/x-mixed-replace to XMLHttpRequest”. Webkit Bugzilla bug tracker. Retrieved 29 Nov 2007.
  7. ^ Alex Russell (21 December 2006). “Adventures In Comet and Multipart Mime”. Continuing Intermittent Incoherency. Retrieved 29 Nov 2007.
  8. ^ Andrew Betts (4 December 2007). “Cross Site Scripting Joy”. Comet Daily. Retrieved 14 Dec 2007.
  9. ^ Bob Ippolito (5 December 2005). “Remote JSON – JSONP”. from __future__ import *. Retrieved 30 Nov 2007.
  10. ^ Alex Russell (22 July 2006). “Cross Domain Comet”. Continuing Intermittent Incoherency. Retrieved 30 Nov 2007.
  11. ^ a b Ian Hickson, et al. (2005–2008). HTML 5 specification, § 6.2: Server-sent DOM events. WHATWG. Retrieved 14 Dec 2007.
  12. ^ a b c Jacob Rus (10 January 2008). “The Future of Comet: Part 2, HTML 5’s Server-Sent Events”. Comet Daily. Retrieved 1 Apr 2008.
  13. ^ HTTP 1.1 specification, section 8.14. W3C. Retrieved 30 Nov 2007.
  14. ^ a b Alessandro Alinone (19 October 2007). “Comet and Push Technology”. Comet Daily. Retrieved 14 Dec 2007.
  15. ^ a b c Just van den Broecke (3 January 2007). “Pushlets: Send events from servlets to DHTML client browsers”. JavaWorld. Retrieved 14 Dec 2007.
  16. ^ a b Martin Tyler (30 November 2007). “The Evolution of Comet at Caplin”. Comet Daily. Retrieved 19 Feb 2008.
  17. ^ Rohit Khare (August 2005). “Beyond AJAX: Accelerating Web Applications with Real-Time Event Notification”. KnowNow white paper (link from the Wayback Machine). Retrieved 14 Dec 2007.
  18. ^ Dion Almaer (29 September 2005). “Jotspot Live: Live, group note-taking” (interview with Abe Fettig). Ajaxian. Retrieved 15 Dec 2007.
    Matt Marshall (15 December 2006). “Renkoo launches event service — in time to schedule holiday cocktails”. Venture Beat. Retrieved 15 Dec 2007.
  19. ^ a b Cite error: The named reference alex_comet was invoked but never defined (see the help page).
  20. ^ Dylan Schiemann (18 October 2007). “Why Comet Daily?”. Comet Daily . Retrieved 8 Jan 2008.
  21. ^ a b Alex Russell, et al. (2007). Bayeux Protocol specification, 1.0 draft 1. Dojo Foundation. Retrieved 14 Dec 2007.
  22. ^ Jesse James Garrett (18 February 2005). “Ajax: A New Approach to Web Applications”. Adaptive Path. Retrieved 29 Nov 2007.
  23. ^ Clint Boulton (27 December 2005). “Startups Board the AJAX Bandwagon”. DevX News. Retrieved 18 Feb 2008.

es:Comet hu:Comet mk:Comet ja:Comet pt:Comet (programação)

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