Content deleted Content added
m →Alternatives: HTTP to HTTPS for Blogspot |
|||
| (38 intermediate revisions by 26 users not shown) | |||
Line 1:
{{short description|Web application model}}
'''Comet''' is a [[web application]] model in which a long-held [[HTTPS]] request allows a [[web server]] to [[Push technology|push]] data to a [[web browser|browser]], without the browser explicitly requesting it.<ref name=
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
Line 10 ⟶ 11:
| ___location = [[JavaOne]] 2007, [[San Francisco, California]]
| url = http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-8434&yr=2007&track=7
|
}}</ref><ref name="ice">{{cite web
|url=http://www.icesoft.org/java/projects/ICEfaces/ajax-push.jsf
|title=Ajax Push
|publisher=ICEfaces.org
|
}}</ref>
''Reverse Ajax'',<ref>{{cite book
Line 23 ⟶ 24:
|author2=McCarthy, Phil
|publisher = Apress
|isbn = 978-1-59059-998-
|date=July 2008
}}</ref> ''Two-way-web'',<ref name="ajax-dp-oreilly"/> ''HTTP Streaming'',<ref name="ajax-dp-oreilly">{{cite book
|title=Ajax Design Patterns
|first=Michael
|last=
|publisher=[[O'Reilly Media]]
|date=June 2006
|isbn=0-596-10180-5
|pages=[https://archive.org/details/ajaxdesignpatter00mahe/page/19 19; 85]
|chapter=Web Remoting
|chapter-url-access=registration
|chapter-url=https://archive.org/details/ajaxdesignpatter00mahe/page/19
}}</ref> and
''[[HTTP push|HTTP server push]]''<ref>{{cite web
Line 42 ⟶ 45:
|last = Double
|date = 2005-11-05
|
}}
</ref>
Line 52 ⟶ 55:
|last = Nesbitt
|date = 2005-11-01
|
|
|
|
}}
</ref> The term ''Comet'' is not an acronym, but was coined by Alex Russell in his 2006 [[blog]] post
|url = http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/
|title = Comet: Low Latency Data for the Browser
Line 64 ⟶ 66:
|last = Russell
|date = 2006-03-04
|
}}</ref>{{citation needed|date=June 2023}}
In recent years{{When|date=January 2025}}, the standardisation and widespread support of [[WebSocket]] and [[Server-sent events]] has rendered the Comet model obsolete.
==History==
===Early Java applets===
The ability to embed [[Java applet]]s into browsers (starting with [[Netscape Navigator 2]].0 in March 1996<ref>{{cite web |url=http://www27.netscape.com/comprod/products/navigator/version_2.0/index.html |title=Netscape.com |
===The first browser-to-browser communication framework===
Line 83 ⟶ 86:
| publisher = Northeast Parallel Architecture Center, College of Engineering and Computer Science
| access-date = 27 February 2016
}}</ref>{{failed verification|date=December 2017}} implemented in 1996–98 at the Northeast Parallel Architectures Center ([http://surface.syr.edu/npac/ NPAC]) at [[Syracuse University]] using [[DARPA]] funding. TANGO architecture has been patented by Syracuse University.<ref>{{Citation|
| url = https://www.dsc.soic.indiana.edu/sites/default/files/tr_9921.pdf
| title = Experiences with Using TANGO Interactive in a Distributed Workshop
Line 92 ⟶ 95:
| publisher = CEWES MSRC/PET TR/99-21
| access-date = 27 February 2016
| archive-date = 8 March 2021
}}</ref> The framework has been commercialized by [http://www.collabworx.com CollabWorx] and used in a dozen or so Command&Control and Training applications in the United States Department of Defense{{fact|date=December 2017}}.▼
| archive-url = https://web.archive.org/web/20210308093626/https://www.dsc.soic.indiana.edu/sites/default/files/tr_9921.pdf
| url-status = dead
▲}}</ref> The framework has been commercialized by [http://www.collabworx.com CollabWorx] and used in a dozen or so Command&Control and Training applications in the United States Department of Defense{{
===First Comet applications===
The first set of Comet implementations
|url=http://news.cnet.com/2100-1023-255088.html
|title=Will the "refresh" button become obsolete?
Line 102 ⟶ 108:
|date=2001-04-01
|publisher=[[CNET Networks]]
|
}}</ref>
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.
In March 2006, [[software engineer]] Alex Russell coined the term Comet in a post on his personal blog.<ref name="alex_comet">Alex Russell (3 March 2006). “[http://alex.dojotoolkit.org/?p=545 Comet: Low Latency Data for the Browser] {{Webarchive|url=https://web.archive.org/web/20080812034003/http://alex.dojotoolkit.org/?p=545 |date=2008-08-12 }}”. Alex Russell’s blog. Retrieved 29 November 2007.</ref> The new term was a play on [[Ajax (programming)|Ajax]] ([[Ajax (cleanser)|Ajax]] and [[Comet (cleanser)|Comet]] both being common household cleaners in the USA).<ref>{{cite web
Line 114 ⟶ 120:
|date=2006-05-12
|publisher=eWEEK.com
|
}}</ref><ref>[http://en.oreilly.com/oscon2008/public/schedule/detail/3048 Orbited: Enabling Comet for the Masses: OSCON 2008 - O'Reilly Conferences, July 21 - 25, 2008, Portland, Oregon<!-- Bot generated title -->]</ref><ref>[http://www.web2journal.com/read/457966.htm Enterprise Comet & Web 2.0 Live Presentation<!-- Bot generated title -->] {{webarchive|url=https://web.archive.org/web/20080520222527/http://www.web2journal.com/read/457966.htm |date=2008-05-20 }}</ref>
Line 120 ⟶ 126:
==Implementations==
Comet applications attempt to eliminate the limitations of the [[World Wide Web#
Specific methods of implementing Comet fall into two major categories: streaming and [[long polling]].
===Streaming===
An application using streaming Comet opens a single [[persistent connection]] from the [[Web browser|client browser]] to the server for all Comet [[Event (computing)|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.<ref name = "WRC">{{cite web | url = http://www.webreference.com/programming/javascript/rg28/ | title = Comet Programming: Using Ajax to Simulate Server Push |
Specific techniques for accomplishing streaming Comet include the following:
====Hidden iframe====
A basic technique for dynamic web application is to use a hidden [[HTML element#Frames|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 transfer encoding|chunked]] block, which implicitly declares it as infinitely long (sometimes called "forever frame"). As events occur, the iframe is gradually filled with <code>script</code> tags, containing JavaScript to be executed in the browser. Because browsers render HTML pages incrementally, each <code>script</code> 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.<ref name="ajaxoreilly">{{cite book
| last = Holdener III
| first = Anthony T.
Line 136 ⟶ 142:
| publisher = [[O'Reilly Media]]
|date=January 2008
| isbn = 978-0-596-52838-
| chapter = Page Layout with Frames that Aren't
| page = 320
Line 148 ⟶ 154:
===Ajax with long polling===
{{original research|date=December 2017}}
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. [https://tools.ietf.org/html/rfc6202 IETF RFC 6202 "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP"] compares long polling and HTTP streaming.
Specific technologies for accomplishing long-polling include the following:
Line 159 ⟶ 165:
|first=David
|title=JavaScript the Definitive Guide
|url=https://archive.org/details/javascript00libg_297
|url-access=registration
|date=2006-08-17
|publisher=[[O'Reilly Media]]
|isbn=0-596-10199-6
|chapter=13.8.4 Cross-Site Scripting
|page=[https://archive.org/details/javascript00libg_297/page/n981 994]
}}</ref> 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.
Line 174 ⟶ 181:
Browser-native technologies are inherent in the term Comet. Attempts to improve non-polling HTTP communication have come from multiple sides:
* The [[HTML 5]]
* The [[HTML 5]] [[WebSocket]] API working
{{cite web
|url=http://www.w3.org/TR/websockets/
Line 181 ⟶ 188:
|last=Hickson
|first=Ian
|publisher=[[
|date=2009-04-23
|
}}
</ref>
* 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.<ref name="bayeux">{{cite web|author=Alex Russell |year=2007 |url=http://svn.cometd.org/trunk/bayeux/bayeux.html|title=Bayeux Protocol - Bayeux 1.0draft1.| publisher= Dojo Foundation|
* The [[BOSH (protocol)|BOSH]] protocol by the XMPP standards foundation. It emulates a bidirectional stream between the browser and server by using two synchronous HTTP connections.
* The JSONRequest object, proposed by [[Douglas Crockford]], would be an alternative to the XHR object.<ref>{{cite web
|url=http://www.json.org/JSONRequest.html
Line 195 ⟶ 202:
|work = An alternative to XMLHttpRequest for long lasting server initiated push of data
|date = 2006-04-17
|
}}</ref>
* Use of plugins, such as [[Java applet]]s or the proprietary [[Adobe Flash]] (using [[Real-Time Messaging Protocol|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<ref>App, The. (2010-12-02) [
==See also==
* [[Push technology]]
* [[Pull technology]]
== Notes ==
{{notelist}}
==References==
Line 208 ⟶ 218:
==External links==
*
{{DEFAULTSORT:Comet (Programming)}}
| |||