Design and Implementation of Pull Mode in Pushlets Messaging System

Overview

Pushlets implements message pushing via long‑living HTTP connections. Two push modes exist—Poll (polling) and Pull. The article focuses on the design of the Pull mode.

Principle

The client initiates a request; the server processes it according to the Pushlets protocol and returns data in the HTTP response. After handling the response, the client issues a new request, forming the Pull mode sequence.

Protocol Steps

join – client sends a join request, server creates a Pushlet session.

join‑ack – server replies with a session ID.

listen – client subscribes to a topic and starts listening.

listen‑ack – server acknowledges the listen request, returning session and subscription IDs.

subscribe (optional) – client explicitly subscribes to a topic.

subscribe‑ack (optional) – server acknowledges the subscription.

refresh – long‑connection request carrying the session ID.

refresh‑ack – server responds with the next refresh interval, heartbeat (hb), and data if available.

leave – client clears its subscriptions.

leave‑ack – server acknowledges the leave operation.

Server Side

The server maintains sessions and uses an in‑memory queue for each session’s topic events. An event dispatcher publishes events to the appropriate subscriber queues. In Pull mode, a blocking queue is used; a read timeout without events triggers a heartbeat and refresh response.

Event Publishing

Broadcast – send the event to all subscribers.

Multicast – send the event to matching subscribers.

Unicast – send the event to a specific subscriber.

Key Parameters

queue.size=24 – maximum queue length; excess events are dropped.

queue.read.timeout.millis=20000 – read timeout of 20 seconds; after timeout, hb and refresh are returned.

queue.write.timeout.millis=20 – write timeout of 20 ms; if the queue remains full, the subscriber is destroyed.

pull.refresh.timeout.millis=45000 – server destroys a subscriber after 45 seconds of inactivity.

pull.refresh.wait.min.millis=2000 and pull.refresh.wait.max.millis=6000 – the refresh interval is a random value within this range.

Client Side

Pushlets supports various clients, including browsers (iframe or AJAX) and Java applications. After initialization, the client sends listen/subscribe requests and periodically issues refresh requests. When a data response arrives, the client’s onData(event) callback processes the message.

Technical Design

Pushlets is wrapped in a Channel service to abstract its details and facilitate future compatibility with other push technologies such as WebSocket.

Server Implementation

The Channel API establishes a long‑connection between the JavaScript client and the server, enabling real‑time message delivery.

JavaScript Client API

init() – configure server URL and client state.

open() – send a join request to create a session.

subscribe({topic, onmessage, onerror}) – request a subscription.

unsubscribe(topic) – remove a subscription.

close() – send a leave request to destroy the session.

Sequence Diagram

Illustrates the interaction flow between the client and server during join, listen, refresh, and data delivery.

Cluster Deployment

A load balancer with source‑IP stickiness ensures that requests from the same IP are routed to the same server node. After processing, nodes publish messages to a messaging system; subscribed nodes receive these messages and use the Channel service to push them to Pushlets.

References

Message Push Technologies

Google App Engine Channel API

HTML5 WebSocket API

Disclaimer: The content is sourced from public channels on the internet. The author remains neutral and provides it for reference and discussion only. Copyright belongs to the original authors or institutions; please contact for removal if infringement occurs.