Data transport and delivery

PubNub delivers real-time messages over ordinary HTTPS rather than over a dedicated real-time protocol. This page explains the transport that carries the subscribe stream, why PubNub chose it, and which delivery properties come from the transport rather than from your application.

One property underpins all of them: the transport is stateless between requests, and continuity comes from a timetoken cursor the client carries from one request to the next.

Transport mechanism

PubNub uses HTTP long polling for all real-time delivery. When your app subscribes to a channel, the SDK sends an HTTP request naming the channels the client wants. The PubNub network holds that request open instead of answering immediately. A published message arrives as the response to the waiting request. A subscribe request is held open for up to 310 seconds before the client reissues it with an updated timetoken cursor.

When the hold ends, whether with a message or on timeout, the SDK immediately issues the next request and advances its cursor to the last position it received. Nothing is delivered in the window between two requests, because the next request asks for everything published after the cursor rather than for whatever is happening now. That cursor, not the socket, is what makes the loop reliable. That's also why an idle channel and a busy one produce the same visible pattern: a request that waits, returns, and is replaced.

Why not WebSocket

PubNub doesn't use WebSocket. Long polling is built from ordinary HTTP request and response pairs, so the subscribe stream travels the same path as any other HTTPS request. It passes through corporate proxies, CDNs, load balancers, and restrictive firewalls without the connection-upgrade failures and fallback paths a WebSocket deployment has to handle. It also works in older client environments that have no WebSocket support at all.

Browser and server transports

Browser SDKs issue subscribe requests with the fetch API and fall back to XMLHttpRequest in environments that lack it. Node.js SDKs use pooled HTTP/2 connections where the origin supports it. The subscribe loop behaves identically on all of them, because the behavior lives in the cursor rather than in the HTTP client.

PubNub supports HTTP/2 on select origins and negotiates it automatically, and HTTP/1.1 is fully supported on every client and endpoint. Both versions serve the same goals: delivery in any network, low bandwidth overhead, and low power consumption on mobile.

HTTP/2 on custom origins

To request HTTP/2 support for a custom origin, contact PubNub Support.

The connections the SDK opens

A client opens a long-lived connection for the subscribe loop and a separate short-lived connection for publish, presence, history, and every other REST call. The two differ in lifetime, in which timeout governs them, and in what a failure looks like. Both are managed by the SDK, and neither is something your code opens. For the split, the socket count it produces, and the per-SDK timeouts, refer to Connection management.

What the transport guarantees

Two properties come from the transport and the timetoken rather than from anything you configure.

At-most-once live delivery

Live delivery to subscribers is at-most-once by default. On a stable connection, a subscriber receives each message at most once. After a reconnect, a replayed message can arrive again with the same timetoken. A subscriber can also miss messages if its buffer overflows or if it's disconnected when someone publishes a message.

The cursor boundary is exclusive, so a client resuming from its last received timetoken asks only for what came after it. Even so, a message handler that must not process a message twice tracks the timetokens it has already processed.

Publish-processing latency, the time PubNub takes to accept and acknowledge a publish request, is about 0.5 ms within the same region.

Message ordering

PubNub assigns every published message a server-side timetoken: a monotonically increasing 17-digit value precise to 100 nanoseconds (10⁻⁷ s), the number of 100-nanosecond intervals since the Unix epoch.

PubNub assigns every message a server-side timetoken when it accepts the publish. The timetoken records when PubNub accepted the message, which can differ from when the client sent it. History fetched through Message Persistence returns a channel's messages in timetoken order.

A subscriber receives live messages in the order they reach it, and each message carries its timetoken. Arrival order can differ from timetoken order and from one subscriber to another. Sorting a channel's messages by timetoken gives every client the same order. Timetoken order applies within a channel, so each channel's messages sort on their own.

That's what lets channels scale out without coordination between them.

Recovering what the live path missed

Loss on the live path has one bounded cause: a burst that overflows the subscriber message buffer while the client isn't there to read it. Recovery is a platform capability rather than something you build, and it has two independent mechanisms.

• For a short gap, such as a tunnel or a Wi-Fi handover, the client reconnects with its preserved cursor and replays the connection's message buffer automatically.
• For a longer gap, such as a backgrounded app or a flight, replay history from the last timetoken your app actually processed using Message Persistence.

Buffer replay and history replay are independent, and one doesn't fall back to the other. If a disconnect may have outlasted the buffer window, treat history replay as the recovery path rather than relying on automatic catch-up. For the buffer's size and window, and for what else survives a reconnect, refer to Connection management.

Building at-least-once delivery on top of the at-most-once live path, retrying a publish, and adding your own idempotency key are publish-side decisions. Refer to Delivery semantics.

Global network

PubNub operates 11 message-routing Points of Presence (PoPs) at the region and data-center level, across North America, Europe, Asia Pacific, and Southern Asia.

Measured end-to-end delivery latency, from publisher to subscriber wire to wire and including network transit, averages approximately 57.79 ms, or approximately 64.97 ms across zones.

A message published to any channel is replicated across Points of Presence automatically, and subscribers receive it from the closest available PoP with no configuration on your part. For how routing, replication, and failure containment produce those figures, refer to How PubNub works.

Next steps

• Connection management - status events, reconnection policies, and the subscriber buffer.
• Publish - the publish response, delivery semantics, and retry decisions.
• Subscribe - how a client chooses what the transport delivers to it.
• API limits - buffer size, catch-up ceiling, and multiplexing guidance.