PUSH Technologies - An Overview: Difference between revisions

From PiRho Knowledgebase
Jump to navigationJump to search
← Older editNewer edit →
Dex (talk | contribs)
121 edits
Dex (talk | contribs)
121 edits
No edit summary
Line 1: Line 1:
{{DISPLAYTITLE:PUSH Technologies: An Overview}}
{{DISPLAYTITLE:PUSH Technologies: An Overview}}
{{ShortDescription|A clear, practical comparison of real-time PUSH technologies used across modern and legacy hybrid systems.}}
{{ShortDescription|A clear, practical comparison of real-time PUSH technologies across six major mechanisms.}}
{{Infobox PublicTech
{{Infobox PublicTech
| title        = PUSH Technologies: An Overview
| title        = PUSH Technologies: An Overview
Line 8: Line 8:
}}
}}


'''PUSH technologies''' allow servers to deliver updates to clients instantly when data changes, without requiring repeated polling. This article compares the major PUSH mechanisms—Server-Sent Events, WebSockets, MQTT, Long‑Polling, and Web Push—explaining how each works, where they fit, and how to choose between them. It also covers the universal PUSH lifecycle, architectural patterns, and practical considerations.
'''PUSH technologies''' allow servers to deliver updates to clients instantly when data changes, without requiring repeated polling. This article compares the six major PUSH mechanisms—Server-Sent Events, WebSockets, MQTT, Long‑Polling, Web Push API, and the Web Push Protocol (RFC 8030)—explaining how each works, where they fit, and how to choose between them.


== What “PUSH” Means ==
== What “PUSH” Means ==
PUSH reverses the traditional HTTP request/response flow by enabling servers to send updates the moment something meaningful happens. This requires:
PUSH reverses the traditional HTTP request/response flow by enabling servers to send updates the moment something meaningful happens.
This requires:
* a persistent or semi‑persistent channel
* a persistent or semi‑persistent channel
* a subscription mechanism
* a subscription mechanism
Line 23: Line 24:
| SSE || Server→Client || Notifications, dashboards, workflow updates || Low
| SSE || Server→Client || Notifications, dashboards, workflow updates || Low
|-
|-
| WebSockets || Full-duplex || Chat, collaboration, presence || Medium–High
| WebSockets || Full‑duplex || Chat, collaboration, presence || Medium–High
|-
|-
| MQTT || Pub/Sub || IoT, sensors, distributed systems || Medium
| MQTT || Pub/Sub || IoT, sensors, distributed systems || Medium
|-
|-
| Long-polling || Simulated PUSH || Legacy fallback || Low
| Long‑polling || Simulated PUSH || Legacy fallback || Low
|-
|-
| Web Push || Server→Browser || Notifications outside browser || Medium
| Web Push API || Server→Browser (via Service Worker) || User notifications, app background updates || Medium
|-
| Web Push Protocol (RFC 8030) || Server→Push Service→Browser || Reliable delivery, offline notifications || Medium
|}
|}


== Major PUSH Technologies ==
== Major PUSH Technologies ==
=== Server-Sent Events (SSE) ===
=== Server‑Sent Events (SSE) ===
Lightweight one-way PUSH over a long-lived HTTP connection.<br />
Lightweight one‑way PUSH over a long‑lived HTTP connection.
Strengths: simple, efficient, REST-friendly.<br />
Limitations: one-way only; PHP-FPM tuning required.<br />


=== WebSockets ===
=== WebSockets ===
Full-duplex real-time communication.<br />
Full‑duplex real‑time communication.
Strengths: low-latency, binary support.<br />
Limitations: needs event-driven runtime.<br />


=== MQTT ===
=== MQTT ===
Pub/sub protocol designed for IoT and telemetry.<br />
Pub/sub protocol designed for IoT and telemetry.
Strengths: massive scalability, durable subscriptions.<br />
Limitations: requires broker, not browser-native.<br />


