Comet (programming)

Early Java applets

The ability to embed Java applets into browsers (starting with Netscape Navigator 2.0 in March 1996^[11]) made two-way sustained communications possible, using a raw TCP socket^[12] 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,^{[13][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.^[14] TANGO framework has been extensively used as a distance education tool.^[15] 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,^{[16][unreliable source?]} with the Pushlets, Lightstreamer, and KnowNow projects. Pushlets, a framework created by Just van den Broecke, was one of the first^[17] 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.^[18]

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.^[19] The new term was a play on Ajax (Ajax and Comet both being common household cleaners in the USA).^[20][21][22]

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.^[23] 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.^[24]

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:

Ajax with long polling

This article may contain original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (December 2017) (Learn how and when to remove this message)

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: