The Spanish Lottery

The best prize is big, but the probability to win this reward, “el Gordo” (”the biggest”), is disappointing, 1/165.750.000, if you just buy one ticket (”décimo”) for 20 euros (around $28 USD).

While I would prefer to waste this money in a casino game where the probability to win is not so low, it is very difficult to escape from this well established and popular tradition (beyond gambling).

The raffle is itself a show because nobody knows when the number with “el gordo” is going to be chosen from a hopper containing all of numbers because concurrently another hopper contains the prizes (containing the big ones and many small prizes). Because many more numbers are taken out randomly with minor prizes, the show takes several hours.

An introduction to the Spanish gambling culture is not the objective of this article, the subject is of course Comet.

Several million people follow this Christmas special event over the radio, television and of course the Internet, especially online newspapers. Are these newspapers using a Comet technique to notify users in real-time when the best prizes are known?

The Experiment

I have watched the most important Spanish online newspapers (elpais.com, elmundo.es, abc.es, 20minutos.es, elperiodico.com, cadenaser.com) to check if the number with “el Gordo” is shown in real-time (listening to the radio is an effective way to know when this occurs). When it comes to technology, Spanish online newspapers are very advanced and have no reason to envy any other international newspaper.

In spite of this, the answer to the question is… NO!!

No newspaper was using any kind of Comet technology or even simple Ajax polling. They all are using a typical full page reload using a timer or a refresh meta tag, typically with an interval of 10 – 15 minutes. This interval is too large and is definitively not real-time in this case.

When “el Gordo” was removed from the hopper, people listening to the radio, usually at work (yes, listening to the radio is usually tolerated this day), compulsively reloaded their preferred online newspaper to check the exact number, because this number, obviously, was not shown in their outdated web page. Consequence: some of these newspaper web sites were stalled for a while.

Can Comet help the Spanish Gambling Culture?

Do not take this question too seriously. This “experiment” is an excuse, based on a concrete and real example, to speculate about how Comet technologies can be introduced to online newspapers or similar web sites with expected, but unpredictable, spikes in traffic.

Comet in Online Newspapers

People like to keep open the main page of their preferred online newspaper to check any change. The main page of an online newspaper is usually (ever?) updated using a simple full page refresh with a JavaScript timer or a refresh meta tag directive.

Full reload of the newspaper’s main page is especially ugly for users and expensive for the server because it contains a substantial amounts of information. Reloading completely takes time, bandwidth and server resources to rebuild the web page because usually newspapers make use of template processors and sometimes querying databases, as with any typical web application.

Online newspapers are designed for the desktop using JavaScript and large screens. Usually there are alternative mobile versions, but most of them do not use JavaScript.

Excluding from this analysis mobile based versions, newspapers make some use of JavaScript and DHTML because web site designers know that virtually 100% of visitors are using modern browsers like Internet Explorer 6+, or those derived from Gecko (FireFox, Mozilla, Camino…) or WebKit (Safari, Chrome). All of these browsers of course have support for Ajax.

We know there are several non-Ajax techniques for Comet, like the forever page, forever frame or script tag long-polling. These techniques are not as clean as Ajax-based alternatives, so I will limit this analysis to Ajax polling and long-polling techniques for this article.

Ajax polling and long-polling can improve the real-time experience of online newspaper readers without excluding users for technological reasons (users with very old browsers are in fact already excluded).

Before trying to add Comet to the news publishing world, one limitation is very important to take into consideration: because most online newspapers are free for users and financed by advertisements, we cannot expense much server power and memory per user because this revenue model only scales with million of readers with a very small cost per user. Web applications for online newspapers are basically stateless. Bandwidth is not a problem because any Comet technique used is a bandwidth saver and usually Comet is a power saver too, but this cannot be said for memory consumption with Comet connection usage.

Comet (Ajax polling or long polling) could be used on two levels:

1. To provide an almost real-time updating service of something specific
2. As a replacement of the old-fashioned full page reload technique

Specific Real-Time Services Based on Comet

The Spanish Christmas Lottery is a very good example of a specific service that could be done with Comet. This event is short in duration and occurs over a reasonably small time frame, so it is worth the effort to spend a bit more server power (it depends on the Comet technique used and the update interval).

