Hubbry Logo
Push technologyPush technologyMain
Open search
Push technology
Community hub
Push technology
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Push technology
Push technology
Push technology
View on Wikipedia
from Wikipedia

Push technology, also known as server push, is a communication method where the communication is initiated by a server rather than a client. This approach is different from the "pull" method where the communication is initiated by a client.[1]

In push technology, clients can express their preferences for certain types of information or data, typically through a process known as the publish–subscribe model. In this model, a client "subscribes" to specific information channels hosted by a server. When new content becomes available on these channels, the server automatically sends, or "pushes," this information to the subscribed client.

Under certain conditions, such as restrictive security policies that block incoming HTTP requests, push technology is sometimes simulated using a technique called polling. In these cases, the client periodically checks with the server to see if new information is available, rather than receiving automatic updates.

General use

[edit]

Synchronous conferencing and instant messaging are 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 decentralized peer-to-peer programs (such as WASTE) and centralized 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: SMTP 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 covered in the 1990s. It delivered news and stock market data as a screensaver. Both Netscape and Microsoft integrated push technology through the Channel Definition Format (CDF) into their software at the height of the browser wars, but it was never very popular. CDF faded away and was removed from the browsers of the time, replaced in the 2000s with RSS (a pull system.)

Other uses of push-enabled web applications include software updates distribution ("push updates"), 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]

Web push

[edit]

The Web push proposal of the Internet Engineering Task Force is a simple protocol using HTTP version 2 to deliver real-time events, such as incoming calls or messages, which can be delivered (or "pushed") in a timely fashion. The protocol consolidates all real-time events into a single session which ensures more efficient use of network and radio resources. A single service consolidates all events, distributing those events to applications as they arrive. This requires just one session, avoiding duplicated overhead costs.[2]

Web Notifications are part of the W3C standard and define an API for end-user notifications. A notification allows alerting the user of an event, such as the delivery of an email, outside the context of a web page.[3] As part of this standard, Push API is fully implemented in Chrome, Firefox, and Edge, and partially implemented in Safari as of February 2023.[4][5]

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 a web browser. HTTP server push can be achieved through any of several mechanisms.

