I stumbled upon something that looked so unbelievable that I simply had to try it. Suppose you want to build a browser based application, rich in functionality. These types of apps are increasingly often now called RIA. If it’s going to be .NET based, you’d probably want to make it WPF based (XBAP). Silverlight is a possibility too but let’s say that because there’s no way of having full CLR available you disregard it.

Since the app is already .NET 3.0 because of the WPF, why not use WCF for the network connectivity? Well, there is one problem you can’t overcome – WCF does not run in a partial trust scenario (at least not in the .NET 3.0, 3.5 should partially resolve the issue).

Let’s say that you’d rather use WCF and thus you give up on the XBAP and decide to go with the full blown WPF app, ClickOnce installed.

What you want to have is a simple stocks service - the server will fire the notifications when the price of a particular stock changes and the client will display it somehow, in a table or maybe as a fancy chart. The screenshot to the left shows two WinForms based applications (prototype obviously, real app will use WPF on the client), service and the client that communicate through WCF.

You need a two way channel – subscribe for updates to the server and then later on receive notifications from the server. Because you don’t want to have problems with the firewalls and such, you decide to pick one of the bindings with HTTP based transport. What do you know, there’s one binding in WCF that perfectly describes your needs – it’s called wsDualHttpBinding.

The app works as the screenshot shows, and it’s literally a couple of lines of code. It’s really easy to add transport and/or message security, transactions and whatnot, so what’s the problem?

The problem is the way that wsDualHttpBinding is designed. To support two-way communication, two HTTP connections (so two TCP connections) are used. The problem is that the second one, used to send messages from server to the client, is actually initiated from the server. Why is this a problem? Because client needs to be able to listen on a port, thus you need to have this port open on the firewall!

This makes no sense because one of the primary reasons you chose HTTP based transport is to avoid issues with the firewall. If I did not care about firewalls, I would have chosen TCP based transport like netTcpBinding which also gives me the benefit of using single TCP/IP connection for two-way communication. In fact, if the client had a simple one-way firewall protecting only incoming and not outgoing traffic (Windows XP firewall works like this as do many of the home routers/wireless access points) this would work even better – no need to touch the firewall!

But wait, why does wsDualHttpBinding require two TCP/IP connections? HTTP as a protocol is one-way, but it’s higher level than the TCP/IP, and it certainly was possible to use single TCP/IP connection for a two-way HTTP communication. I can only guess that time and/or resource constraints cut this feature out. Unfortunately, there’s no mention of rectification of this problem in the “Orcas” release.