Comet (programming)

Last updated

Comet is a web application model in which a long-held HTTPS 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]

Contents

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] The term Comet is not an acronym, but was coined by Alex Russell in his 2006 blog post. [lower-alpha 1] [ citation needed ]

In recent years, 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 applets into browsers (starting with Netscape Navigator 2.0 in March 1996 [10] ) made two-way sustained 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.

The first browser-to-browser communication framework

The very first application using browser-to-browser communications was Tango Interactive, [12] [ failed verification ] implemented in 1996–98 at the Northeast Parallel Architectures Center (NPAC) at Syracuse University using DARPA funding. TANGO architecture has been patented by Syracuse University. [13] TANGO framework has been extensively used as a distance education tool. [14] The framework has been commercialized by CollabWorx and used in a dozen or so Command&Control and Training applications in the United States Department of Defense[ citation needed ].

First Comet applications

The first set of Comet implementations dates back to 2000, [15] [ unreliable source? ] with the Pushlets, Lightstreamer, and KnowNow projects. Pushlets, a framework created by Just van den Broecke, was one of the first [16] open source implementations. Pushlets were based on server-side Java servlets, and a client-side JavaScript library. 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. [17]

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.[ citation needed ] 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.[ citation needed ]

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

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. [22] New Comet variants 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. [23]

Implementations

Comet applications attempt to eliminate the limitations of the page-by-page web model and traditional polling by offering two-way sustained 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 "this specification... encourages clients to be conservative when opening multiple connections". [24] 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

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

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. [25]

One benefit of the iframes 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. [25]

XMLHttpRequest

The XMLHttpRequest (XHR) object, a tool used by Ajax applications for browser–server communication, can also be pressed into service for server–browser Comet messaging by generating a custom data format for an XHR response, and parsing 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

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

XMLHttpRequest long polling

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

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. [26] 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. [26]

Alternatives

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

See also

Notes

  1. Russell, Alex (2006-03-04). "Comet: Low Latency Data for the Browser" . Retrieved 2014-11-02.

Related Research Articles

Jakarta Faces, formerly Jakarta Server Faces and JavaServer Faces (JSF) is a Java specification for building component-based user interfaces for web applications and was formalized as a standard through the Java Community Process being part of the Java Platform, Enterprise Edition. It is also an MVC web framework that simplifies the construction of user interfaces (UI) for server-based applications by using reusable UI components in a page.

<span class="mw-page-title-main">XMLHttpRequest</span> Web API to transfer data between a web browser and a web server

XMLHttpRequest (XHR) is a JavaScript class containing methods to asynchronously transmit HTTP requests from a web browser to a web server. The methods allow a browser-based application to make a fine-grained server call and store the results in XMLHttpRequest's responseText attribute. The XMLHttpRequest class is a component of Ajax programming. Prior to Ajax, an HTML form needed to be completely sent to the server followed by a complete browser page refresh.

Ajax is a set of web development techniques that uses various web technologies on the client-side to create asynchronous web applications. With Ajax, web applications can send and retrieve data from a server asynchronously without interfering with the display and behaviour of the existing page. By decoupling the data interchange layer from the presentation layer, Ajax allows web pages and, by extension, web applications, to change content dynamically without the need to reload the entire page. In practice, modern implementations commonly utilize JSON instead of XML.

<span class="mw-page-title-main">Dynamic web page</span> Type of web page

A server-side dynamic web page is a web page whose construction is controlled by an application server processing server-side scripts. In server-side scripting, parameters determine how the assembly of every new web page proceeds, and including the setting up of more client-side processing.

Push technology or server push is a style of Internet-based communication where the request for a given transaction is initiated by the publisher or central server. It is contrasted with pull, or get, where the request for the transmission of information is initiated by the receiver or client.

A web framework (WF) or web application framework (WAF) is a software framework that is designed to support the development of web applications including web services, web resources, and web APIs. Web frameworks provide a standard way to build and deploy web applications on the World Wide Web. Web frameworks aim to automate the overhead associated with common activities performed in web development. For example, many web frameworks provide libraries for database access, templating frameworks, and session management, and they often promote code reuse. Although they often target development of dynamic web sites, they are also applicable to static websites.

Remote scripting is a technology which allows scripts and programs that are running inside a browser to exchange information with a server. The local scripts can invoke scripts on the remote side and process the returned information.

<span class="mw-page-title-main">Dojo Toolkit</span> Open-source modular JavaScript library

Dojo Toolkit is an open-source modular JavaScript library designed to ease the rapid development of cross-platform, JavaScript/Ajax-based applications and web sites. It was started by Alex Russell, Dylan Schiemann, David Schontzler, and others in 2004 and is dual-licensed under the modified BSD license or the Academic Free License.

qooxdoo Open-source Ajax web application framework

qooxdoo is an open-source Ajax web application framework. It is an LGPL- and/or EPL-licensed client-side and server-agnostic solution, and includes support for professional JavaScript development, a graphical user interface (GUI) toolkit and high-level client-server communication.

Lightstreamer is a web-based asynchronous messaging project, implementing the WebSocket protocol, the Comet model, the push technology paradigm, and the real-time web practices.

Web-based SSH is the provision of Secure Shell (SSH) access through a web browser. SSH is a secure network protocol that is commonly used to remotely control servers, network devices, and other devices. With web-based SSH, users can access and manage these devices using a standard web browser, without the need to install any additional software.

