Push technology From Wikipedia, the free encyclopedia

Standard
English: Illustration of CONWIP compared to pu...

English: Illustration of CONWIP compared to pull and push (Photo credit: Wikipedia)

English: Push-pull topology

English: Push-pull topology (Photo credit: Wikipedia)

A push-pull converter schematic

A push-pull converter schematic (Photo credit: Wikipedia)

Diagram of a Push-pull amplifier

Diagram of a Push-pull amplifier (Photo credit: Wikipedia)

English: This figure shows a WAP Push Process ...

English: This figure shows a WAP Push Process and the interaction of all instances involved. Deutsch: Ablauf eines WAP Push Vorgangs. Diese Grafik zeigt die beteiligten Instanzen und ihre Interaktion miteinander. (Photo credit: Wikipedia)

The image shows a technology push, mainly driv...

The image shows a technology push, mainly driven by internal R&D activities and market pull, driven by the external market forces.[1]. Shematic presentation of technology push and market pull[1]. (Photo credit: Wikipedia)

English: A push-pull amplifier

English: A push-pull amplifier (Photo credit: Wikipedia)

English: SMTP transfer model Blue arrows can b...

English: SMTP transfer model Blue arrows can be implemented by SMTP variations (Photo credit: Wikipedia)

Pull push principle.

Pull push principle. (Photo credit: Wikipedia)

Wikipedia Front Page

Wikipedia Front Page (Photo credit: szeke)

Celtic language Wikipedias over time ( Feb 06 ...

Celtic language Wikipedias over time ( Feb 06 – 07 ) (Photo credit: James Morrison)

Push technology

From Wikipedia, the free encyclopedia
Not to be confused with Push–pull technology.
 This article’s lead section may not adequately summarize key points of its contents.Please consider expanding the lead to provide an accessible overview of all important aspects of the article. (September 2012)

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

General use[edit]

Push services are often based on information preferences expressed in advance. This is called a publish/subscribe model. A client “subscribes” to various information “channels” provided by a server; whenever new content is available on one of those channels, the server pushes that information out to the client.

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 asWASTE) 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-email in a wireless context.[citation needed]

Another example is the PointCast Network, which was widely implemented in the 1990s. It delivered news and stock market data. BothNetscape and Microsoft integrated it into their software at the height of the browser wars, but it was never popular and later faded away. Browsers replaced it in the 2000s with RSS (a pull system).

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

Examples[edit]

HTTP server push[edit]

HTTP server push (also known as HTTP streaming) is a mechanism for sending unsolicited (asynchronous) data from a web server to aweb browser. HTTP server push can be achieved through any of 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 occurs (ex: change in internal data which needs to be reported to one or multiple clients), it can be sent out immediately; otherwise, the event would have to be queued until the client’s next request would have been 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 interpret this as a document changing whenever the server feels like pushing a new version to the client.[1] It is still supported by Firefox, Opera, and Safari today, but it is 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] includes a mechanism to push content to the client. On September 1, 2006, the Opera web browser implemented this new experimental system 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 WebSocket API, which allows a web server and client to communicate over a full-duplex TCP connection.

Pushlet[edit]

In this technique, the server takes advantage of persistent HTTP connections, leaving the response perpetually “open” (i.e., the server never terminates the response), effectively fooling the browser to remain in “loading” mode after the initial page load could be considered 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 in order to keep an open connection to the server; the client is automatically notified about 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[edit]

Long polling is itself not a true push; long polling is a variation of the traditional polling technique, but it allows emulating a push mechanism under circumstances where a real push is not possible, such as sites with security policies that require rejection of incoming HTTP/S Requests.

With long polling, the client requests information from the server exactly as in normal polling, except it issues its HTTP/S requests (polls) at a much slower frequency. If the server does not have any information available for the client when the poll is received, instead of sending an empty response, the server holds the request open and waits for response information to become available. Once it does, the server immediately sends an HTTP/S response to the client, completing the open HTTP/S Request. In this way the usual response latency (the time between when the information first becomes available and the next client request) otherwise associated with polling clients is eliminated.

For example, BOSH is a popular, long-lived HTTP technique used as a long-polling alternative to TCP when TCP is difficult or impossible to employ directly (e.g., in a web browser);[9] it is also an underlying technology in the XMPP, which Apple uses for its iCloud push support.

Flash XMLSocket relays[edit]

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

See also[edit]

References[edit]

<Realtime’s push beats Ajax pull> [1]

External links[edit]

[show]
Related articles

Leave a comment