As a part of HTML5 the Web Socket API allows a web server and client to communicate over a full-duplex TCP connection.

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 (for example, a 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 is received. Most web servers offer this functionality via CGI (e.g., Non-Parsed Headers scripts on Apache HTTP Server). The underlying mechanism for this approach is chunked transfer encoding.

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 that changes whenever the server pushes a new version to the client.[6] It is still supported by Firefox, Opera, and Safari today, but it is ignored by Internet Explorer[7] and is only partially supported by Chrome.[8] It can be applied to HTML documents, and also for streaming images in webcam applications.

The WHATWG Web Applications 1.0 proposal[9] 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".[10][11] It is now part of the HTML5 standard.[12]

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.[13][14] 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 requests.

With long polling, the client requests to get more information from the server exactly as in normal polling, but with the expectation that the server may not respond immediately. If the server has no new information for the client when the poll is received, then instead of sending an empty response, the server holds the request open and waits for response information to become available. Once it does have new information, the server immediately sends an HTTP response to the client, completing the open HTTP request. Upon receipt of the server response, the client often immediately issues another server 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.[15]

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

Flash XML Socket relays

[edit]

This technique, used by chat applications, makes use of the XML Socket 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 this identifier with it. 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.

Reliable Group Data Delivery (RGDD)

[edit]

In services such as cloud computing, to increase reliability and availability of data, it is usually pushed (replicated) to several machines. For example, the Hadoop Distributed File System (HDFS) makes 2 extra copies of any object stored. RGDD focuses on efficiently casting an object from one location to many while saving bandwidth by sending minimal number of copies (only one in the best case) of the object over any link across the network. For example, Datacast[17] is a scheme for delivery to many nodes inside data centers that relies on regular and structured topologies and DCCast[18] is a similar approach for delivery across data centers.

Push notification

[edit]
See also: Mobile marketing § Push notifications

A push notification is a message that is "pushed" from a back-end server or application to a user interface, e.g. mobile applications[19] or desktop applications. Apple introduced push notifications for iPhone in 2009,[20] and in 2010 Google released "Google Cloud to Device Messaging" (superseded by Google Cloud Messaging and then by Firebase Cloud Messaging).[21] In November 2015, Microsoft announced that the Windows Notification Service would be expanded to make use of the Universal Windows Platform architecture, allowing for push data to be sent to Windows 10, Windows 10 Mobile, Xbox, and other supported platforms using universal API calls and POST requests.[22]

Push notifications are mainly divided into two approaches, local notifications and remote notifications.[23] For local notifications, the application schedules the notification with the local device's OS. The application sets a timer in the application itself, provided it is able to continuously run in the background. When the event's scheduled time is reached, or the event's programmed condition is met, the message is displayed in the application's user interface.

Remote notifications are handled by a remote server. Under this scenario, the client application needs to be registered on the server with a unique key (e.g., a UUID). The server then fires the message against the unique key to deliver it to the client via an agreed client/server protocol such as HTTP or XMPP, and the client displays the message received. When the push notification arrives, it can transmit short notifications and messages, set badges on application icons, blink or continuously light up the notification LED, or play alert sounds to attract user's attention.[24] Push notifications are usually used by applications to bring information to users' attention. The content of the messages can be classified in the following example categories:

  • Chat messages from a messaging application such as Facebook Messenger sent by other users.[25]
  • Vendor special offers: A vendor may want to advertise their offers to customers.
  • Event reminders: Some applications may allow the customer to create a reminder or alert for a specific time.
  • Subscribed topic changes: Users may want to get updates regarding the weather in their location, or monitor a web page to track changes, for instance.

Real-time push notifications may raise privacy issues since they can be used to bind virtual identities of social network pseudonyms to the real identities of the smartphone owners.[26] The use of unnecessary push notifications for promotional purposes has been criticized as an example of attention theft.[27]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Push technology

View on Grokipedia
from Grokipedia
Push technology, also referred to as server push, is a communication in which a server initiates the transmission of or messages to a client without an explicit request from the recipient, in contrast to where the client must actively request the information. This approach enables proactive delivery of updates, notifications, or content, anticipating user needs or responding to events on the server side. The concept of push technology emerged in the late 1990s amid the growth of the internet and distributed information systems, with early implementations like PointCast providing personalized news feeds directly to users' desktops. Its popularity waned due to bandwidth limitations in unicast-based delivery over early networks, but it resurged with advancements in wireless and mobile technologies, particularly through standards like WAP Push, initially developed by the WAP Forum and later advanced by the Open Mobile Alliance in the early 2000s. Today, push technology underpins real-time applications across web, mobile, and IoT ecosystems, evolving to support scalable, event-driven interactions. As of 2025, advancements include AI-driven personalization and interactive elements in push notifications. Key implementations include the Web Push API, which allows web applications to receive server-sent messages via service workers even when the app is not active, facilitating notifications and background updates in progressive web apps. In mobile contexts, protocols like Apple's Push Notification Service (APNs) and Google's (FCM) enable similar unsolicited deliveries to devices. Emerging in information-centric networking (ICN), push models integrate with pull mechanisms for efficient data dissemination in scenarios like IoT sensor networks and vehicular communications, using techniques such as long-lived subscriptions or special data packets to minimize overhead. These advancements address challenges like network efficiency and privacy, making push technology essential for timely, user-centric information delivery.

Fundamentals

Definition

Push technology is a communication in which servers proactively initiate the transmission of to clients without requiring explicit requests from those clients, differing from conventional client-server models where communication is driven by client-initiated queries. This approach allows for the automatic delivery of updates, alerts, or content directly to user devices or applications, enhancing efficiency in scenarios demanding timely information flow. A prominent example of push technology in modern consumer applications is push notifications. Push notifications are short, timely messages or alerts delivered to a user's device (such as a smartphone, tablet, or computer), even when the associated application is closed or running in the background. These notifications inform users of updates, incoming messages, events, reminders, or other relevant information. The delivery of push notifications typically requires explicit user permission through the device's settings, as implemented on platforms such as iOS and Android. A common implementation of push technology relies on the publish-subscribe (pub/sub) model, where clients subscribe to specific channels, topics, or event patterns of interest, and servers—acting as publishers—automatically disseminate updates to all relevant subscribers upon detecting changes or triggers. In this model, publishers generate events without of specific recipients, while subscribers express their interests independently, enabling between the communicating parties. Key characteristics of push technology include its proactive nature, which facilitates real-time or near-real-time data delivery by notifying clients asynchronously as events occur, rather than relying on periodic checks. It also minimizes resource overhead by eliminating the need for clients to continuously poll servers for updates, thereby conserving bandwidth and computational effort compared to pull-based alternatives. The basic architecture of push technology centers on a intermediary broker or server component that manages subscription lists, matches incoming to active subscriptions, and routes notifications to the appropriate clients, ensuring scalable and operation across distributed systems. This setup supports event-driven interactions, where triggers such as data changes or external signals prompt the push of relevant information.

Comparison to Pull Technology

Pull technology involves client-initiated requests to a server for , typically using protocols like HTTP GET, where the client fetches on demand. This model forms the basis of traditional web browsing and request-response interactions, allowing users to retrieve specific content when needed. In contrast, push technology enables the server to initiate and send to the client without prior requests, shifting the control from client polling to server-driven delivery. The primary difference lies in initiation: pull requires the client to actively query the server, often through repeated polling, while push allows proactive updates from the server. Regarding efficiency, push reduces latency for frequent or real-time updates by eliminating the need for constant client requests, making it suitable for scenarios requiring immediate delivery, whereas pull is more efficient for sporadic access where data is not time-sensitive. Resource utilization also differs: push minimizes client-side polling overhead but can increase server load due to persistent connections, while pull burdens the client and network with repeated queries but lightens server demands. Pull technology excels in use cases involving on-demand , such as searching a database or loading static web pages, where users control the timing of access. Push, however, is preferable for continuous streams, like live news feeds or instant notifications, enabling timely updates without user intervention. Hybrid approaches combine elements of both models, such as using polling in a system to simulate push-like behavior for near-real-time updates, though true push avoids such simulations for better efficiency.

Historical Development

Early Concepts and Precursors

The (SMTP), standardized in the and early , served as an early example of push technology by enabling servers to deliver messages directly to recipients' mailboxes without requiring client-initiated pulls. Originating from implementations in 1971, SMTP formalized a reliable transmission mechanism in 1982 through RFC 821, where a sender-SMTP process initiates a connection to a receiver-SMTP, pushing mail data via commands like MAIL FROM and DATA to support asynchronous delivery across networks. This protocol's design emphasized server-driven propagation, influencing later push paradigms by decoupling senders from receivers in distributed environments. In the , experimental network-based systems began exploring push for information to communities. The Community Information System (BCIS), developed at MIT, represented a pioneering effort by using computer networks to push localized news and updates to users' terminals in real-time, combining broadcast dissemination with user-specific filtering during a 1986 test involving over 200 -area participants. Similarly, systems, introduced in the but widely adopted in the , pushed text-based information such as news and schedules over television broadcast signals, allowing users to access cyclically transmitted pages without active querying, as seen in services like the UK's starting in 1974. Academic research in the laid foundational concepts for push through studies on and data in distributed systems. Early work on extensions, such as the 1985 proposal for host groups in RFC 966, enabled efficient one-to-many data pushes over internetworks, reducing network load by duplicating packets only at routing points rather than at the source. Complementary efforts in broadcast media, including analyses of periodic push over links like those in , highlighted trade-offs in latency and bandwidth for disseminating shared data. In sensor networks, the Distributed Sensor Networks (DSN) program, initiated around 1980, explored push mechanisms for aggregating and relaying data from dispersed nodes to central processors, emphasizing real-time event notification in resource-constrained environments. By the early 1990s, non-commercial roots in groupware emphasized push for maintaining user in collaborative settings. Systems like those developed in academic prototypes pushed subtle notifications—such as cursor movements or document changes—to distributed participants in real-time shared workspaces, as articulated in on workspace awareness to support fluid interaction without explicit polling. These efforts, often building on the publish-subscribe model emerging in distributed systems, focused on low-overhead pushes to foster group coordination in experimental tools.

Commercial Adoption in the 1990s

The PointCast Network, launched in beta in February , marked the first major commercial deployment of push technology, delivering personalized and information channels directly to users' desktops over dial-up connections. By the end of , the service had grown to 1.5 million users and generated $5 million in annual advertising revenue, capitalizing on the era's excitement for automated content delivery. However, it quickly drew criticism for its high bandwidth demands, which caused service slowdowns and congested corporate networks during an era of limited infrastructure. In the mid-1990s, other ventures like BackWeb Technologies (founded in 1995) and emerged to apply push mechanisms for software updates and content distribution, targeting both consumer and enterprise needs. These tools integrated with leading browsers, including 's Netcaster push client released in 1997, allowing for scheduled casting of updates and multimedia content without user intervention. 's Castanet platform, in particular, partnered with to embed push capabilities, facilitating efficient delivery of dynamic web channels and applications. The surge in push technology sparked the so-called "push wars," with over 30 vendors flooding the market amid intense hype that positioned it as the future of internet personalization and commerce. Yet, by the late , escalating bandwidth costs and the broader dot-com bust eroded investor confidence, leading to widespread vendor failures and a pivot away from consumer-focused push systems. As consumer adoption faltered, push technology found renewed traction in enterprise settings, exemplified by Research In Motion's (RIM) commercialization of push-email with the device in January 1999. This wireless pager integrated real-time delivery from servers like , enabling professionals to receive updates instantly without polling. The innovation transformed mobile communication by prioritizing secure, always-on access for business users, driving rapid enterprise adoption and establishing push as a cornerstone of wireless productivity.

Modern Evolution Post-2000

In the early 2000s, push technology underwent a significant shift from proprietary, server-initiated models of the to more user-controlled syndication formats like (Really Simple Syndication), which functioned primarily as a pull mechanism but enabled push-like alerts through frequent polling by feed aggregators. This transition was driven by the decline of pure push systems, such as PointCast, which faced challenges from high bandwidth consumption, intrusive delivery, and limited browser support, leading to their commercial failure by the late 1990s and early . gained prominence around 2002–2003 as a standardized XML-based format for web feeds, allowing users to subscribe to updates from multiple sources via desktop and early web-based readers, thus democratizing content distribution without the resource demands of true push. The rise of around 2005 introduced techniques like and AJAX to simulate push functionality within browser constraints, marking a pseudo-push era that bridged the gap to native standards. , coined in 2006, relied on long-held HTTP connections—such as long polling or streaming—to enable server-to-client data pushes without full page reloads, often integrated with AJAX for asynchronous updates in interactive web applications. This approach addressed the limitations of traditional HTTP's request-response model, fostering real-time features in early social platforms and collaborative tools, though it incurred overhead from repeated connections. Complementing these, the (SSE) specification emerged in 2006 as part of the draft by the , providing a standardized, unidirectional stream for servers to send events to browsers over a persistent HTTP connection, with initial experimental support in . The mobile era accelerated push technology's evolution, beginning with Apple's launch of the Push Notification Service (APNS) in June 2009 alongside 3.0, which allowed third-party apps to deliver remote notifications via Apple's centralized gateway, conserving battery and bandwidth while enabling timely alerts. Google followed with Cloud Messaging (GCM) in June 2012 as a successor to its earlier C2DM service, offering scalable, free push delivery to Android devices and later rebranded as (FCM) in 2016 for enhanced cross-platform support. By the mid-2010s, push notifications had achieved widespread adoption in mobile apps, powering in social, e-commerce, and news applications. In the 2020s, advancements focused on broader web standardization and network enhancements, with the Web Push API gaining near-universal browser support, including partial implementation in 16.4 for and in March 2023, allowing websites to send notifications via service workers without requiring a native app. This completed the API's rollout across major browsers—Chrome since 2015, since 2016, and Edge since 2018—enabling cross-platform push for web apps. Concurrently, networks, deployed widely from 2019 onward, integrated with push systems to reduce latency to under 1 ms in optimal conditions, facilitating ultra-low-latency deliveries essential for real-time applications like updates and IoT alerts. Recent trends as of 2025 include AI-driven hyper-personalization, interactive notifications, and rich media enhancements, improving user engagement and relevance in push deliveries.

Technical Implementations

HTTP-Based Push Methods

HTTP-based push methods enable servers to deliver real-time updates to clients over standard HTTP connections, overcoming the request-response limitations of traditional web protocols by maintaining open or repeatedly renewed connections. These techniques emerged as early workarounds for the stateless of HTTP, allowing unidirectional or simulated bidirectional communication without requiring non-HTTP protocols. They form the foundation for many web applications needing timely data delivery, such as live feeds or notifications, and predate more advanced standards like WebSockets. One of the earliest HTTP-based push mechanisms is HTTP server push, which utilizes the non-standard MIME type multipart/x-mixed-replace to stream sequential content replacements to the client. Introduced by in the mid-1990s, this method allows a server to send multiple document parts over a single connection, where each part replaces the previous one in the browser, effectively pushing updates like animated images or live video frames from webcams. For instance, a server might respond with a boundary-delimited stream of images, enabling real-time visual updates without client-initiated refreshes, though support is limited to certain browsers like and Chrome. This approach, while innovative for its era, lacks and is prone to issues like incomplete browser support and inefficient bandwidth use for non-visual data. Server-Sent Events (SSE) provide a standardized, unidirectional push mechanism defined in the specification, allowing servers to send event data to clients over a persistent HTTP connection using the text/event-stream type. Clients connect via the EventSource , which automatically handles reconnection on failures, ensuring reliable delivery with built-in retry logic (defaulting to 3 seconds). The event stream format consists of simple text lines prefixed with keywords like data: for message payloads or event: for custom types, enabling applications such as tickers or feeds to receive updates without polling. SSE is lightweight and integrates seamlessly with HTTP/1.1 or , but it supports only server-to-client communication and may face proxy timeouts in firewalled environments. Long polling, often associated with the Comet pattern, simulates push by having the client issue an HTTP request that the server holds open until new data is available or a timeout occurs, at which point the response is sent and a new request is immediately initiated. Coined around 2006, Comet encompasses various HTTP streaming techniques, including long polling, to enable asynchronous server updates in web applications like chat systems. This method reduces latency compared to short polling by minimizing empty responses, though it consumes server resources due to sustained connections and requires careful timeout management to avoid overload. A specific implementation is BOSH (Bidirectional-streams Over Synchronous HTTP), an XMPP extension that uses long polling (or similar hold techniques) to tunnel bidirectional XMPP messaging over HTTP, allowing real-time communication in environments blocking direct TCP connections like corporate firewalls. BOSH sessions involve repeated POST requests with deferred responses, supporting features like stream resumption for reliability. Pushlets is a Java-based open-source framework that leverages persistent HTTP connections to deliver events from server-side Java objects to client-side , effectively emulating push notifications without native browser support for real-time protocols. Developed in the late 1990s, it operates via servlets that maintain long-lived connections, subscribing clients to event channels and pushing updates as they occur, often using techniques akin to long polling for compatibility. This framework simplifies integration for Java web applications by handling connection management and event routing, making it suitable for dynamic content updates in DHTML environments, though it predates modern standards and may require updates for current servlet containers.

Web Push and Notifications

Web push technology enables web applications to receive messages from servers even when the application is not actively running in the foreground, primarily through standardized APIs that integrate with browser notification systems. This mechanism relies on a push service intermediary to deliver messages to a service worker, which can then trigger user-visible notifications or background updates. The Web Push API, defined by the W3C, facilitates this by allowing application servers to send encrypted push messages at any time, ensuring asynchronous communication without constant polling. The Web Push API operates over the Web Push protocol (RFC 8030), which supports for efficient message delivery to the push service endpoint, requiring via VAPID keys or similar mechanisms. It mandates the use of service workers to handle incoming push events, such as the 'push' event, where developers can process data and display notifications using the Notifications API. A practical JavaScript implementation for subscribing to web push notifications without a separate explicit permission request relies on the browser auto-triggering the system permission prompt via the subscribe() method if needed. The following simplified code example demonstrates this process, including handling of VAPID public keys, service worker registration, subscription renewal for returning users, and sending the subscription to the server:

javascript

const VAPID_PUBLIC_KEY = document.querySelector('meta[name="vapid-public-key"]').content; const SUBSCRIBE_ENDPOINT = '/api/subscribe'; async function urlBase64ToUint8Array(base64String) { const padding = '='.repeat((4 - base64String.length % 4) % 4); const base64 = (base64String + padding).replace(/-/g, '+').replace(/_/g, '/'); const rawData = window.atob(base64); const outputArray = new Uint8Array(rawData.length); for (let i = 0; i < rawData.length; ++i) { outputArray[i] = rawData.charCodeAt(i); } return outputArray; } async function sendSubscriptionToServer(subscription) { await fetch(SUBSCRIBE_ENDPOINT, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(subscription.toJSON()) }); } async function subscribeUser() { if (!('serviceWorker' in navigator) || !('PushManager' in window)) { console.warn('Push not supported'); return; } const reg = await navigator.serviceWorker.ready; let subscription = await reg.pushManager.getSubscription(); if (!subscription) { subscription = await reg.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: await urlBase64ToUint8Array(VAPID_PUBLIC_KEY) }); } else { subscription = await reg.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: await urlBase64ToUint8Array(VAPID_PUBLIC_KEY) }); } await sendSubscriptionToServer(subscription); console.log('Subscribed/renewed'); } // Auto-renew for returning users if (Notification.permission === 'granted') { subscribeUser().catch(err => console.error('Auto-subscribe failed:', err)); } export async function enablePushNotifications() { if (Notification.permission === 'denied') { console.warn('Notifications blocked'); return; } await subscribeUser(); }

