Push, or server push, describes 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, where the request for the transmission of information is initiated by the receiver or client.

  General use

Push services are often based on information preferences expressed in advance. This is called a publish/subscribe model. A client might "subscribe" to various information "channels". Whenever new content is available on one of those channels, the server would push that information out to the user.

Synchronous conferencing and instant messaging are typical examples of push services. Chat messages and sometimes files are pushed to the user as soon as they are received by the messaging service. Both decentralised peer-to-peer programs (such as WASTE) and centralised programs (such as IRC or XMPP) allow pushing files, which means the sender initiates the data transfer rather than the recipient.

Email may also be a push system: the SMTP protocol is a push protocol (see Push e-mail). However, the last step —from mail server to desktop computer— typically uses a pull protocol like POP3 or IMAP. Modern e-mail clients make this step seem instantaneous by repeatedly polling the mail server, frequently checking it for new mail. The IMAP protocol includes the IDLE command, which allows the server to tell the client when new messages arrive. The original BlackBerry was the first popular example of push code for email in a wireless context.^{[citation needed]}

Another popular type of Internet push code was PointCast Network, which gained popularity in the 1990s. It delivered news and stock market data. Both Netscape and Microsoft integrated it into their software at the height of the browser wars, but it later faded away and was replaced in the 2000s with RSS (a pull code).

Other uses are push enabled web applications including market data distribution (stock tickers), online chat/messaging systems (webchat), auctions, online betting and gaming, sport results, monitoring consoles and sensor network monitoring.

  Coding

  HTTP server push

HTTP server push (also known as HTTP streaming) is a mechanism for sending data from a web server to a web browser. HTTP server push can be achieved through several mechanisms.

Generally the web server does not terminate a connection after response data has been served to a client. The web server leaves the connection open so that if an event is received, it can immediately be sent to one or multiple clients. Otherwise the data would have to be queued until the client's next request is received. Most web servers offer this functionality via CGI (e.g. Non-Parsed Headers scripts on Apache).

Another mechanism is related to a special MIME type called multipart/x-mixed-replace, which was introduced by Netscape in 1995. Web browsers would interpret this as a document changing whenever the server felt like pushing a new version to the client.^[1] It is still supported by Firefox, Opera and Safari today, but ignored by Internet Explorer.^[2] It can be applied to HTML documents, and also for streaming images in webcam applications.

The WHATWG Web Applications 1.0 proposal^[3] included a mechanism to push content to the client. On September 1, 2006, the Opera web browser implemented this new experimental coding in a feature called "Server-Sent Events".^[4][5] It is now being standardized as part of HTML5.^[6] Another related part of HTML5 is the WebSockets API, which allows a web server and client to communicate over a full-duplex TCP connection.

  Pushlet

In this technique, the server takes advantage of persistent HTTP connections and leaves the response perpetually "open" (i.e. it never terminates the response), effectively fooling the browser into continuing in "loading" mode after the initial page load would normally be complete. The server then periodically sends snippets of JavaScript to update the content of the page, thereby achieving push capability. By using this technique the client doesn't need Java applets or other plug-ins to keep an open connection to the server. The clients will be automatically notified by new events, pushed by the server.^[7][8] One serious drawback to this method, however, is the lack of control the server has over the browser timing out. A page refresh is always necessary if a timeout occurs on the browser end.

  Long polling

Long polling is a variation of the traditional polling technique and allows emulation of an information push from a server to a client. With long polling, the client requests information from the server in a similar way to a normal poll. However, if the server does not have any information available for the client, instead of sending an empty response, the server holds the request and waits for some information to be available. Once the information becomes available (or after a suitable timeout), a complete response is sent to the client. The client will normally then immediately re-request information from the server, so that the server will almost always have an available waiting request that it can use to deliver data in response to an event. In a web/AJAX context, long polling is also known as Comet programming.

