Sep 30, 2010 at 3:15 PM
Edited Sep 30, 2010 at 4:28 PM

I am building an online game and chat server with silverlight clients, hosted in Azure for about 2000 clients.

I am using the 'standard way' that Tomasz Janczuk explain in 'Pub/sub sample using HTTP polling duplex WCF channel' and in 'Duplex communication with WCF on Silverlight TV' :
- reference to ServiceModel.PollingDuplex.dll
- in the server I have the xxxxService.svc file and a Web.config file
- in the Silverlight client I add a Service Reference to build the xxxxServiceProxy

Do you think using Laharsub is the best approach? Have Laharsub less problems, a better performance and/or less delivery latency?


Oct 4, 2010 at 12:51 AM
Edited Oct 4, 2010 at 12:56 AM



There is a number of aspects to consider when choosing between Silverlight's PollingDuplexHttpBinding and Laharsub, among others:

PollingDuplexHttpBinding Laharsub
Official Silverlight component supported by Microsoft Open source component. No official support, but you can modify the code as you see fit.
Duplex communication capability, but no pub\sub pattern support in Silverlight itself Built from the ground up specifically to support the pub\sub pattern.
Both PollingDuplexHttpBinding and Laharsub are based on HTTP long polling protocol pattern with support for multiplexing multiple messages on the response. You can expect similar performance characteristics in terms of message throughput and connection use.
Not easy to scale-out beyond a single backend server due to in-memory state maintained at the protocol level. One way to scale out is described at, but it is limited to the low performance SingleMessagePerPoll mode. Built from the ground up with scale-out as a design principle. Ships with a simple in-memory pub\sub implementation, but you can plug in a custom extension that supports pub\sub pattern scale-out.
Based on .NET Framing protocol with only available client implementation in Silverlight. Based on open web protocols (HTTP, multipart/mixed MIME) with variety of client implementations (Silverlight, .NET, JavaScript - jQuery).
Depending on the specifics of your messaging patterns and message sizes, may or may not scale to 2000 concurrent clients on a single machine. Check out some performance numbers at Bottom line, do your own measurements given the messaging patterns of your application. Performance numbers are not available as of right now (in fact, the goal of the next release is to improve performance and generate performance metrics). However, one of the design principles was for the solution to support high scale-in through the use of asynchronous processing throughout.

I hope this helps.


Oct 5, 2010 at 9:04 AM
Edited Oct 5, 2010 at 11:01 AM

Thanks Tomek for your answer.

Laharsub looks the better choice.
I'll use Laharsub for my project, with a custom extension with no in-memory state. This because we need to work in Azure without interruptions even when backend recycling occurs.

The online game has a slow rate, about one message every 15 seconds.
According the performance numbers at I can assume that one single machine will be enough for 2000 concurrent clients.


Oct 7, 2010 at 3:57 AM


sounds good, I am curious about the approach you will take when scaling out in Azure. Do you have any thoughts on the backend technology you want to use to achieve scale-out?

As for Laharsub, I am planning to make another official release of it within days. It will include several performance and stability fixes and improvements compared to the current release. In the meantime I suggest you pick up the latest code from the dev branch and compile it yourself rather than using the latest binary release.


Oct 14, 2010 at 2:06 PM


I am planning to follow the way described at, but really I don't know enough Azure nor Laharsub at this moment.

Thanks, Cristian

Oct 15, 2010 at 5:56 AM


My blog post at is related to scaling out the backend of Silverlight's HTTP long polling service, not the Laharsub service from this project. Laharsub has a built-in extensibility point for plugging in pub\sub backend implementations that support scale out.

You may want to check out the performance measurements of the Laharsub service I just recently published at Given your number of concurrent clients and messaging frequency you may be able to support your scenario without scaling out the backend at all, with the Laharsub service on a single backend machine.