const VAPID_PUBLIC_KEY = document.querySelector('meta[name="vapid-public-key"]').content; const SUBSCRIBE_ENDPOINT = '/api/subscribe'; async function urlBase64ToUint8Array(base64String) { const padding = '='.repeat((4 - base64String.length % 4) % 4); const base64 = (base64String + padding).replace(/-/g, '+').replace(/_/g, '/'); const rawData = window.atob(base64); const outputArray = new Uint8Array(rawData.length); for (let i = 0; i < rawData.length; ++i) { outputArray[i] = rawData.charCodeAt(i); } return outputArray; } async function sendSubscriptionToServer(subscription) { await fetch(SUBSCRIBE_ENDPOINT, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(subscription.toJSON()) }); } async function subscribeUser() { if (!('serviceWorker' in navigator) || !('PushManager' in window)) { console.warn('Push not supported'); return; } const reg = await navigator.serviceWorker.ready; let subscription = await reg.pushManager.getSubscription(); if (!subscription) { subscription = await reg.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: await urlBase64ToUint8Array(VAPID_PUBLIC_KEY) }); } else { subscription = await reg.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: await urlBase64ToUint8Array(VAPID_PUBLIC_KEY) }); } await sendSubscriptionToServer(subscription); console.log('Subscribed/renewed'); } // Auto-renew for returning users if (Notification.permission === 'granted') { subscribeUser().catch(err => console.error('Auto-subscribe failed:', err)); } export async function enablePushNotifications() { if (Notification.permission === 'denied') { console.warn('Notifications blocked'); return; } await subscribeUser(); }

