Question

Would using WSDualHttpBinding for duplex callbacks work in real-world scenarios? Say, I have a .NET application that uses a random port, would the service be able to resolve the client’s base addresses and port for callbacks?

Answer 1

A complete answer to your question depends on the “real-world scenario” being either an Intranet or an Internet scenario. Although WSDualHttpBinding works in both scenarios there are specifics to be aware of:

Intranet

WSDualHttpBinding will work with your .NET application using a preconfigured custom port in an Intranet scenario and “Yes” the service will be able to resolve the client’s base addresses and port for callbacks: exactly how is explained below. The reason it’s explained below is that WSDualHttpBinding is primarily designed to be used over the Internet.

Duplex callbacks in an Intranet scenario when you can use WCF on both client and server is best achieved by using NetTcpBinding or NetNamedPipeBinding. These bindings use TCP and ICP respectively as transport (rather than HTTP) and a custom binary encoding which is why WCF is required on both sides. For calls-back to the client the same channel used to connect to the Service via the Binding is re-used without requiring a new port to be opened.

Internet

In an Internet scenario valid HTTP requests and responses only travel in one direction, HTTP is designed as a one-way protocol. When using the WSDualHttpBinding WCF therefore creates a seperate HTTP channel for callbacks. In answer to your second question: the destination address for this call-back to the client is composed of the client machine hostname and port 80 by default. If the client is a development machine for example and has IIS installed, port 80 will be exclusively reserved in some scenarios which will cause conflicts with your prototype application. This is what this blog post presents a solution for and what the ClientBaseAddress property is designed to help with. Regardless of which port you go with – the default or a custom one, you must ensure all firewalls and routers on both sides are configured correctly to allow both the outgoing channel and the seperate callback channel to be established.

A .NET application can also denote a Silverlight application. Because of the fact that a Silverlight application running in a browser cannot accept new incoming HTTP connections, WSDualHttpBinding with it’s seperate back channel will not work. Hence PollingDuplexHttpBinding was created firstly in Silverlight 2 which can be thought of as a clever ‘trick’ to get around the fact that HTTP is unidirectional by keeping the request channel open for a long time (long polling) and using it as a back channel for calls back to the client. This has a number of implications on both the client and server side particularly relevant to scaling, for more detail please see this post from my blog.

With an idea of your particular “real-world scenario” and your use-cases hopefully this will help you work out the correct binding to use for duplex callbacks.