For instance, using Ajax polling with an interval of one minute or less, the server can send to the client new reward numbers in almost real-time. The return of most of Ajax requests will be empty (almost no server power and bandwidth used) and will help to avoid the issue of compulsive user reload. What is more expensive: X requests with empty responses, or one request with a useless full page reload? It depends on X and how much a full page reload costs.

Long polling can be more bandwidth effective and can offer the user instant notification, but the server cost can increase because it needs more server resources (connections and memory).

Other similar use cases are notification events of breaking news or during sports games.

The ItsNat Approach

Using ItsNat, this can be easily achieved using an Ajax timer (polling).

On the server, because the dynamic zone is small, most of the server DOM will be declared as static, cached as text (DOM serialized as markup) and shared between all users reducing to the minimum the server memory used per user (client page). ItsNat caching is very important because the memory used by a user must be very small to keep the business need of low small cost per user.

Another alternative is having a fully-static server-side DOM (hence fully cached and shared between users) and dynamic changes served from server as JavaScript code (calling ItsNatDocument.addCodeToSend(String)) to the client to render the dynamic zone usually with the help of a JavaScript framework. In spite of ItsNat, this case is a client-centric solution and ItsNat can be replaced with another technology on the server and toolkits like Dojo can provide Ajax polling.

Replacing the Full Page Reload Technique with Comet

This problem is, by far, more complex.

With Comet, the web page would change partially and only if necessary, avoiding full reloads, reducing server power and bandwidth. However, adding Comet may be analyzed with care because in this context one important piece of this puzzle is server memory. The web application of a newspaper is basically stateless, there is not very much personalization and all users usually see the same content. Adding too much state to the server can increment the server costs (as said before in a service financed with ads), that is to say the web application must remain mainly stateless.

Investigating strategies:

A) Client-centric Approach:

In this kind of problem a JavaScript framework with Comet capabilities like Dojo seems to shine because “the application” is brought to the client and only the strictly necessary user data lives in the server because the client is responsible to keep track of visual rendering and state. For instance the server can instruct the client using Comet (polling or long polling) to render new news, to change the ads showed and so on.

But in this case, what is the application? The main page of a newspaper is an interesting example of a highly flexible web application where data and visual appearance are changing frequently. Sometimes these changes are unpredictable when something very important occurs.

Partially updating this kind of page in an unpredictable “application” is hard to drive and code using JavaScript, because the client code may be outdated, and new code should be injected replacing the old code (the client needs to be “reprogrammed”).

Maybe the most effective action in this case is to notify the client for a full page reload (for instance sending a window.location.reload(true)). So the promise of no full reload is not fulfilled in all cases.

B) Server-centric Approach:

Usually Ajax based server-centric frameworks keep track of the visual state in the server, any change in data model is rendered and the client is updated accordingly. If any part of the web page can change, the page is fully dynamic and must be fully saved in the server. This visual state can use too much memory (maybe valid in any typical web application but not for a newspaper). ItsNat is no different because it uses DOM to save this state in server and in theory any part of the page can change (no caching).

Another problem: if any part of the web page can change, how do you modify the visual state within the server memory programmatically without discarding the current state? In theory ItsNat can fully change the page in server and in client with no reload, so an interesting approach would be to change the original file template and automatically update the DOM tree of the live page with changes. This is an interesting approach to investigate.

The easier solution in ItsNat is to update the file template in server accordingly, notify the server of this change and with a long-polling event, or when the client queries the server to detect any new change (Ajax polling), the server will send a window.location.reload(true) JavaScript instruction or similar to fully update the page. In this case the visual state in the server is almost useless because the page is fully reloaded when something important changes, and the partial update requisite is not fulfilled. So again the promise of no full page reload is not fulfilled.

Conclusion

A newspaper is not a typical predictable and fixed web application. Comet (Ajax polling or long-polling) can be used to partially update some concrete and predictable parts of the web page with client or server-centric strategies, and the cost per user may be acceptable.