Browser support is widespread: fully implemented in Chrome (since 2015), , and Edge, while provides partial support starting with version 16 on macOS 13+ and 16.4+ in 2023, limited to web apps added to the home screen and requiring user gestures for subscription. In 2025, introduced Declarative Web Push, an enhancement to the standard API that allows subscriptions and notifications without a service worker, improving efficiency and privacy; it is available in on 18.4, 18.4, and macOS 15.5 betas as of 2025. In comparison, native mobile apps provide full push notification support on iOS and Android platforms via dedicated services like APNs and FCM, enabling high user engagement even when the app is closed. This capability requires the user to grant explicit permission to the app to send notifications, typically through a system prompt or in device settings. Push notifications are short, timely messages or alerts that appear on a phone, tablet, or computer—even when the app is closed or in the background—to inform the user of updates, messages, events, reminders, or other information. Push notifications, a core application of web push, differ between remote and local types. Remote notifications are initiated by a remote server and delivered to the device via platform-specific services like Apple's Push Notification service (APNs) or Google's Firebase Cloud Messaging (FCM), allowing cross-device reach even when the app is closed. Local notifications, in contrast, are generated and scheduled directly by the application on the device without server involvement, suitable for timed reminders. APNs was introduced by Apple in 2009 with iOS 3, marking the first widespread mobile push system, while Android adopted similar capabilities in the 2010s, evolving from Google Cloud Messaging (launched 2012) to FCM for enhanced reliability and scalability. To ensure reliable delivery in cloud-based push systems, techniques like Reliable Group Data Delivery (RGDD) replicate data across multiple nodes, mimicking fault-tolerant models such as the three-copy replication in Hadoop Distributed File System (HDFS). RGDD addresses group-oriented traffic in data centers by using sender-initiated with in-network caching and edge-disjoint trees, reducing duplicates and link stress for scalable, loss-free distribution to all recipients. This approach, prototyped in systems like Datacast, achieves near-optimal performance, transmitting large payloads (e.g., 4 GB) in under 17 seconds on 1 Gbps networks with minimal overhead. As a legacy implementation, Adobe Flash's XMLSocket class enabled bidirectional push for real-time applications like chat systems by establishing persistent TCP connections for low-latency XML message exchange, often embedded in a minimal Flash object. This allowed server-to-client pushes without full page reloads, but Flash's end-of-life in December 2020 rendered it obsolete, with browsers blocking content thereafter and prompting migration to modern alternatives like WebSockets.

