PUSH Technologies - An Overview - Revision history

Dex at 16:42, 14 March 2026

2026-03-14T16:42:12Z

2026-02-05T12:51:22Z

Universal PUSH Lifecycle

← Older revision		Revision as of 12:51, 5 February 2026
Line 55:		Line 55:

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

2026-02-05T12:16:00Z

How it Works

@@ Line 381: / Line 381: @@
 === How it Works ===
-* App server sends (encrypted) message to a push service over HTTP/2.
+The Web Push Protocol, defined in IETF RFC 8030, specifies how an application server sends real‑time push messages to a push service, which then delivers them to the user agent. Rather than sending messages directly to a browser, the application server communicates with an intermediary push service using HTTP/2‑based message delivery semantics. This decouples the application server from the user's network state and allows reliable delivery even when the browser is offline. [1](https://www.hivemq.com/blog/mqtt5-now-an-approved-oasis-standard/)
-* Push service stores and forwards to the user agent when reachable.
-* Browser wakes the Service Worker `onpush` handler to process the message.
+==== 1. Application Server Sends a Push Request ====
 == References ==

2026-02-05T12:13:46Z

How it Works

@@ Line 243: / Line 243: @@
 Long‑polling simulates PUSH over repeated held HTTP requests.
-=== Flow ===
+=== How it Works ===
-. Client opens request.<br/>
+Long‑polling is a technique that simulates server‑initiated updates over traditional HTTP. Instead of opening a persistent connection or upgrading to another protocol, the client sends an HTTP request that the server deliberately holds open until new data becomes available. When the server responds, the client immediately opens a new request, creating the illusion of a continuous stream.
-. Server holds connection until event.<br/>
-. Client reconnects.
+Long‑polling is not a formal protocol; rather, it is a behavioural pattern built on top of standard HTTP and widely used before WebSockets, SSE, and Push APIs became available.
 == Deep Dive: Web Push API (W3C) ==

2026-02-05T12:12:01Z

How it Works

@@ Line 251: / Line 251: @@
 The Push API enables web apps to receive messages when not active, via Service Workers and a browser push service. (W3C latest published version)
-=== Flow ===
+=== How it Works ===
-. Register Service Worker.<br/>
+The Web Push API enables web applications to receive push messages from a server even when the webpage is not open, using a Service Worker as the delivery endpoint. It is defined by the W3C Push API specification and relies on a browser‑specific push service to route messages from the application server to the user agent. [1](https://archive.org/details/rfc8030)
-. Subscribe via `PushManager.subscribe()`.<br/>
-. Browser obtains endpoint.<br/>
+==== 1. Service Worker Registration ====
-. Service Worker receives notifications.
+To participate in Web Push, a site must first register a **Service Worker**.
 == Deep Dive: Web Push Protocol (RFC 8030) ==

2026-02-05T12:10:20Z

How it Works

@@ Line 152: / Line 152: @@
 MQTT v5 is a lightweight publish/subscribe messaging protocol optimised for constrained networks; it is an OASIS Standard.
-=== Flow ===
+=== How it Works ===
-. Client publishes<br/>
+MQTT is a lightweight publish/subscribe messaging protocol designed for efficient communication across unreliable or bandwidth‑constrained networks. Its behaviour and wire format are defined in the OASIS MQTT v5.0 Standard, which specifies the client–server roles, message exchange patterns, quality-of-service levels, session control, and metadata features. [1](https://docs.racket-lang.org/rfc6455/index.html)
-. Broker routes<br/>
-. Subscribers receive.
+==== 1. Client–Broker Architecture ====
 === Key Features ===

2026-02-05T12:08:37Z

How it Works

@@ Line 87: / Line 87: @@
 WebSockets provide full‑duplex, low‑latency communication over a single TCP connection, standardised by IETF RFC 6455.
-=== Flow ===
+=== How it Works ===
-. HTTP Upgrade request<br/>
+WebSockets create a persistent, full‑duplex communication channel between a client and a server. The connection begins as a normal HTTP/1.1 request, but then upgrades to the WebSocket protocol as defined in IETF RFC 6455. This upgrade transforms the traditional request–response cycle into a continuous, bidirectional data stream. [1](https://pirho-my.sharepoint.com/personal/dex_pirho_net/Documents/Microsoft%20Copilot%20Chat%20Files/PUSH_Technologies_Deep_Dives_MediaWiki.txt)
-. 101 Switching Protocols<br/>
-. WebSocket frames.
+==== 1. The Opening Handshake ====
 === Framing ===

2026-02-05T11:45:40Z

How SSE Works

← Older revision		Revision as of 11:45, 5 February 2026
Line 71:		Line 71:
	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. 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 ===		=== How it Works ===
	* Client opens a long‑lived HTTP GET request.		* Client opens a long‑lived HTTP GET request.
	* Server streams events using `text/event-stream`.		* Server streams events using `text/event-stream`.

2026-02-05T11:44:58Z

References

← Older revision		Revision as of 11:44, 5 February 2026
Line 132:		Line 132:

	== 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]]

2026-02-05T11:44:21Z

How it Works

← Older revision		Revision as of 11:44, 5 February 2026
Line 126:		Line 126:
	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.		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~~ ===		=== How it Works ===
	1. App server sends encrypted push ~~message.<br~~/>		* App server sends (encrypted) message to a push service over HTTP/2.
	2. Push service stores and forwards.~~<br/>~~		* Push service stores and forwards to the user agent when reachable.
	3. Browser wakes Service Worker.		* Browser wakes the Service Worker `onpush` handler to process the message.

	== References ==		== References ==