I was recently playing around with WCF services, seeing what I could learn about duplex communications. I came up with the idea to build a demo application that would connect a HTML5 “audience” website with a Silverlight 4 “presentation” application. The specific idea was to have a GrokTalk audience use their iPads to send messages from Safari with AJAX calls to a WCF service, which would, in turn, forward data to a Silverlight application that would display the results. In turn, SL4 would return messages through WCF back to the HTML5 web clients, updating the browser with refreshed information.
I'm between projects. What the heck?
Well, that was the original, albeit admittedly contrived, idea. As it turns out, this original architecture did not pass the POC phase. While exploring the idea, however, I learned a bit about the current strengths and limitations of WCF's PollingDuplex binding and will summarize what I discovered here.
With the release of Silverlight 4, a new mode, called MultipleMessagesPerPoll, was added to PollingDuplex binding. For previous versions of Silverlight, duplex communications between WCF and Silverlight were achieved by having the client poll the server, and the server using its response as an opportunity to send data back to the client. One limitation of this initial PollingDuplex implementation is that the client cannot respond to the incoming server responses. A more severe limitation is that the server could only send one message per response. With the server only able to send one response per poll cycle, the queue for outgoing messages to the client could become quickly backlogged, even in a matter of a few seconds.
With Silverlight 4, PollingDuplex binding now has the MultipleMessagesPerPoll mode available. Now when WCF receives a poll request from the client, it is able to send multiple messages to the client using HTTP chunking. In fact, WCF attempts to hold open the response connection for as long as it can, until it times out or it experiences interference from the network. As soon as the connection is lost, the client sends a new request and the process repeats itself. Yavor Georgiev provides a more detailed explanation here.
While the MultipleMessagesPerPoll mode is a definite improvement over the original PollingDuplex implementation, it turns out to have some limitations. First, for the non-server operating system (XP/Vista/Windows7), WCF will either reject or queue new client requests after the first 10 simultaneous connection are made. For server operating systems, the picture is a bit brighter. While IIS6 allows each long running connection to consume a thread from the pool (placing a serious limitations on the number of possible clients), with IIS7 on Windows Server 2008, asynchronous connections do not require their own thread, allowing for thousands of concurrent connections.
A more serious problem, however, then surfaced. A known issue with the current release of Silverlight causes faults in the PollingDuplex client channel:
This behavior is a regression introduced in SL4 GDR1 and is visible when the following conditions are put together:
-Use of PollingDuplex
-DuplexMode is set to MultipleMessagesPerPoll
-Http stack is set to BrowserHttpWebRequest (the default stack)
-Client browser is IE8 with SL4 GDR1 or later runtime
-A poll completes after ServerPollTimeout and there is no content to consume by the client
Should you have all these conditions filled the client channel will fault. The issue will not manifest if you use any other browser.
As luck would have it, this configuration was an exact match to mine. The only available workaround for IE8 currently available is to change the BrowserHttpWebRequest stack to ClientHttp. This change, however, then causes the same channel faults in Chrome 9 and Firefox 3.5. Microsoft states that they are currently working on a fix.
In addition to the limitations with PollingDuplex between Silverlight 4 and WCF, during my POC research, I also discovered a number of blocking issues with using a
Comet programming model between WCF and an AJAX (non-ASP.Net) web site when viewed from iPad's Safari. While true duplex communication is not currently available between AJAX clients and a WCF service, I explored a number of ways to achieve similar results. During my research and discussions with coworkers, HTML5's HTTP WebSockets was suggested as a possible solution. The WebSockets API implements an
onmessage callback for creating a persistent communications between server and client. It's an exciting technology and raises hopes for duplex communications as the HTML5 specification continues to mature and browser support becomes more prevalent. Although WebSockets, as well as other emerging features of HTML5, are currently available with Chrome, Chrome, unfortunately, is not currently available on the iPad.
A final additional finding is that WCF does not provide support for WebSockets, although Glenn Block has
posted that Microsoft is working on an implementation.
That implementation, however, actually uses an embedded Silverlight 4 application that connects to WCF using PollingDuplex for browsers that do not support WebSockets. But in terms of using just AJAX without Silverlight as a fallback, my research did not find a way to communicate with WCF.
Of course, I could create a similar result if I were to make significant changes to my architecture. I could drop the idea of using Safari on the iPad. There are also other technologies available in place of WCF, including Bayeaux, BOSH and JSONRequest -- all being solutions that were outside the scope of my explorations. Some of the problems with WCF PollingDuplex are slated to be fixed in the near future. Additionally, increased HTML5 support across browsers promises to make duplex communication between the browser and server more of a reality instead of a long sought-after dream.
For those who have read this far, I would say, stay tuned. . . . It sounds as some major improvements are on the horizon.