If the visual structure of the page randomly changes the most effective strategy is a full reload because the “application” has changed and the visual state saved in server and in client is no longer valid and is very hard to update partially. In this case Comet (polling and maybe long-polling) can be used to detect when the page must be fully reloaded, saving significant bandwidth and server power, but the promise of partial rendering of any part of the page is not fulfilled, so typical Ajax approaches, both client and server-centric may be too inflexible and/or consume too much memory.

This article speculates about how to introduce Comet in the main page of online newspapers, this problem is relatively new and open to ideas and experiences.

What do you think?
What kind of strategy would you choose?

The problem selected is to calculate the PI number through Gregory-Leibniz series. This calculation takes significant time if you want high precision.

The objective of the article is monitoring via the web this server thread with no user interaction, periodically obtaining the estimated value and of course asynchronously notifying to the end user when the calculation has finished. As a bonus, the user can start and stop the server thread through web buttons.

The article has two parts/approaches:

1) In the first part the “polling” technique is used (through the use of a meta refresh directive) alongside Ajax to query the thread state, conventional page navigation technology to start and stop the thread and global variables to hold the thread and calculation states. No specific web framework is used (just servlets and JSPs).

2) The second part uses Comet (long-polling) provided by the ItsNat framework. In this case the application is a single page interface and the thread is only attached to the user’s page. In this case a CometNotifier object provided by ItsNat is “attached” to the web page and to the calculator thread.

Note: the original article has an annoying visual problem, to read it I recommend using MSIE 6 (yes in this case a non-W3C CSS compliant browser is great) or Firefox disabling styles (View/Page Style/No Style).

I’m not a big fan of the WebSocket protocol, as evidenced by my blog on how to improve WebSocket, the BWTP proposal and/or the IETF Hybi mailing list. But Chrome and Firefox will soon be supporting WebSocket, so WebSocket (for better or for worse) will soon be available in the wild.

So if you can’t beat them, join them. Having failed to convince others to create a better protocol, I’m now determined for Jetty to provide the best implementation of the protocol and to become the server of choice for WebSocket Comet development, deployment ( and experimenting with improving the protocol).

Jetty’s async IO architecture is ideally suited to providing a very scalable implementation of WebSocket that is well integrated with standard server-side java application environments. Thus Jetty-7.0.1 now includes a WebSocket server. Feedback welcome!

The CometD project ships the following libraries to develop comet web applications:

* A JavaScript library, with bindings for the well known Dojo and jQuery toolkits
* A Java client library, to be used, for example, in rich Java clients such as Swing applications
* A Java server library, to be used to implement the logic behind you application

The Bayeux protocol is considered complete as well. The Python and Perl versions of the cometD server are not yet production quality, and the project is seeking contributors to help get those servers improved.

Maven users will enjoy the simplicity of getting up and running:

$ mvn archetype:generate -DarchetypeCatalog=http://cometd.org
...
$ mvn install jetty:run

The cometD 1.0 announcement blog has more details, and there’s also a lengthy article on cometD features and extensions.

The project includes a server and a JavaScript framework that is a derivative of MooTools (though it of course works with Dojo, jQuery, and other JavaScript toolkits). APE uses a pub/sub model with its own protocol, and states that it currently scales to more than 100,000 concurrent users. It has some similarities to Orbited in its approach of many other protocols and TCPSockets.

Probably the most interesting point from the performance tests was the conclusion that WebSocket does not yet address compression which can impact overall bandwidth sent across the wire, leading HTML5 lead Hixie to comment that if people want compression, it will be added to the next version as an option.

Starting in the Google Chrome developer channel release 4.0.249.0, Web Sockets are available and enabled by default. Web Sockets are “TCP for the Web,” a next-generation bidirectional communication technology for web applications being standardized in part of Web Applications 1.0. We’ve implemented this feature as described in our design docs for WebKit and Chromium.

Also, Greg Wilkins recently announced that Jetty now supports WebSocket.

Jetty-7.0.1 has been extended with a WebSocket server implementation based on the same scalable asynchronous IO infrastructure of Jetty and integrated into the Jetty Servlet container.