=== Long-Polling ===
=== Long‑Polling ===
Held-open requests until change.<br />
Held‑open requests until change.
Strengths: universal fallback.<br />
Limitations: inefficient at scale.<br />


=== Web Push API ===
=== Web Push API ===
Notification delivery even when browser is closed.<br />
Browser-side mechanism for receiving push notifications.
Strengths: great for user-centric alerts.<br />
 
Limitations: not for continuous streams.<br />
=== Web Push Protocol (RFC 8030) ===
Server-to-push-service protocol enabling browser push delivery.


== Universal PUSH Lifecycle ==
== Universal PUSH Lifecycle ==
1. Discovery/Intent<br />
1. Discovery/Intent
2. Channel Establishment<br />
2. Channel Establishment
3. Subscription Registration<br />
3. Subscription Registration
4. Delivery<br />
4. Delivery


== When to Use What ==
== When to Use What ==
* Use SSE for simple one-way notifications.
* Use SSE for simple one‑way notifications.
* Use WebSockets for collaborative apps.
* Use WebSockets for collaborative apps.
* Use MQTT for IoT/distributed messaging.
* Use MQTT for IoT/distributed messaging.
* Use Long-polling for legacy compat.
* Use Long‑polling for legacy compatibility.
* Use Web Push for browser notifications.
* Use Web Push API for browser notifications.
* Use Web Push Protocol when interacting with push services.


== Deep Dive: Server‑Sent Events (SSE) ==
== Deep Dive: Server‑Sent Events (SSE) ==
Server‑Sent Events (SSE) is a server → client streaming technology defined in the HTML Living Standard. Clients receive UTF‑8 encoded events over a long‑lived HTTP connection via the JavaScript `EventSource` interface. (Spec: WHATWG HTML — Server‑Sent Events)
Server‑Sent Events (SSE) is a server → client streaming technology defined in the HTML Living Standard.


=== How SSE Works ===
=== How SSE Works ===
* Client opens a long‑lived HTTP GET request.
* Client opens a long‑lived HTTP GET request.
* Server replies with `Content-Type: text/event-stream` and streams events.
* Server streams events using `text/event-stream`.
* Events may include `data:`, optional `id:` (resume), and optional `event:` (named types).
* Events support `data:`, `id:` and `event:` fields.
* Browsers auto‑reconnect and send `Last-Event-ID` when resuming. (Spec details)
* Browsers auto‑reconnect with `Last-Event-ID`.


=== Example Event ===
=== Example ===
<pre>
<pre>
id: 583
id: 583
Line 86: Line 83:
data: {"order":123,"status":"shipped"}
data: {"order":123,"status":"shipped"}
</pre>
</pre>
=== Strengths ===
* Simple implementation; native `EventSource` API.
* Automatic reconnection and event ID tracking.
=== Limitations ===
* One‑way only (server → client); UTF‑8 text only.
* Browser connection limits for HTTP/1 (commonly ~6 per domain).


== Deep Dive: WebSockets ==
== Deep Dive: WebSockets ==
WebSockets provide full‑duplex, low‑latency communication over a single TCP connection, standardised by IETF RFC 6455.
WebSockets provide full‑duplex communication, standardised by RFC 6455.


=== Handshake ===
=== Handshake ===
WebSockets begin with an HTTP/1.1 Upgrade request and a 101 Switching Protocols response, then switch to WebSocket frames.
HTTP Upgrade request → 101 Switching Protocols → WebSocket frames.


=== Framing ===
=== Framing ===
RFC 6455 defines text, binary, continuation, ping/pong (keep‑alive), and close frames.
Supports text, binary, continuation, ping/pong and close frames.
 
=== Strengths ===
* True two‑way realtime; supports binary payloads.
 
=== Limitations ===
* Requires event‑driven runtimes (e.g., Node.js, Go, Perl EV/Mojo) rather than PHP‑FPM. (Background per protocol/runtime practice)
 