Alternative Protocols

WebSockets provide a full-duplex over a single TCP connection, initiated via an HTTP upgrade mechanism, allowing servers to push data to clients in real-time without the need for polling or repeated HTTP requests. Standardized in RFC 6455 in December 2011 by the (IETF), the protocol establishes a persistent, bidirectional link that supports low-latency interactions suitable for applications requiring continuous data flow, such as collaborative editing or live updates. Unlike traditional HTTP request-response models, WebSockets enable servers to initiate message transmission at any time once the connection is established, reducing overhead and improving efficiency for push scenarios. The (SMTP), defined in RFC 5321, serves as a foundational push mechanism for asynchronous server-to-client notifications through delivery. As a TCP-based protocol operating at the , SMTP facilitates the transfer of messages from a sending server to a receiving server, effectively pushing content toward the end user's mailbox without requiring client-initiated pulls during transmission. While not designed for real-time delivery—due to dependencies on periodic client retrieval via protocols like POP3 or IMAP—SMTP remains widely used for non-urgent notifications, such as alerts or updates, owing to its reliability and ubiquity in systems. The Extensible Messaging and Presence Protocol (XMPP), outlined in RFC 6120, offers a structured, XML-based framework for near-real-time bidirectional communication, particularly in and presence applications. XMPP operates over TCP, enabling servers to push messages, presence updates, or roster changes directly to connected clients, which supports decentralized, federated networks for scalable push interactions. To accommodate environments restricted to HTTP, such as browsers, XMPP can employ Bidirectional-streams Over Synchronous HTTP (BOSH), specified in XEP-0124, which maintains long-lived HTTP sessions to simulate persistent connections and facilitate push semantics with minimal latency. This hybrid approach has been integral to chat applications, allowing efficient transport of XMPP stanzas in both directions without full reliance on native TCP support. Proprietary methods have also emerged as alternatives for push delivery, often bridging gaps in standard protocols. Early implementations, such as Flash's XMLSocket class, enabled direct TCP socket connections from browser-embedded Flash content to servers, allowing real-time push for applications like multiplayer or chat relays through a lightweight, XML-formatted bidirectional channel. More contemporary solutions include Microsoft's , a .NET library that abstracts real-time push over multiple transports—including WebSockets, , and long polling—to deliver server-initiated updates to clients in web and mobile applications. These proprietary approaches prioritize ease of integration in specific ecosystems, such as .NET environments, while supporting scalable, event-driven push without mandating direct protocol handling by developers.

Applications

Real-Time Communication