WebSocket came out of work on HTML5 by the What Working Group to specify a mechanism to allow two way communications to a browsers. It is currently being standardized at the W3C for the WebSocket API and by the IETF for the WebSocket protocol and is soon to be supported by releases of Firefox, and Chromium. While I have significant concerns about the websockets protocol, it is important that server concerns are considered in the standardization process. Thus to follow the IETF model of “rough consensus and working code”, it is important that Jetty has a working implementation of the protocol.

WebSync is a full-blown comet server built for the Microsoft stack (IIS/MSSQL/.NET) written in 100% managed C#. Use it to instantly transform your website into a real-time, comet-enabled communications platform.

Jerod Venema recently wrote a guest post for Ajaxian, WebSync: Comet for IIS, explaining in detail about their approach.

One section in particular was of interest to me, their use of Bayeux, but not Dojo:

Once we were satisfied with the server’s performance, we set our sights on a JavaScript client. We had originally been using the Dojo Toolkit, but the overhead was more than what we wanted (it rang in at about 90k after compression, but before gzipping), so we wrote our own library that, when compressed and gzipped, comes across the wire at about 8k total (just over 15k before gzipping). We also ran into a slew of cross-browser issues (of course), in particular when dealing with long-lived HTTP connections. A bit of effort, though, and we can now claim the client to be fully compatible with over a dozen browsers, from IE5.5 all the way to the iPhone and Android browsers. Being fans of open-source technology (even in a Microsoft world), we decided to use the Bayeux transport protocol rather than develop our own, so any Bayeux-compliant client can link in to the server.

I take objection to their Dojo size, as they could have stripped their use of Dojo down to about 8K total as well by stripping out unneeded features.

Since they are supporting Bayeux, then any Bayeux-compliant client such as the one found in Dojo will work with their server. If you are using Dojo and IIS, and are interested in Comet, you should consider WebSync.

Firstly, Sockets, Messages and the Pub Sub Paradigm: Approaches to Streaming which covers the various styles and techniques that people have implemented Comet based products. I have just followed that up with Domain Driven Design: Approaches to Streaming where I talk about a higher level approach which is appropriate when targeting a specific market, as we do at Caplin.

Stock Prices

Solutions for the online trading of securities were the first to adopt Push Technology and the Comet paradigm. In my case, it was actually the requirements of online trading systems that drove the technology. Back in 2000, when I started designing and prototyping Lightstreamer, I had had strong inputs from banks that wanted to get rid of Java applets. At that time, real-time market data (stock quotes and news) was delivered through the Internet to thick desktop applications or to Java applets running inside the browser. The trend of moving from desktop to browser-based applications was already massive and, at the same time, the decline of Java applets had begun (for some well known reasons, including: incompatible runtimes, start-up slowness, expensive maintenance, layout mismatch, etc.).

Nine years ago, the only ready-made solutions for pushing data to a browser without using applets or plug-ins were Pushlets (open source) and Lightstreamer (commercial). Starting from 2006, when the term “Comet” was coined, many more players, both open source and commercial, has come into the arena, making modern Push Technology more and more visible and recognized in the mainstream.

Banks and financial institutions are still the most demanding Comet-technology consumers. Their requirement of pushing real-time market data to the browser is still there, with additional requirements of low latency, high scalability, bandwidth throttling, and the support of multiple client-side technologies, including Ajax, Flex, Silverlight, and iPhone.

In recent years, many online gaming companies, especially in the UK, have found a great technological ally in Comet. Spread betting in particular, which is often on the boundary between finance and gaming, shares the same requirements of more traditional online trading applications. Many other types of games and auctions are progressively adopting Comet technologies.

The live example above is based on the most typical Lightstreamer demo. You can check out the full source code and explanation.

Chat

To the left you can see a basic, fully-functional chat application. It is implemented in pure HTML and JavaScript and is able to deliver each message with zero latency (that is, no round trip to retrieve a new message, thanks to streaming or long-polling, depending on the environment).

