PUSH Technologies - An Overview: Difference between revisions
| Line 106: | Line 106: | ||
=== Flow === | === Flow === | ||
1. Client opens request. | 1. Client opens request.<br/> | ||
2. Server holds connection until event. | 2. Server holds connection until event.<br/> | ||
3. Client reconnects. | 3. Client reconnects. | ||
Revision as of 11:38, 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. Clients receive UTF‑8 encoded events over a long‑lived HTTP connection via the JavaScript `EventSource` interface. (Spec: WHATWG HTML — Server‑Sent Events)
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, low‑latency communication over a single TCP connection, standardised by IETF 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 messaging protocol optimised for constrained networks; it is an 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)
The Push API enables web apps to receive messages when not active, via Service Workers and a browser push service. (W3C latest published version)
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)
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.
Flow
1. App server sends encrypted push message.
2. Push service stores and forwards.
3. Browser wakes Service Worker.
