Comet implementation for ASP.NET?

I've been looking at ways to implement gmail-like messaging inside a browser, and arrived at the Comet concept. However, I haven't been able to find a good .NET implementation that allows me to do this within IIS (our application is written in ASP.NET 2.0).

The solutions I found (or could think of, for that matter) require leaving a running thread per user - so that it could return a response to him once he gets a message. This doesn't scale at all, of course.

So my question is - do you know of an ASP.NET implementation for Comet that works in a different way? Is that even possible with IIS?

Comet is challenging to scale with IIS because of comet's persistent connectivity, but there is a team looking at Comet scenarios now. Also look at Aaron Lerch's blog as I believe he's done some early Comet work in ASP.NET.

WebSync is a standards-compliant scalable Comet server that integrates directly into the IIS/.NET pipeline. It's also available on demand as a hosted service.

It officially supports up to 20,000 concurrent client connections per server node, but individual tests have seen it go as high as 50,000. Message throughput is optimal around the 1,000-5,000 concurrent clients mark, with messages delivered as high as 300,000 per second from a single node.

It includes client-side support for JavaScript, .NET/Mono, iOS, Mac OS X, Java, Silverlight, Windows Phone, Windows Runtime, and .NET Compact, with server-side support for .NET/Mono and PHP.

Clustering is supported using either SQL Server or Azure Caching out of the box, but custom providers can be written for just about anything (Redis, NCache).

Disclaimer: I work for the company that develops this product.

I recently wrote a [simple example of a Long Polling Chat Server][1] using MVC 3 Async Controllers based on a [great article by Clay Lenhart][2]

You can use the [example on a AppHarbor deployment][3] I set up based on the source from the BitBucket project.

Also, more information available from my [blog post explaining the project][4].

[1]: https://bitbucket.org/jacob4u2/mvcchatsite/src "MVC Chat Site Source On BitBucket" [2]: http://clay.lenharts.net/blog/2010/10/19/websockets-is-cool-but-what-can-you-do-today/ [3]: http://mvcchatsite.apphb.com [4]: http://jacob4u2.posterous.com/mvc-3-long-polling-comet-chat-example

Actually there are many choices to create ajax supported website with ASP.NET but honestly, PokeIn is the easiest way to create an comet ajax supported web application. It has saved one of the projects of my company.

You might also look at the Kaazing Enterprise Gateway which has made a production release of their webSocket [HTML5] gateway which supersedes the comet way completely and enables full-duplex connections between browsers & application servers.

You might also look at Light Streamer Demos

I once used a chat site long ago that utilized a custom built http streaming server. I actually reproduced that software at one point out of sheer curiosity, and it's easy enough to do, I think. I would never try to implement a similar type of "infinite request" in IIS, especially in ASP.NET, because the requests tie up a thread pool thread (or IO thread, if asynchronous handlers are used) indefinitely, which means you can only handle so much per server as your thread pool configuration allows.

If I had a strong legitimate need for such functionality, I'd honestly write a custom http server for it.

I know that doesn't really answer your question, but I thought the input might be relevant.

The WS-I group published something called "Reliable Secure Profile" that has a Glass Fish and .NET implementation that apparently inter-operate well.

With any luck there is a Javascript implementation out there as well.

There is also a Silverlight implementation that uses HTTP Duplex. You can connect javascript to the Silverlight object to get callbacks when a push occurs.

There are also commercial paid versions as well.

I think the Comet approach isn't really scalable unless you are prepared to expand the web farm horizontally (by adding more web servers to the mix). The way it works is that it leaves a TCP connection open per user session, just so the server can push stuff into that connection from time to time to immediately inform the user of a change or activity.