Comet: the New Communication Platform?

by Jerod VenemaJuly 12th, 2010

One of the most interesting things I have seen from our clients over the past few months is the myriad of ways in which they use Comet technology. We had a very specific problem in mind when we build WebSync, namely real-time updates in a browser with ASP.NET and IIS, and it solves that problem admirably. Even as I realized some of the other uses-cases for WebSync (such as bypassing firewall restrictions for Windows-based applications), I don’t think I quite realized the huge number of possibilities that were really available with a standards-based Comet server.

What is Comet, really?

When I think of Comet, my mind immediately jumps to the idea of the “real-time web”, which is probably what the majority of Comet developers think about as well. Live updates in a web browser, awesome! But recently, I’ve seen more and more people using WebSync to solve other problems, and for many applications that are not strictly web-based. These applications may be *partially* web-based, but often times they have other components as well - desktop, mobile devices, you name it.

Comet is, in my opinion, much more than just a way to push data to a web browser. It’s a complete platform for real-time communication, built on top of HTTP, for all languages and purposes, not just the web.

A multitude of devices

When I was at the University, my design project was an application for managing equipment within a nano-fabrication lab on campus. It had a web front-end for managing users and devices, a Windows CE component to send signals to the switch, and an ethernet-enabled relay switch for actually controlling the various pieces of equipment. This was, overall, a very small project. But it already had 3 separate components and required programming in 2 software languages and some hardware design as well.

Fast forward to today. Applications aren’t getting any simpler. More people and businesses want devices that can communicate between the web, desktop, and mobile devices, and Comet is ideally suited to doing exactly this! Since Comet runs over HTTP, you can typically side-step any issues with firewalls, network configurations, etc. Additionally, if your server is based on open standards (such as the Bayeux protocol), integration with other languages and platforms becomes a snap - WebSync, for example is able to communicate with applications build on Windows Forms, Windows CE, Windows Phone, JavaScript, Silverlight, PHP, and we’re considering Java too (although since the cometD project has already written a Java client for their Bayeux implementation, that client should work with WebSync as well). With Comet (and Bayeux in particular) at the center of your communication, the sky is truly the limit. Let those Windows Phone Apps talk to your web apps, and throw in a notification system to sit in your system tray while you’re at it.

Comet can actually become the foundation on which your entire application is built, tying all these pieces together into one seamless unit!

A communication platform

To me, this is all rather amazing, really. When we started building WebSync, we were building a solution to a problem we needed to get past ourselves - pushing data to a web browser in real time using ASP.NET and IIS. By solving that problem, we’ve actually created a whole communication platform, with all kinds of integration points and incredible extensibility. What are your thoughts on using Comet as more than just a simple browser-push solution?

3 Responses to “Comet: the New Communication Platform?”

  1. RogerV Says:

    I’ve been architecting applications using Comet for several years now. One thing that can become an issue is scalability (when you want thousands of concurrent connections per physical server and not just hundreds).

    In the Java arena scalability was limited by servlet containers such as Tomcat. Establishing a Comet connection to tomcat servlet and doing long polling or HTTP streaming would tie up a thread on the server. This was okay for hundreds of such connections but not for 10K to 20K such connections - the OS would fall over.

    Two software technology improvements are solving this problem, though. Web servers have phased in implementations of HTTP listeners based on Java NIO. This style of NIO makes it possible to handle a vast number of socket connections with a small thread pool. The other improvement is an asynchronous servlet programming model. This latter has taken longer to come about. Tomcat 6 had an async servlet, but only half-baked. Tomcat 7 is implementing full Servlet 3.0 standard.

    Jetty went a different way with continuations. All of these make it possible to scale to 20K Comet connections per server.

  2. Jerod Says:

    Hey Roger!

    I agree completely; we (at Frozen Mountain) are have a bit of a gift in that area. IIS, when configured properly (and if you write your application to take advantage of it, like WebSync) scales very well; our testing hit 30k concurrent on a box from Best Buy with 3 gig of RAM and 3 cores.

    Once you get past that though, the end result is similar whether on Java or .NET - you’ve got a highly scalable, standards-compliant messaging hub that works over plain old HTTP - the possibilities are endless!

  3. Jose Maria Arranz Says:

    This has been discussed before in CometDaily

    I haven’t found any test with data probing that NIO is more scalable than IO, in my opinion they are basically the same in scalability because both are basically doing the same.

    - IO needs more memory (stacks of threads)

    - NIO can be problematic if some request is executing slowly because all other clients associated to the same dispatching thread are stalled (because a NIO thread is a software thread not a hardware thread able to grant or relinquish CPU to software threads).

Copyright 2015 Comet Daily, LLC. All Rights Reserved