This project is read-only.

Goals and requirements


The scenarios Laharsub project aspires to address include:
  • Chat/customer support
  • Stock quote updates/breaking news
  • Multiplayer web games
  • Campfire/live blog (real time wiki collaboration)
  • Google docs/Office Live (real time document collaboration)
  • Remote device control/monitoring

Target audience

  • If you are an individual developer implementing one of the web application types listed above, Laharsub is a flexible messaging solution that will substantially shorten your development time while allowing deployment in a variety of environments (self-host, Windows Azure, Amazon EC2).
  • If you are an ISV developing a web application that requires a scalable publish\subscribe solution, Laharsub provides you with a robust protocol optimized for the web while allowing scale-out to a large number of users in a variety of deployment environments. Open source license allows you to customize the software to the needs of your specific application.


What we care about:
  • JavaScript and Silverlight as a client
  • HTTP polling and Websockets as two primary protocols
  • Browser TCP connection use minimization (single HTTP request with multiple subscriptions)
  • Unrestricted message content type
  • Low latency between publish and delivery (check the performance results)
  • Scalable to tens of thousands subscribers per topic
  • Authorization
  • Configurable message durability (e.g. TTL based)
  • Ability to self-host, deploy in Windows Azure, and in Amazon EC2
What we don’t care about:
  • Transactions
  • Formal delivery guarantees
  • Push subscription model (i.e. the server initiating a connection to a subscriber in order to deliver a notification; web clients are not addressable)
  • Durable subscriptions (server side cursors, subscription identity)
We don’t know yet if we care about:
  • Message size restrictions
  • Integrity & confidentiality
  • Shared hosting

Last edited Oct 31, 2010 at 12:04 AM by tjanczuk, version 5


tjanczuk Nov 5, 2010 at 4:59 AM 
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.

PhilBachmann Nov 1, 2010 at 7:24 AM 
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):

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

tjanczuk Nov 1, 2010 at 1:04 AM 

bandwidth usage matters in particular in deployment environments where one pays for usage, like Windows Azure ( or Amazon EC2 ( 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:

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

PhilBachmann Oct 31, 2010 at 7:31 AM 

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.

tjanczuk Oct 31, 2010 at 12:19 AM 

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.

PhilBachmann Oct 18, 2010 at 2:13 AM 
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.

PhilBachmann Oct 16, 2010 at 8:27 PM 
Well I didn't know what Campfire was so I looked it up and suppose you're talking about

So then for fun I googled "Campfire comet" and got people saying that Campfire uses short polling not Comet!

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).

PhilBachmann Oct 16, 2010 at 7:14 PM 
>> 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.

PhilBachmann Oct 15, 2010 at 9:51 PM 
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.