JSONP, or JSON-P, is a historical JavaScript technique for requesting data by loading a <script> element, which is an element intended to load ordinary JavaScript. It was proposed by Bob Ippolito in 2005. JSONP enables sharing of data bypassing same-origin policy, which disallows running JavaScript code to read media DOM elements or XMLHttpRequest data fetched from outside the page's originating site. The originating site is indicated by a combination of URI scheme, hostname, and port number.

A single-page application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of a web browser loading entire new pages. The goal is faster transitions that make the website feel more like a native app.

Wt is an open-source widget-centric web framework for the C++ programming language. It has an API resembling that of Qt framework, also using a widget-tree and an event-driven signal/slot system.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current API specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

Server-Sent Events (SSE) is a server push technology enabling a client to receive automatic updates from a server via an HTTP connection, and describes how servers can initiate data transmission towards clients once an initial client connection has been established. They are commonly used to send message updates or continuous data streams to a browser client and designed to enhance native, cross-browser streaming through a JavaScript API called EventSource, through which a client requests a particular URL in order to receive an event stream. The EventSource API is standardized as part of HTML5 by the WHATWG. The media type for SSE is text/event-stream.

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources on a web page to be accessed from another domain outside the domain from which the first resource was served.

Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website or web application where unauthorized commands are submitted from a user that the web application trusts. There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript fetch or XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. In a CSRF attack, an innocent end user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user's account.

Wakanda is a JavaScript platform to develop and run web or mobile apps.

References

  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. 1 2 Gravelle, Rob. "Comet Programming: Using Ajax to Simulate Server Push". Webreference.com. Archived from the original on 2010-10-18. 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.{{cite speech}}: CS1 maint: location (link)
  5. 1 2 "Ajax Push". ICEfaces.org. Retrieved 2014-10-23.
  6. Crane, Dave; McCarthy, Phil (July 2008). Comet and Reverse Ajax: The Next Generation Ajax 2.0. Apress. ISBN   1-59059-998-5.
  7. 1 2 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. Archived from the original on 2006-02-08. Retrieved 2008-05-06.
  10. "Netscape.com". Archived from the original on November 15, 1996. Retrieved 2017-08-16.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  11. "java.net.Socket (Java 2 Platform SE v1.4.2)" Archived May 19, 2009, at the Wayback Machine
  12. Beca, Lukasz (1997). "TANGO - a Collaborative Environment for the World-Wide Web". Syracuse University SURFACE. Northeast Parallel Architecture Center, College of Engineering and Computer Science. Retrieved 27 February 2016.
  13. Podgorny, Marek; Beca, Lukasz; Cheng, Gang; Fox, Geoffrey C.; Jurga, Tomasz; Olszewski, Konrad; Sokolowski, Piotr; Walczak, Krzysztof; PL (June 20, 2000), United States Patent: 6078948 - Platform-independent collaboration backbone and framework for forming virtual communities having virtual rooms with collaborative sessions , retrieved 2016-02-27
  14. Baer, Troy (1999). "Experiences with Using TANGO Interactive in a Distributed Workshop" (PDF). CEWES Major Shared Resource Center. CEWES MSRC/PET TR/99-21. Retrieved 27 February 2016.
  15. "CometDaily: Comet and Push Technology". Archived from the original on 2007-11-13. Retrieved 2007-12-15.
  16. Just van den Broecke (1 March 2000). “Pushlets: Send events from servlets to DHTML client browsers”. JavaWorld. Retrieved 1 August 2014.
  17. Borland, John (2001-04-01). "Will the "refresh" button become obsolete?". CNET Networks . Retrieved 2008-07-22.
  18. Alex Russell (3 March 2006). “Comet: Low Latency Data for the Browser Archived 2008-08-12 at the Wayback Machine ”. Alex Russell’s blog. Retrieved 29 November 2007.
  19. K. Taft, Darryl (2006-05-12). "Microsoft Scrubs Comet from AJAX Tool Set". eWEEK.com. Retrieved 2008-07-21.
  20. Orbited: Enabling Comet for the Masses: OSCON 2008 - O'Reilly Conferences, July 21 - 25, 2008, Portland, Oregon
  21. Enterprise Comet & Web 2.0 Live Presentation Archived 2008-05-20 at the Wayback Machine
  22. 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.
  23. Clint Boulton (27 December 2005). “Startups Board the AJAX Bandwagon”. DevX News. Retrieved 18 February 2008.
  24. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, section 6.4. IETF. Retrieved 2014-07-29
  25. 1 2 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.
  26. 1 2 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.
  27. Ian Hickson, ed. (2007-10-27). "6.2 Server-sent DOM events". HTML 5 - Call For Comments. WHATWG . Retrieved 2008-10-07.
  28. Hickson, Ian (2009-04-23). "The WebSocket API". W3C . Retrieved 2009-07-21.
  29. Alex Russell; et al. (2007). "Bayeux Protocol - Bayeux 1.0draft1". Dojo Foundation. Retrieved 2007-12-14.
  30. Crockford, Douglas (2006-04-17). "JSONRequest Duplex". An alternative to XMLHttpRequest for long lasting server initiated push of data. Retrieved 2008-05-05.
  31. 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.
  32. Paul, Ryan. (2010-12-06) App Engine gets Streaming API and longer background tasks. Ars Technica. Retrieved on 2014-04-12.
  33. "Package com.google.appengine.api.channel". Google. 2019-11-16. Retrieved 2020-04-30. This API has been deprecated.