Push technology plays a pivotal role in and chat applications by delivering messages to users in real time, even when the app is backgrounded or closed. Applications like leverage Google's (FCM) on Android to transmit push notifications containing only a unique ID, after which the app fetches the message content securely from its servers, ensuring users receive alerts promptly upon message arrival. On devices, both and Slack utilize Apple's Push Notification service (APNs) to send remote notifications for incoming messages, which can manifest as onscreen alerts, badges, or sounds to notify users of new communications. This approach minimizes latency and battery drain compared to constant polling, allowing seamless, end-to-end encrypted delivery in high-volume scenarios. In synchronous conferencing, push technology underpins the signaling process essential for initiating and maintaining video and audio streams. employs signaling servers to push exchange messages, such as (SDP) offers and () candidates, between peers, facilitating direct connections for low-latency interactions. For instance, when a user initiates a video call, the signaling mechanism pushes negotiation data to the recipient's device, enabling rapid setup of media streams without intermediary servers for the ongoing communication, as seen in browser-based conferencing tools. Push technology enables live updates for dynamic content streams, such as feeds and stock tickers, by delivering data instantaneously to maintain user engagement. Twitter's (now X) Streaming uses a persistent HTTP connection to push real-time tweet events to connected clients, supporting features like live timelines where new posts appear without client-initiated requests. This server-driven model ensures sub-second delivery for time-sensitive information, such as market price fluctuations in stock tickers. In gaming and collaborative tools, push technology synchronizes multiplayer interactions and shared editing sessions for immersive, consistent experiences. Multiplayer games rely on WebSockets to push game state updates, including player positions and events, across participants, optimizing for low-latency in web-based 3D environments. Similarly, tools like use WebSockets to push presence indicators—such as active cursors and user avatars—enabling real-time awareness of collaborators' actions during document editing.

Content Delivery and Updates

Push technology facilitates the automated delivery of content updates from servers to client devices or applications without requiring user-initiated requests, enabling efficient maintenance of software, feeds, and data streams. This non-interactive approach relies on server-initiated mechanisms, often built on publish-subscribe models, to ensure timely dissemination while minimizing bandwidth usage through targeted pushes. In software and operating system updates, push mechanisms automate the detection, download, and installation of patches and upgrades to enhance security and functionality. For instance, Microsoft's employs the Windows Update Orchestrator service, which runs in the background to scan for available updates from , them automatically over or metered connections based on policy settings, and install them during active hours or restarts. Similarly, app stores like Apple's and Store support automatic updates by pushing notifications of new versions to devices, triggering background s when the device is idle and connected to , thereby keeping applications current without manual intervention. For news and feeds, push extensions transform traditional pull-based RSS and Atom syndication into real-time channels by notifying subscribers of content changes. The WebSub protocol, standardized by the W3C, allows publishers to register feeds with a hub service that verifies and pushes update notifications to subscribers upon publication, reducing polling overhead and enabling near-instantaneous delivery of personalized news streams. This approach supports customized content channels, where users subscribe to specific topics or sources, receiving tailored updates such as breaking news alerts directly to feed readers or aggregators. In sensor and IoT monitoring, push technology enables devices to proactively transmit data to central systems for analysis and alerting, supporting automated home environments. Protocols like , a lightweight publish-subscribe messaging standard, allow IoT sensors—such as temperature monitors or motion detectors in setups—to push event-triggered data to brokers, which then forward alerts for actions like adjusting thermostats or notifying users of anomalies via integrated apps. This ensures responsive monitoring without constant querying, as seen in systems where smart home devices disseminate status updates to platforms for real-time oversight. Market data distribution in finance leverages push protocols to deliver high-velocity streams of quotes, trades, and updates to trading platforms, critical for low-latency decision-making. The (FIX) protocol supports incremental push dissemination of , where exchanges broadcast real-time price changes and volumes to subscribed clients over TCP connections, ensuring synchronized feeds across global participants. Additionally, networking techniques enable efficient one-to-many pushes of tick data, minimizing delays in high-throughput environments like stock exchanges. Push advertising, commonly known as push ads, utilizes push technology to deliver promotional notifications directly to users' devices following user opt-in consent. These advertisements typically consist of short messages, icons, and images that appear as browser or mobile notifications, implemented using standards such as the Web Push API for web applications or mobile services like Firebase Cloud Messaging for Android and Apple Push Notification service for iOS. This approach enables advertisers to provide timely, targeted promotions, fostering direct user engagement and potentially higher conversion rates compared to traditional pull-based advertising methods.

Challenges

Technical Limitations

One of the primary challenges in push technology arises from the need to maintain persistent connections, such as in WebSockets or (SSE), where each active connection consumes significant server resources including memory, file descriptors, and CPU cycles. For instance, a single server node may handle up to 240,000 concurrent connections with optimized event-driven architectures like or Go, but scaling to millions requires careful resource management to avoid overload from thousands of open sockets. To address this, load balancers are commonly employed to distribute traffic across multiple servers using algorithms such as round-robin or least-connections, enabling horizontal scaling while mitigating single points of failure. Bandwidth and latency issues further complicate always-on push implementations, as continuous connections demand ongoing data transmission for keep-alives and updates, leading to elevated bandwidth consumption on both server and client sides. In mobile environments, these persistent connections exacerbate battery drain by keeping power-intensive cellular or Wi-Fi radios active, even during idle periods, unless optimized with techniques like conditional background execution. Latency can also increase due to queuing delays in high-traffic scenarios or network variability, though push methods generally offer lower end-to-end delays compared to polling alternatives. Reliability remains a key concern, particularly in HTTP-based approaches like long polling and SSE, where network instability frequently causes connection drops due to timeouts, proxies, or mobile network switches. These disruptions necessitate automatic reconnection mechanisms—SSE includes built-in retry logic with exponential backoff—and message queuing systems to buffer undelivered payloads for later transmission, ensuring eventual consistency without data loss. For example, services like Firebase Cloud Messaging queue messages for up to 28 days during offline periods, retrying delivery upon reconnection. Browser and vendor compatibility introduces additional limitations, with variations in support for push APIs across platforms hindering uniform deployment. Notably, on and provided limited Web Push support until version 16.4 (released March 2023), restricting it to Progressive Web Apps added to the and requiring user permission for background delivery. This disparity, compared to fuller implementations in Chrome and , often requires fallback strategies like or in-app polling for broader reach.

