First, let's talk about the problem that Polling Duplex solves. Polling Duplex is a special WCF channel that is available only to Silverlight. When your Silverlight application needs data from the server, it needs it in one of two different ways:

• On-Demand : Something in your application happens and it needs data. It specifically asks the server for that data upon encountering the need for that data. This is what most people think of as "pull" data.
• Push : This is where you need data sent to your application as the data becomes available and the overhead of setting up a timer on which you pull (or poll) for data is unacceptable to you. The main reason why this is unacceptable to people is because there may be frequent periods of time where the pull/poll has no data, which means your app will be occupying server resources every X seconds even when there is nothing to do.

The Polling Duplex channel is a solution to the push problem. It allows server-side code to "push" data down to the Silverlight application. Under the hood the channel is using "Comet"-style tricks keeping HTTP connections open in much the same way that the Gmail application is able to receive push notifications of new mail.

This is great and the programming model for communicating with the Polling Duplex channel is brain-dead simple. It does NOT get any easier to implement push data to a RIA - not in Flash, not in AIR, and certainly not in JavaFX. The problem is that this solution doesn't scale. On the server side, for each concurrently running Silverlight application (so probably one per concurrent user), there is a full live socket being consumed that will not be relinquished until the client disconnects/closes their browser.

Worse is that the Polling Duplex channel defaults to only allowing 10 concurrent connections. You can programmatically tweak that by configuring the throttling behavior (as shown in this blog post here ).Even if you do increase the amount of concurrent connections allowed, those concurrent connections are still going to beat the crap out of your servers and good luck getting that to work seamlessly in a cluster/farm scenario.

If you need more than a handful of concurrent users and you want to do it in a way that scales and doesn't abuse your servers, then I highly, highly recommend looking into some kind of messaging / open gateway server. The only one I've played with for more than a few minutes is Kaazing , but I have nothing but good things to say about it. It's based on HTML 5 Web Sockets so you will be in good shape for the future.

Web Sockets are freaking awesome but that's a topic for another post.

Bottom line here is that if you're looking at any of the Polling Duplex samples online like the "stock ticker" sample, don't be fooled. It looks easy, but especially in the financial industry, you need high concurrency, high speed, low latency - and you're not going to get that with the polling duplex channel. If there was one place where I see it fitting is in the creation of intranet applications internal to an organization with a limited number of concurrent users.

Read the original blog entry...