Server Push (Comet) Techniques: Comparison, Implementation, and Best Practices

Introduction

Many applications—monitoring, instant messaging, real‑time pricing—require the server to push updates to the client without the client constantly polling. This article introduces and compares common server‑push solutions, focusing on Comet, which uses HTTP long connections without requiring browser plugins, and discusses how to build server‑push applications with the open‑source Pushlet framework.

Use Cases for Server‑Push

Traditional web models (client request → server response) cannot satisfy scenarios where backend changes (hardware hot‑plug, temperature, voltage, new messages, database updates) must be delivered instantly to the client.

Categories of Server‑Push Techniques

Two main categories exist: solutions that need browser plugins or socket‑based remote calls (e.g., Flash XMLSocket, Java applets), and solutions that rely on HTTP long connections without plugins.

Socket‑Based Approaches

Flash XMLSocket : Requires Flash Player; uses the XMLSocket class to communicate with the server. JavaScript can call Flash‑exposed interfaces to update the HTML page. Limitations include the need for Flash, firewall traversal issues, and dedicated ports.

Java Applet Sockets : Uses java.net.Socket , java.net.DatagramSocket or java.net.MulticastSocket to create socket connections. The main drawback is the inability of the applet to modify the page via JavaScript after receiving data.

HTTP Long‑Connection Approaches (Comet)

Comet Overview : With the rise of AJAX, browsers can send asynchronous requests, but standard AJAX cannot push server updates in real time. Comet leverages HTTP long connections to deliver data without plugins.

Long‑Polling (AJAX) : The client sends an XMLHttpRequest that the server holds open until data is available or a timeout occurs. After processing, the client immediately issues another request. Advantages include asynchronous requests, no plugins, and support in IE and Firefox.

Iframe/Htmlfile Streaming : An invisible iframe’s SRC points to a long‑connection URL; the server streams JavaScript calls such as <script type="text/javascript">js_func("data from server")</script> . The client executes these calls to update the page. Htmlfile (ActiveX) solves IE’s loading‑indicator issue.

Practical Development Guidelines

Do not open more than two HTTP long connections per client, as HTTP/1.1 limits concurrent connections and excess connections are blocked.

Server‑side performance: each connection may consume a thread; use asynchronous I/O (e.g., Java NIO) or servers like Jetty that support continuations to reduce thread usage.

Separate control and data channels: use a lightweight control request to close a data connection when the client unloads, preventing resource leaks.

Maintain a heartbeat: the server sends periodic heartbeat messages when no data is available; if the client does not respond, the server releases resources.

Pushlet – An Open‑Source Comet Framework

Pushlet implements the observer pattern: clients subscribe to events, the server assigns a session ID, and events are multicast to each subscriber’s queue.

Client‑side JavaScript library provides APIs such as join() , leave() , subscribe() , unsubscribe() , listen() , and defines states like STATE_ERROR , STATE_ABORT , STATE_NULL , STATE_READY , STATE_JOINED , STATE_LISTENING . Communication uses XML messages with request types (join, leave, subscribe, etc.) and response types (data, join_ack, heartbeat, error, …).

Server‑side is a Java servlet but the design can be adapted to PHP or C. Pushlet supports streaming, long‑polling, and polling modes, handling event fetching and heartbeat generation accordingly.

Conclusion

Choosing the right server‑push solution depends on application requirements; Comet remains challenging compared to traditional web apps, but ongoing advances in browsers, servers, and open‑source frameworks are making it increasingly viable.