Friday, October 30th, 2009

WebSync: Comet for IIS

Category: Comet

>The following is a guest post. If you have something to say to the Ajaxian community, please feel free to either link us to your work, or give us a guest posting that goes into detail! Contact us.

My name is Jerod Venema, and I’m excited to write to you about our new Comet server for the Microsoft stack – WebSync. It is written in 100% managed C#, and uses IIS to reach incredibly high user concurrency. Despite being written in C#, we’ve made it easy to integrate other languages as well by pre-building client libraries and allowing generic HTTP requests to send messages.

There are many challenges in getting a Comet server to operate efficiently in any language, and the .NET environment delivers its own set of unique challenges. One of the biggest challenges we faced was how to make IIS “play nice” when scaling to tens of thousands of concurrent HTTP connections and message transactions. A great deal of time was spent minimizing the memory footprint (even to the point of lazy object construction), optimizing libraries, and digging through pages of profiler results. Multi-threading reared its ugly (but powerful) head on more than one occasion as we sought to take maximum advantage of multiple CPU cores while keeping locking and concurrency issues to a minimum. We even ended up writing a new lock-free data structure similar to a linked queue that allows us to perform multiple-writer add/remove operations – very helpful when dealing with large lists of clients and messages. Once all was said and done, we tested on a $500 Acer desktop and saw over 30,000 concurrent users and 25,000 messages per second. (We were pretty pumped when we saw some of those numbers coming through!)

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.

We also spent some time on making it easy to integrate into non-browser applications. One of the really neat features is the ability to publish data via a simple GET/POST request, so it can integrate into any application that can make a web request, regardless of the language. If you’re writing in PHP or .NET, we’ve made life even easier by writing publishers that wrap up the creation and invocation of the web request into single method calls.

Oh, and we’ve got a hosted version too (WebSync On-Demand), so people with smaller sites who don’t want the cost of hosting their own Comet server can still get all the benefits of a full Comet solution. For the On-Demand solution we’ve also implemented request proxing, which allows developers to direct the low-impact publish and subscribe requests to their server first, so they can pre-process any incoming messages (to add authentication, save messages to a database, etc). And again, for PHP or .NET users, it’s a one-liner to implement.

Anyway, it’s a pretty neat product, easy to get started with, and as I said, we’re pretty excited and proud of it, so check it out including demos or tutorials and let us know what you think!

Related Content:

Posted by Dion Almaer at 6:02 am
9 Comments

+++--
3.9 rating from 195 votes

9 Comments »

Comments feed TrackBack URI

Dojo is under 30k after gzipping, which is about the same size a Prototype.

Comment by Les — October 30, 2009

My biggest problem with implementing Comet has not been the technology itself, but grappling with the ‘temporal’ property. It seems to break some of the current conventions of the web in a big way. I should send a link to someone and be assured that what I see resembles what they see. Sites seem to be dealing with this by implementing a playback feature coupled a link, such as Etherpad’s time slider and “download as.” I’m not entirely confident that is the best way to go about it, or at least I’ve not figured out an elegant way of preventing the application from turning into a massive version control system.

Comment by geoffreys — October 30, 2009

This is nice, but it’s just another closed source procuct. Hardely in the spirit of open web.

Leave the advertising on the side bars. This doesn’t deserve an article.

Comment by pnewhook — October 30, 2009

Just because it’s closed source doesn’t mean that it’s not ajax. I think this article does have a place on ajaxian, and that this is an interesting product.

Comment by Joeri — October 30, 2009

I disagree, but then I subscribe to the spirit of productivity and quality. Great chronology of challenges and solutions – very robust – I’m definitely checking this out!

Comment by smartairguy — October 30, 2009

…clarification – disagree with pnewhook

Comment by smartairguy — October 30, 2009

@geoffreys: a collaborative editor like Etherpad (your example) running inside a browser is first of all an editor. Do we expect desktop editors to save snapshots of every single change made to the text? Usually not, even this feature exists to some degree in some editors and word processors (automatic saves and versioning). Should web based editors be different beasts and be subjected to different requirements? IMHO the answer is no. Furthermore there are desktop based collaborative editors so their web based brothers and sisters are not so special.

To recap my point: there are many kinds of web based applications and for some applications the resource they work on changes at such a speed that it doesn’t make sense for that URL to exist. In the case of an editor a static resource is created when the document is saved, an URL may be generated at that time and the document can be stored in a versioning system and be accessible forever.

Comment by pmontrasio — October 31, 2009

Is there any extension for Apache for the same purpose ?

Comment by gabrielricci — November 4, 2009

Excellent thanks

Comment by Aphrodisiac — January 22, 2010

Leave a comment

You must be logged in to post a comment.