Long polling is itself not a true push, but can be used under circumstances where a real push is not possible, and offers many of the same benefits in terms of rapid delivery. For example, BOSH is a popular long polling alternative to TCP, used when TCP is difficult or impossible (e.g. in a web browser).^[9]

  Flash XMLSocket relays

This technique, used by Cbox and other chat applications, makes use of the XMLSocket object in a single-pixel Adobe Flash movie. Under the control of JavaScript, the client establishes a TCP connection to a unidirectional relay on the server. The relay server does not read anything from this socket; instead it immediately sends the client a unique identifier. Next, the client makes an HTTP request to the web server, including with it this identifier. The web application can then push messages addressed to the client to a local interface of the relay server, which relays them over the Flash socket. The advantage of this approach is that it appreciates the natural read-write asymmetry that is typical of many web applications, including chat, and as a consequence it offers high efficiency. Since it does not accept data on outgoing sockets, the relay server does not need to poll outgoing TCP connections at all, making it possible to hold open tens of thousands of concurrent connections. In this model, the limit to scale is the TCP stack of the underlying server operating system.

  Other coding

The term Comet has been used to describe push technologies applied to Ajax web applications. It is used as an umbrella term for a combination of web technologies such as HTTP server push and long polling (see above).

XMPP is often used for push applications as well, especially the PubSub extensions. Apple uses this code for its iCloud push support.

BOSH is a long-lived HTTP technique used in XMPP, but that can be used on the web. The specification (XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)) reads: This specification defines a transport protocol that emulates the semantics of a long-lived, bidirectional TCP connection between two entities (such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of frequent polling or chunked responses.

  See also

• Apple Push Notification Service
• Android Cloud to Device Messaging Service
• BOSH
• Comet
• Client–server model
• File transfer
• Pull technology
• Push Access Protocol
• Push e-mail
• Reverse Ajax
• SPDY
• Streaming media
• SQL Server Notification Services
• WebSockets
• BlazeDS

  References

1. ^ CGI Programming on the World Wide Web O'Reilly book explaining how to use Netscape server-push
2. ^ Server-Push Documents (HTML & XHTML: The Definitive Guide) O'Reilly book explaining server-push
3. ^ "Web Applications 1.0 specification". http://www.whatwg.org/specs/web-apps/current-work/#scs-server-sent. 
4. ^ "Event Streaming to Web Browsers". 2006-09-01. http://my.opera.com/WebApplications/blog/show.dml/438711. Retrieved 2007-03-23. 
5. ^ "Opera takes the lead with AJAX support among browsers: More efficient streaming". 2006-09-01. http://operawatch.com/news/2006/09/opera-takes-the-lead-with-ajax-support-among-browsers-more-efficient-streaming.html. Retrieved 2007-03-23. 
6. ^ Server-Sent Events
7. ^ Pushlets introduction
8. ^ JavaWorld article about pushlets
9. ^ "XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)". http://xmpp.org/extensions/xep-0124.html#intro. Retrieved 2012-06-26. 

  External links

• W3C Push Workshop. A 1997 workshop that discussed push technology and some early examples thereof
• HTTP Streaming with Ajax A description of HTTP Streaming from the Ajax Patterns website
• HTML5 WebSockets draft specification
• HTML5 Server-Sent Events draft specification
• HTTP Server Push at UDAParts A commercial grade Comet implementation with source code available
• Google Web Toolkit's Server Push FAQ Explains Server Push and how you can achieve this with GWT
• Ajax Push Engine An open source web server for pushing real-time data to Rich Internet Applications using Comet
• GWT Comet Adapter Open source adapter for implementing server push in Google Web Toolkit
• XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH) A dual HTTP long-lived connection
• Part 2 HTML5 Server-push Technologies Introduction into HTML5 Server-push Technologies. Part 1 covers ServerSent Events, Part 2 covers WebSockets
• Data from a Flex Publisher Client to a Consumer Client Covers Apache NMS, ActiveMQ and WebORB