Design and Implementation of Pull Mode in the Pushlets Messaging System
This article explains the Pull mode of Pushlets, detailing its protocol, server‑side session management, client interactions, key configuration parameters, and the encapsulated Channel API that enables long‑connection message pushing for browsers and Java clients.
Pushlets implements message pushing over long‑living HTTP connections, offering two push models: Poll (polling) and Pull. The article focuses on the Pull model, describing its request‑response flow where the client initiates a request, the server processes it according to the Pushlets protocol, and data is returned via HTTP.
The Pull sequence includes steps such as join (session creation), join‑ack (session ID return), listen (topic subscription), listen‑ack , optional subscribe and subscribe‑ack , periodic refresh requests, and corresponding acknowledgments ( refresh‑ack , hb , data ), ending with leave and leave‑ack to clear subscriptions.
On the server side, sessions are maintained in memory queues, and a dispatcher publishes events to subscriber queues. Pull mode uses blocking queues; when a read timeout occurs (no events), the server replies with heartbeat and refresh commands. Event publishing supports broadcast, multicast, and unicast, and key parameters such as queue size, read/write timeouts, and refresh intervals are configurable.
The client side can be a browser (iframe or AJAX) or a Java application. After initialization, the client sends listen and subscribe requests, then repeatedly issues refresh requests. When a data response arrives, the client’s onData(event) callback processes the message.
For extensibility, the Pushlets functionality is wrapped in a Channel service that abstracts the push mechanism, allowing future replacement with technologies like WebSocket. The Channel API defines a JavaScript oaweb.Channel() class with methods init() , open() , subscribe() , unsubscribe() , and close() , which manage the underlying long‑connection lifecycle.
In a clustered deployment, a load balancer with source‑address persistence 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 forward them through the Channel service to the appropriate Pushlets implementation.
The article concludes with references to related push technologies such as Google App Engine Channel API and HTML5 WebSocket, and includes a disclaimer that the content is for reference only and sourced from public internet channels.
Art of Distributed System Architecture Design
Introductions to large-scale distributed system architectures; insights and knowledge sharing on large-scale internet system architecture; front-end web architecture overviews; practical tips and experiences with PHP, JavaScript, Erlang, C/C++ and other languages in large-scale internet system development.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.