== Deep Dive: MQTT v5 ==
== Deep Dive: MQTT v5 ==
MQTT v5 is a lightweight publish/subscribe messaging protocol optimised for constrained networks; it is an OASIS Standard (7 March 2019).
MQTT v5 is a lightweight publish/subscribe protocol (OASIS Standard).


=== Architecture ===
=== Architecture ===
Clients publish to topics; subscribers receive from topics; a broker (e.g., Mosquitto, HiveMQ, EMQX) routes messages. (Model per spec)
Client publishes → Broker routes → Subscribers receive.


=== Key v5 Features ===
=== Key Features ===
* QoS 0/1/2 (at‑most‑once / at‑least‑once / exactly‑once).
QoS levels, user properties, will messages, shared subscriptions.
* Session expiry, reason codes, user properties, shared subscriptions, Will messages, enhanced flow control.
 
=== Strengths ===
* Efficient over unreliable networks; scales for IoT/telemetry.


=== Limitations ===
== Deep Dive: Long‑Polling ==
* Requires a broker; not browser‑native.
Long‑polling simulates PUSH over repeated held HTTP requests.


=== Flow ===
1. Client opens request.
2. Server holds connection until event.
3. Client reconnects.


== Deep Dive: Push API (W3C) ==
== Deep Dive: Web Push API (W3C) ==
The Push API enables web apps to receive messages when not active, via Service Workers and a browser push service. (W3C latest published version)
Browser-side API enabling notifications via Service Workers.


=== Architecture ===
=== Architecture ===
1) Register a Service Worker → 2) `PushManager.subscribe()` to obtain an endpoint and keys → 3) Server sends encrypted messages to that endpoint → 4) Service Worker handles `push` events (e.g., show notifications).
1. Register Service Worker.
 
2. Subscribe via `PushManager.subscribe()`.
=== Strengths ===
3. Browser obtains endpoint.
* Works when the tab/app is closed; reliable background delivery.
4. Service Worker receives notifications.
 
=== Limitations ===
* Higher latency; quotas in some browsers; not for continuous streaming.
 


== Deep Dive: Web Push Protocol (RFC 8030) ==
== Deep Dive: Web Push Protocol (RFC 8030) ==
RFC 8030 defines the HTTP‑based protocol used by application servers to send push messages to push services, which then deliver them to user agents.
Defines how servers send push messages to browser push services.
 
=== How It Works ===
* App server sends (encrypted) message to a push service over HTTP/2.
* Push service stores and forwards to the user agent when reachable.
* Browser wakes the Service Worker `onpush` handler to process the message.
 
=== Key Features ===
* TTL, urgency, message replacement, and delivery receipts; interoperates with VAPID (RFC 8292) and encryption (RFC 8291).


=== Flow ===
1. App server sends encrypted push message.
2. Push service stores and forwards.
3. Browser wakes Service Worker.


