Laharsub: a message server for real time web applications

Phil, I really don't have to imagine willing to turn down the volume on a 4 year old's laptop, I just need to reflect on the past day ;). Remote device control is in fact one of the scenarios I consider in scope for Laharsub.

I would love to see your application. Let me know if/when it is available.

I am building a learning environment for children where there will be interactation between students (eg. playing multi-player games and other activities together). The tech environment is hosted Windows VPS/Asp.NET, Silverlight & WPF click-once apps on the client. There are other uses for push - I don't know whether you have children: Imagine sitting at your PC and remotely being able to turn down the volume on a 4 year old's laptop..

I thought your best explanation of scalability/performance rationale was articulated here (which I only discovered after I made my last comment): http://laharsub.codeplex.com/Thread/View.aspx?ThreadId=229166

I too am starting to think hybrid short/long polling may prevail.

Phil,

bandwidth usage matters in particular in deployment environments where one pays for usage, like Windows Azure (http://www.microsoft.com/windowsazure/offers/popup/popup.aspx?lang=en&locale=en-US&offer=MS-AZR-0003P) or Amazon EC2 (http://aws.amazon.com/ec2/pricing/). In such environments the long polling benefit over short polling can be easily quantifed in terms of savings.

I am curious what application you are building? I agree minimizing latency is not always a priority, and the definition of "good enough" is application specific.

You are right IE 7 and below have a 2 connection limit by default, just as some of the older browsers from other brands. Your target audience and the software they run is definately a consideration when choosing between long and short polling. I believe Laharsub can be reasonably easily modified to gracefully switch down to short polling if necessary, I added this feature to the product backlog: http://laharsub.codeplex.com/wikipage?title=Future%20plans.

Thank you for your suggestions regarding "target audience". I will work on a better pitch. As for benefits for the individual developer, if a publish\subscrive pattern is what you need, coming up with your own implementation and stabilizing it takes time, even it is based on something as simple as short polling. In addition or providing a solution for multiple client technologies, Laharsub will also provide a uniform programming model over several protocols in the future (websockets coming up).

Regarding scalability and performance numbes of the PollingDuplexHttpBinding, the best data I can offer is at http://tomasz.janczuk.org/2009/08/performance-of-http-polling-duplex.html.

Thomasz,

Thanks for the clarification re: push subscription - clearly I misunderstood what you meant.

Re: short polling inadequacies: I'm struggling to think of a real-world example where bandwidth would be a problem (assuming small poll packets) given the huge upload/download limits that modern internet users are demanding from their ISPs.

Regarding latency: I love the idea of near zero latency, I want an excuse to use Laharsub - but it's more "nice to have" than compulsory.

Re: connection quota's: Isn't IE 7.0 and below limited to two connections? We engineers always use the latest browsers but the rest of the world don't always share our zest for new stuff.

My suggestion re Target audience/marketing is this: Identify the situations where Laharsub will deliver clear benefits over both short polling and PollingDuplexHttpBinding.

eg. When does PollingDuplexHttpBinding stop scaling?

Re: "...will substantially shorten your development time": Sounds wonderful. Details please.

Phil,

thank you for your comments.

I have changed the "push subscription" description above to better explain what I mean: the Laharsub server initiating a connection to a subscriber to deliver a notification. Since Laharsub mostly targets web clients, such feature would not be useful since web clients are not directly addressable. Such functionality may be helpful for integrating with other backend systems in the future.

There is clearly a trade off between short and long polling. Short polling is easier to scale out and implement on the client, but it consumes more bandwidth and offers worse latency than long polling. Long polling offers much better latency than short polling and preserves bandwidth, but is effectively uses one TCP connection at any time and is more difficult to scale out. Laharsub offers all the benefits of long polling (and going forward websockets), while taking care of the protocol implementation complexities both on the client and the server. Connection use remains a trade off one needs to make when choosing between short polling and Laharsub, but the issue is not as apparent in modern browsers that have an increased connection quota (8 is typical).

Regarding Campfire, I used it as an example of a scenario rather than as a reference to a particular protocol choice. The distinction between web chat, wiki collaboration, or other forms of document collaboration is rather fluent, and latency requirements may differ depending on a particular application. Wiki collaboration may work just fine with a 2s latency, while web chat would really provide sub-prime experience with that latency.

I have added a "Target audience" section to clarify who I think may benefit from using Laharsub and how. Now bear in mind I am an engineer, this section could use someone with more marketing experience. Suggestions welcome.

I think this design document is excellent, but another heading would be good: "Typical Users". This would be a list of stereotypical users of the Laharsub platform, who they are, who they work for, what experience they have, their deployment scenarios, what they are trying to achieve.

Well I didn't know what Campfire was so I looked it up and suppose you're talking about www.campfirenow.com?

So then for fun I googled "Campfire comet" and got people saying that Campfire uses short polling not Comet!
http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications

When asked why the answer was "we wanted agile" which I presume means they wanted it quick and simple. (btw. One of the issues raised in that discussion is that long polling hijacks one of the two open connections available to a browser - is that a big deal?)

If Campfire uses simple polling any monkey can code, it looks like the only candidate in your list of scenarios that needs Laharsub is "Multiplayer web games" (where presumably people won't accept a 2 second lag as they try to get out of the way of oncoming monsters).

Re:
>> Push subscription model (clients are not addressable)

I presume you mean you can send a message to a topic (eg. "message for everyone in the chat room") but not to an individual user ("whisper something to a friend").

I suspect that both topic and individual messenging will be called for, though I suppose a topic could be created for each user.

You've probably made the right choice here.

I love the layout of this document, especially "What we don't care about".

There is a lot confusion when trying to understand someone's intentions and this simple statement does so much to clarify.