Comet implementation in IIS is a challenging task as Web servers are not built for maintaining live connections. COMET as everyone would know is the technology for sending live updates (or server push) to the listening clients. The web servers are built as a request-response servers and not as a persistent updaters.
In our case, we had a requirement to support a JMS platform ActiveMQ. Our JMS platform has all the live updates, but this needs to be securely pushed to the client. A clear disclaimer is that, this is a very simple implementation and not yet suitable for Enterprise level Live updates.
Sometimes we can choose to use other external servers to handle such connections, but this becomes a problem in the internet scenario due to firewall restrictions. Because the external servers will be listening in a port which is different than 80 and most of the firewall softwares would block ports other than port 80. We can also explore another option of hosting the live update server on another server and access the updates via cross-domain updates, but this requires another server.
This leaves us with enabling our software for live update with IHttpAsyncHandler which is naturally supported by IIS for asynchronous replies in place of IHttpHandler. There are other third party providers like WebSync, PokeIn and Lightstreamer which offer commercial products. Most of them support only this IHttpAsyncHandler based live updates only.
I think there are numerous articles floating in the internet about IHttpAsyncHandler’s capabilities. Briefly, this IHttpAsyncHandler has the capability to respond to a client asynchronously (few seconds after the request is received). This makes it the right candidate for clients to issue a subscribe request and return to doing their work. FlyComet uses the same approach to achieve this.
JMS is a standard called Java Messaging Service which is a part of J2EE specification and is implemented by many J2EE application servers like JBOSS, Apache Geramnino etc., and stand-alone products like ActiveMQ, RabbitMQ. For our article, we’ll use ActiveMQ which is an industry standard product.
Components of FlyComet:
FlyComet has 6 components to achieve our objective.
This is the entry point for the whole COMET implementation. This implements the IHttpAyncHandler and overrides the BeginProcessRequest and EndProcessRequest functions.
This class maintains the state of the request, the HttpContext for the request and address of the call back handler for calling back once the update is ready.
This class is responsible for connecting to Active MQ and listening for updates from the ActiveMQ. This is a static class which gets initialized when the IIS web site is started. This keeps listening for updates and categorizes the pending updates for every subscriber. FlyComet uses the NonDurableTopicSubscriber as explained in the article publish subscribe in c#.
This class has a ProcessRequest function which is invoked with a thread. After a connect & subscribe request is received, the client keeps polling for any pending and new messages.
This is the class in whose structure the data is expected to arrive. The messages are received in JSON format.
This is the data which is pushed to the clients in JSON format.
Download the Flycomet project and the above sample from FlyComet Codeplex site.