Content deleted Content added
Bluelink 1 book for verifiability (prndis)) #IABot (v2.0) (GreenC bot |
m →Alternatives: HTTP to HTTPS for Blogspot |
||
| (27 intermediate revisions by 20 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
Line 34 ⟶ 35:
|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 44 ⟶ 45:
|last = Double
|date = 2005-11-05
|
}}
</ref>
Line 54 ⟶ 55:
|last = Nesbitt
|date = 2005-11-01
|
|url-status = dead
|
|
}}
</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 65 ⟶ 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
==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 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 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 105 ⟶ 108:
|date=2001-04-01
|publisher=[[CNET Networks]]
|
}}</ref>
Line 117 ⟶ 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 123 ⟶ 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 139 ⟶ 142:
| publisher = [[O'Reilly Media]]
|date=January 2008
| isbn = 978-0-596-52838-
| chapter = Page Layout with Frames that Aren't
| page = 320
Line 151 ⟶ 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 164 ⟶ 167:
|url=https://archive.org/details/javascript00libg_297
|url-access=registration
|date=2006-08-17
|publisher=[[O'Reilly Media]]
Line 179 ⟶ 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 188 ⟶ 190:
|publisher=[[W3C]]
|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 200 ⟶ 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 213 ⟶ 218:
==External links==
*
{{DEFAULTSORT:Comet (Programming)}}
| |||