Security and Privacy Issues

Push technology, particularly in the form of notifications, raises significant privacy concerns due to the potential for unwanted spam and intrusive tracking. Unwanted notifications often manifest as deceptive alerts promoting scams, such as fake lottery wins or surveys, tricking users into subscribing via disguised prompts like CAPTCHAs or video playback requirements. These spam campaigns have affected over 14 million unique users globally between January and September 2019, with high prevalence in regions like and . In web-based push systems, subscriptions enable persistent delivery of such content even when the browser is closed, exacerbating user annoyance and exposure to malicious links. Tracking via push subscriptions further compromises by revealing user behavior through metadata. Push services like (APNs) and (FCM) collect details such as the app receiving the notification, timestamps, device identifiers, and associated accounts, which can decode app usage patterns without accessing content. This metadata has been requested by governments for , including over two dozen U.S. cases related to investigations like the January 6, 2021, Capitol riots, enabling identification of dissidents, journalists, and whistleblowers. For instance, a 2024 analysis of secure messaging apps using FCM found leaks of user IDs, names, phone numbers, and even message content in unencrypted payloads to servers, affecting apps with over 2 billion installs and undermining promises; of 21 analyzed apps, 11 leaked such metadata without disclosure in policies. The Web Push API mitigates some risks by requiring explicit user permission before subscriptions, typically obtained via a prompted request tied to a user . Similarly, on mobile operating systems such as iOS and Android, applications must obtain explicit user permission through device settings to deliver push notifications. This requirement grants users control over which apps can send alerts, helping to address privacy concerns by limiting unsolicited and potentially intrusive messages. Security vulnerabilities in push systems include risks from man-in-the-middle (MITM) attacks on unencrypted transmissions and token hijacking. Although modern implementations mandate to prevent interception, legacy or misconfigured systems using HTTP expose payloads to , where attackers could alter notification content or steal sensitive data in transit. Push tokens, unique identifiers for devices in FCM and APNs, are susceptible to hijacking if leaked, allowing adversaries to impersonate senders and deliver notifications that users trust as legitimate. These issues, including unauthorized tracking via leaked metadata, facilitate through legal subpoenas. To address these issues, robust and secure subscription are essential. Push subscriptions must use HTTPS-secured endpoints to ensure encryption of message contents per standards like RFC 8291, while endpoints should avoid embedding user-identifiable information to prevent persistent tracking. Tokens require regular rotation—FCM marks inactive ones as invalid after 270 days—and apps should implement for payloads to limit exposure on push service servers. Deactivated subscriptions must be invalidated to avoid reuse as tracking identifiers. Regulatory frameworks like the General Data Protection Regulation (GDPR) impose strict requirements for push consents to protect user rights. Organizations must obtain explicit, informed opt-in consent before sending notifications, treating them as a form of electronic communication under ePrivacy rules, with clear records of consent to demonstrate compliance. Non-compliance can result in fines up to 4% of global annual turnover, emphasizing the need for granular controls. Effective mechanisms, such as browser settings to revoke permissions or app-specific unsubscribe options, are mandated to prevent abuse, allowing users to withdraw consent at any time without penalty. These provisions align with GDPR's emphasis on data minimization and user autonomy, ensuring push systems do not become tools for unchecked or spam.