== References ==
== References ==
* [https://html.spec.whatwg.org/multipage/server-sent-events.html Server-Sent Events — WHATWG]
* [[https://html.spec.whatwg.org/multipage/server-sent-events.html|Server-Sent Events — WHATWG]]
* [https://www.rfc-editor.org/rfc/rfc6455 WebSockets — IETF RFC 6455]
* [[https://www.rfc-editor.org/rfc/rfc6455|WebSockets — IETF RFC 6455]]
* [https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html MQTT v5 — OASIS]
* [[https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html|MQTT v5 — OASIS]]
* [https://www.w3.org/TR/push-api/ Push API — W3C]
* [[https://www.w3.org/TR/push-api/|Push API — W3C]]
* [https://www.rfc-editor.org/rfc/rfc8030 Web Push Protocol — IETF RFC 8030]
* [[https://www.rfc-editor.org/rfc/rfc8030|Web Push Protocol — IETF RFC 8030]]


[[Category:Architecture]] [[Category:Standards]] [[Category:Real-Time Systems]] [[Category:Dex White]]
[[Category:Architecture]] [[Category:Standards]] [[Category:Real-Time Systems]] [[Category:Dex White]]

Revision as of 11:34, 5 February 2026

Template:ShortDescription Template:Infobox PublicTech

PUSH technologies allow servers to deliver updates to clients instantly when data changes, without requiring repeated polling. This article compares the six major PUSH mechanisms—Server-Sent Events, WebSockets, MQTT, Long‑Polling, Web Push API, and the Web Push Protocol (RFC 8030)—explaining how each works, where they fit, and how to choose between them.

What “PUSH” Means

PUSH reverses the traditional HTTP request/response flow by enabling servers to send updates the moment something meaningful happens. This requires:

  • a persistent or semi‑persistent channel
  • a subscription mechanism
  • a delivery engine
  • event triggers

Summary Comparison Table

Technology Directionality Ideal Use Cases Complexity
SSE Server→Client Notifications, dashboards, workflow updates Low
WebSockets Full‑duplex Chat, collaboration, presence Medium–High
MQTT Pub/Sub IoT, sensors, distributed systems Medium
Long‑polling Simulated PUSH Legacy fallback Low
Web Push API Server→Browser (via Service Worker) User notifications, app background updates Medium
Web Push Protocol (RFC 8030) Server→Push Service→Browser Reliable delivery, offline notifications Medium

Major PUSH Technologies

Server‑Sent Events (SSE)

Lightweight one‑way PUSH over a long‑lived HTTP connection.

WebSockets

Full‑duplex real‑time communication.

MQTT

Pub/sub protocol designed for IoT and telemetry.

Long‑Polling

Held‑open requests until change.

Web Push API

Browser-side mechanism for receiving push notifications.

Web Push Protocol (RFC 8030)

Server-to-push-service protocol enabling browser push delivery.

Universal PUSH Lifecycle

1. Discovery/Intent 2. Channel Establishment 3. Subscription Registration 4. Delivery

When to Use What

  • Use SSE for simple one‑way notifications.
  • Use WebSockets for collaborative apps.
  • Use MQTT for IoT/distributed messaging.
  • Use Long‑polling for legacy compatibility.
  • Use Web Push API for browser notifications.
  • Use Web Push Protocol when interacting with push services.

Deep Dive: Server‑Sent Events (SSE)

Server‑Sent Events (SSE) is a server → client streaming technology defined in the HTML Living Standard.

How SSE Works

  • Client opens a long‑lived HTTP GET request.
  • Server streams events using `text/event-stream`.
  • Events support `data:`, `id:` and `event:` fields.
  • Browsers auto‑reconnect with `Last-Event-ID`.

Example

id: 583
event: order_update
data: {"order":123,"status":"shipped"}

Deep Dive: WebSockets

WebSockets provide full‑duplex communication, standardised by RFC 6455.

Handshake

HTTP Upgrade request → 101 Switching Protocols → WebSocket frames.

Framing

Supports text, binary, continuation, ping/pong and close frames.

Deep Dive: MQTT v5

MQTT v5 is a lightweight publish/subscribe protocol (OASIS Standard).

Architecture

Client publishes → Broker routes → Subscribers receive.

Key Features

QoS levels, user properties, will messages, shared subscriptions.

Deep Dive: Long‑Polling

Long‑polling simulates PUSH over repeated held HTTP requests.

Flow

1. Client opens request. 2. Server holds connection until event. 3. Client reconnects.

Deep Dive: Web Push API (W3C)

Browser-side API enabling notifications via Service Workers.

Architecture

1. Register Service Worker. 2. Subscribe via `PushManager.subscribe()`. 3. Browser obtains endpoint. 4. Service Worker receives notifications.

Deep Dive: Web Push Protocol (RFC 8030)

Defines how servers send push messages to browser push services.

Flow

1. App server sends encrypted push message. 2. Push service stores and forwards. 3. Browser wakes Service Worker.

References

Retrieved from "http://knowledgebase.pirho.net/index.php?title=PUSH_Technologies_-_An_Overview&oldid=243"