Chat applications have often been considered the “Hello World” of Comet (even if in the past I preferred to publish an actual “Hello World” application…). One of the first players to propose a full-fledged messenger application based on the Comet paradigm was Meebo. Previously, web chats relied on page refresh or applets/plug-ins. Soon after the success of Meebo, the arena of new generation chats/messengers quickly became crowded. It is interesting to notice that the widespread success of Comet chats arrived with the in-house engineering made by the major social companies. Google Talk inside Gmail and the Facebook chat are two clear examples.

Chat and messenger Comet applications are much simpler and lighter on requirements with respect to online trading Comet applications. For instance, bandwidth throttling and very low latency are generally not really necessary. Even if the number of concurrent users can be higher than trading applications, the event throughput for each user is much lower. This means that the overall outbound message throughput is generally much higher in trading applications (you can have tens of messages per second per user in trading vs. one per second or less in chats). So, the only requirement for chat-oriented Comet servers is to scale well over high numbers of TCP sockets. While Meebo started with lighthttpd, the major social sites developed their servers internally, more than using off-the-shelf products.

The live chat example above is based on another Lightstreamer demo. You can check out the full source code and explanation.

Even More Chat

The launch of Google Wave pushed real-time interaction a step further. One of the features of Google Wave that caused most hype is the character-by-character real-time dispatching of messages. Well, let me mention immodestly that here at Lightstreamer we publicly demonstrated this feature in February 2006, when my colleague Simone Fabiano came up with this idea, based on early desktop chat platforms, and implemented a demo .

Above you can play with that demo, which is quite effective (what do you think?). Just type something in any of the two “broadcast” fields. Your message will be pushed in real-time as you type it to all the browsers connected to this page. For the best experience, open this page in two different browsers, or ask a colleague to visit this page in their browser as well.

You can check out more information on this demo.

Monitor Consoles

From a more general perspective, the Comet paradigm is the right solution when you need to monitor the state of any variables in real time. There exist many kinds of monitor consoles. There are consoles for monitoring software processes, hardware components, the physical environment (e.g. atmospheric or geological variables), transportation systems, etc. These consoles are often web-based and they usually provide the current snapshot for a given set of variables. Again, being able to push updates for such variables in real-time, without a manual page refresh or traditional Ajax polling techniques, will provide a dramatic improvement to the system.

Above you can see an example of a tiny monitor console, which shows some real-time variables of an actual Lightstreamer Server instance. The demo is pushing updates on: the free memory on the server, the current number of connections to the server, the current total outbound bandwidth used by the server, and the total number of bytes pushed since server’s startup.

Again, the full Lightstreamer demo from which the example above was extracted is available with source code and explanations.

Conclusions

I focused on three typical examples of real-time applications. Many more application domains can benefit from the Comet paradigm. The raise of the number of good Comet servers on the market, both free and commercial, is helping many application progressively transition to the Comet-driven real-time web.

Many other online examples are available from the Lightstreamer gallery, covering several different client-side technologies (including Ajax, Flex, Silverlight, .Net, Java, and iPhone). Below is the full list to date:

HTML & JavaScript

• Basic Stock-List Demo
• Stock-List Demo
• Framed Stock-List Demo
• Bandwidth Demo
• Simple Grid Demo
• Chart Demo
• Basic Portfolio Demo
• Portfolio Demo
• Drop-Down Demo
• Basic Chat Demo
• Basic Instant Messenger Demo
• Round-Trip Demo
• Monitor Console Demo
• Web Telemetry Demo
• RSS News Reader Demo
• Mini Stock-List Demo
• Mini Chart Demo

Other Ajax Frameworks

• TIBCO General Interface :: Basic Stock-List Demo
• TIBCO General Interface :: Advanced Stock-List Demo
• Dojo :: Stock-List Demo
• Microsoft ASP.NET AJAX :: Stock-List Demo
• OpenAjax Alliance - InteropFest 1.0

Flash, Flex, and Air

• Flash Bridge :: Basic Demo
• Flash Bridge :: Stock-List Demo
• Flex :: Stock-List Demo
• AIR :: Stock-List Demo

Silverlight

• Basic Stock-List Demo

.NET

• Basic Stock-List Demo

Java SE

• Trading Client Demo

Java ME

• Basic Stock-List + Round-Trip Demo

Others

• Excel DDE Demo
• iPhone Demo