References

  1. https://www.cs.dartmouth.edu/~dfk/research/project/dagents/papers/cybenko-push.pdf
  2. https://www.openmobilealliance.org/tech/affiliates/wap/wap-250-pusharchoverview-20010703-a.pdf
  3. https://www.mdpi.com/1999-5903/11/3/74
  4. https://onesignal.com/blog/how-mobile-push-expectations-have-changed/
  5. https://developer.mozilla.org/en-US/docs/Web/API/Push_API
  6. https://www.ibm.com/think/topics/push-notifications
  7. https://escholarship.org/content/qt0z35478j/qt0z35478j_noSplash_3f8014718b3c30d3de9e3863c94829c3.pdf
  8. https://dl.acm.org/doi/10.1145/857076.857078
  9. https://developer.apple.com/documentation/usernotifications
  10. https://firebase.google.com/docs/cloud-messaging
  11. https://datatracker.ietf.org/doc/html/rfc8030
  12. https://simplicable.com/design/pull-vs-push-technology
  13. https://datatracker.ietf.org/doc/rfc821/
  14. https://dl.acm.org/doi/10.1145/75577.75580
  15. https://www.historyofinformation.com/detail.php?id=3801
  16. https://datatracker.ietf.org/doc/rfc966/
  17. https://dl.acm.org/doi/pdf/10.1145/276304.276360
  18. https://cs.brown.edu/courses/cs295-1/chong.pdf
  19. https://www.markroseman.com/pubs/wahci96.pdf
  20. https://www.researchgate.net/publication/200772529_A_Descriptive_Framework_of_Workspace_Awareness_for_Real-Time_Groupware
  21. https://www.bloomberg.com/news/articles/1999-04-25/point-cast-the-rise-and-fall-of-an-internet-star
  22. https://thehistoryoftheweb.com/timeline/
  23. https://www.afr.com/politics/users-warned-of-push-risks-19970422-k7dry
  24. https://www.sec.gov/Archives/edgar/data/1082064/000089161803001539/f88613e10vk.htm
  25. https://www.sfgate.com/business/article/Pushing-the-envelope-3130166.php
  26. https://www.cnet.com/tech/services-and-software/netscape-marimba-sign-distribution-pact/
  27. https://adage.com/article/news/netscape-microsoft-add-push-content/3634/
  28. https://blog.lightstreamer.com/2011/07/push-technology-comet-and-websockets-10.html
  29. https://www.the-independent.com/news/business/analysis-and-features/todd-johnson-when-push-comes-to-shove-694062.html
  30. https://www.nytimes.com/library/cyber/week/021698push.html
  31. https://www.investopedia.com/terms/d/dotcom-bubble.asp
  32. https://www.investopedia.com/articles/investing/062315/blackberry-story-constant-success-failure.asp
  33. https://www.ithistory.org/db/hardware/research-motion-limited/blackberry-850
  34. https://www.inc.com/graham-winfrey/blackberry-how-the-world-s-first-smartphone-revolutionized-communication-then-died.html
  35. https://www.vice.com/en/article/the-rise-and-demise-of-rss/
  36. https://twobithistory.org/2018/09/16/the-rise-and-demise-of-rss.html
  37. https://web.archive.org/web/20140704185432/http://dev.opera.com/blog/event-streaming-to-web-browsers/
  38. https://www.braze.com/resources/articles/push-notification-evolution-2009-to-now
  39. https://www.5gamericas.org/the-first-roar-of-the-2020s-is-coming-from-5g/
  40. https://outpush.io/articles/trends-in-web-push-notifications-for-2025
  41. https://docs.oracle.com/cd/E19798-01/821-1752/ggrgt/index.html
  42. https://jacobfilipp.com/DrDobbs/articles/DDJ/1995/9517/9517b/9517b.htm
  43. https://stackoverflow.com/questions/13777508/in-which-browsers-is-content-type-multipart-x-mixed-replace-supported
  44. https://html.spec.whatwg.org/multipage/iana.html
  45. https://html.spec.whatwg.org/multipage/server-sent-events.html
  46. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
  47. https://www.w3.org/TR/2012/WD-eventsource-20120426/
  48. https://www.pubnub.com/guides/long-polling/
  49. https://xmpp.org/extensions/xep-0124.html
  50. https://www.rfc-editor.org/rfc/rfc6202.html
  51. https://www.infoworld.com/article/2161637/pushlets-send-events-from-servlets-to-dhtml-client-browsers.html
  52. http://highlyinternational.com/doc/doc/whitepaper-s6.html
  53. https://www.w3.org/TR/push-api/
  54. https://developer.apple.com/documentation/usernotifications/sending-web-push-notifications-in-web-apps-and-browsers
  55. https://webkit.org/blog/16535/meet-declarative-web-push/
  56. https://developer.apple.com/documentation/usernotifications/asking_permission_to_use_notifications
  57. https://developer.android.com/develop/ui/views/notifications/notification-permission
  58. https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps
  59. https://onesignal.com/blog/understanding-ios-remote-local-push-notifications/
  60. https://www.netguru.com/blog/why-mobile-push-notification-architecture-fails
  61. https://www.microsoft.com/en-us/research/publication/datacast-a-scalable-and-efficient-reliable-group-data-delivery-service-for-data-centers-2/
  62. https://www.tencentcloud.com/techpedia/101546
  63. https://airsdk.dev/reference/actionscript/3.0/flash/net/XMLSocket.html
  64. https://helpx.adobe.com/enterprise/kb/eol-adobe-flash-shockwave-player.html
  65. https://datatracker.ietf.org/doc/html/rfc6455
  66. https://datatracker.ietf.org/doc/html/rfc5321
  67. https://datatracker.ietf.org/doc/html/rfc6120
  68. https://doc.neolao.com/as3_langref/flash/net/XMLSocket.html
  69. https://learn.microsoft.com/en-us/aspnet/core/signalr/introduction?view=aspnetcore-9.0
  70. https://arxiv.org/pdf/2407.10589
  71. https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/
  72. https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling
  73. https://developer.x.com/en/docs/tutorials/consuming-streaming-data
  74. https://www.gamedeveloper.com/programming/optimizing-multiplayer-3d-game-synchronization-over-the-web
  75. https://www.designgurus.io/blog/design-real-time-editor
  76. https://www.w3.org/TR/websub/
  77. https://learn.microsoft.com/en-us/windows/deployment/update/how-windows-update-works
  78. https://support.apple.com/en-us/102629
  79. https://support.google.com/googleplay/answer/113412
  80. https://www.home-assistant.io/integrations/mqtt/
  81. https://finchtrade.com/blog/financial-information-e-xchange-fix-what-is-and-how-does-it-work
  82. https://signalsandthreads.com/multicast-and-the-markets/
  83. https://ably.com/topic/the-challenge-of-scaling-websockets
  84. https://developer.android.com/develop/connectivity/preserving-battery
  85. https://www.smashingmagazine.com/2018/02/sse-websockets-data-flow-http2/
  86. https://www.tencentcloud.com/techpedia/112124
  87. https://firebase.google.com/docs/cloud-messaging/customize-messages/setting-message-lifespan
  88. https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app
  89. https://caniuse.com/push-api
  90. https://securelist.com/unwanted-notifications-in-browser/95060/
  91. https://cacm.acm.org/news/governments-are-spying-on-your-push-notifications/
  92. https://arxiv.org/abs/2407.10589
  93. https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API/Using_the_Notifications_API
  94. https://www.wired.com/story/push-notification-privacy-security-roundup/
  95. https://www.ngrow.ai/blog/push-notifications-in-the-age-of-privacy-navigating-regulations-for-sustainable-engagement
  96. https://www.braze.com/resources/articles/opt-out-of-push-notifications-why-users-do-it
Add your contribution
Related Hubs
User Avatar
No comments yet.