Push and pull technologies

Short polling is a common method where a client sends a request to a server and receives a response with available data at that moment.

In this model, a consumer runs periodically—say every 10 seconds—making an HTTP request to a broker. The broker replies immediately with one or several messages, up to a predefined maximum.

Short polling is simple to understand and implement. However, it has key drawbacks.

Defining an optimal polling interval is difficult. Too infrequent polling risks delaying message consumption. Too frequent polling wastes resources.

Each HTTP request requires a connection. The broker must authenticate, authorize, check client quotas, decrypt, deserialize, and validate the request.

These operations consume server resources, especially when polling is frequent.

Long polling improves on short polling by reducing empty responses.

The client makes an HTTP request to the broker. If data is available, the broker responds immediately.

If no messages exist in the queue, the broker does not respond. Instead, it waits for a message to arrive.

The client also waits on the open connection. Both sides remain idle until one of two events occurs:

• A message arrives in the queue, and the broker sends it to the client.
• The wait time expires, and the broker sends an empty response.

The wait time can be specified in two ways:

• As a request parameter by the client.
• As a static configuration value set by the broker.

After receiving a response—whether with data or an empty reply—the client immediately initiates a new request.

This behavior resembles an endless while loop: the consumer stops the world, waits for a response, then restarts the loop.

Long polling reduces empty responses and ensures consumers receive messages as soon as they arrive in the queue.

Short polling is better when a consumer expects an immediate response from the broker.

For example, a single thread polling multiple queues may experience delays.

With long polling, the thread waits for messages in the first queue, delaying processing of other queues.

Best practice: a single polling thread should process only one queue.

We now examine push technologies that enable servers to send data directly to clients.

We will explore two popular push methods: WebSocket and Server-Sent Events (SSE).

Before discussing WebSocket, consider how a server can push data to clients.

Every HTTP request relies on an underlying TCP connection. While HTTP is unidirectional—clients send requests and servers reply—TCP is bidirectional, allowing both ends to send data in either direction.

The HTTP protocol does not permit the server to initiate data transmission on this connection. This creates a limitation: servers cannot proactively push data to clients.

TCP connections can use standard ports like 80 (HTTP) or 443 (HTTPS), which are typically open and firewall-friendly. Other ports can be blocked, making this a secure and accessible setup.

However, TCP operates at the byte level—a stream of raw bytes. This is not developer-friendly. Messages are easier to work with than raw byte streams.

This is one of the main reasons HTTP’s request-response model is so widely adopted.

What if we built a message-based protocol that runs over standard HTTP ports (80 or 443)?

Such a protocol could reuse the initial TCP connection established for an HTTP request.

It would allow bidirectional communication and be compatible with all major browsers and web servers.

This protocol already exists: WebSocket.

The client sends a regular HTTP request to the server.

The only special part is the Upgrade header, which signals the client’s intent to establish a WebSocket connection.

If the server supports WebSocket, it responds with an Upgrade header in its reply.

Once the handshake completes, communication switches to the WebSocket protocol over the same TCP connection.

Now, the client and server can exchange WebSocket messages in both directions.

• Fast communication
• Bidirectional data flow
• Native browser support
• A viable alternative to raw TCP sockets when security policies block direct socket usage

WebSocket may be overkill for use cases where only one-way communication is needed.

For example, a server might only need to push notifications to a browser periodically.

A simpler solution exists: Server-Sent Events (SSE).

When a user opens a mailbox page, the browser sends a regular HTTP request.

Along with the page, a small JavaScript snippet is downloaded and executed.

This script opens a persistent HTTP connection to the server.

The server uses this connection to push data to the client.

For simplicity, imagine a server job that runs periodically, checks for new emails, and sends a notification to the browser whenever a new email arrives.

If the connection drops, the client automatically attempts to reconnect.

MessageData is a stream that allows the server to send arbitrary text to the client—such as JSON or XML—converted into a stream.

• Simple to implement on both client and server
• Uses standard HTTP as transport
• Does not require custom protocol or server code to function

• Monodirectional: data flows only from server to client
• Supports only text data
• Does not support binary data

Each browser has a hard limit on the number of simultaneous open connections it can maintain.

This limit is imposed by the browser's architecture and security model.

For example, Chrome typically allows up to 60 concurrent connections.

This constraint applies regardless of the server or protocol used.

The limit is not based on bandwidth or performance.

It is a per-browser, per-origin restriction.

This means each unique domain or subdomain counts separately.

A single browser instance can only maintain a finite number of active connections.

This cap prevents resource exhaustion and potential denial-of-service attacks.

The limit is enforced at the transport layer.

It does not depend on the application layer or data size.

For instance, a user loading 100 images from different domains will hit the limit if each domain requires a separate connection.

The number of connections is not proportional to the amount of data transferred.

It is strictly tied to the number of distinct origins.

This behavior is consistent across modern browsers.

It applies to both HTTP and HTTPS.

It also applies to WebSocket and other real-time protocols.

The limit is not adjustable by users or developers.

It is a built-in security and stability feature.

Understanding this constraint is essential when designing systems that rely on frequent, small data exchanges.

Failure to account for it may result in degraded performance or failed requests.

Designers must consider connection pooling or server-side coordination to work around it.

This is especially critical in push-based systems where frequent updates are expected.

A system that sends updates every second may exceed the limit if not managed properly.

The limit is not shared across browser tabs or windows.

Each tab operates independently with its own connection cap.

This means a user with multiple open tabs may reach the limit faster than expected.

The cap is per-origin, not per-URL or per-resource.

This distinction is critical for scalability and reliability.