Willy-Peter Schaub's Cave of Chamomile Simplicity

WCF/Indigo … surviving the port warp from BETA-1 … log #6: Duplex Communication

Another hurdle to cross is duplex communication. While I will document the problem and the resolution, I am not as yet sure what actually changed from BETA-1 where the resolution was not required. I will update this post as soon as I have figured out what has changed under the bonnet.

Scenario:

You have a contract with a callback interface, i.e. a duplex communication, for example:

[ServiceContract(CallbackContract = typeof(ICalculationResult), Namespace = "http://www.bbd.co.za/IndigoCompanionSolution")]
    public interface ICalculationRequest
    {
        /// <summary>
        /// Calculation request, passing calculation request which defines values and operation
        /// </summary>
        /// <param name="request"></param>
        [OperationContract(IsOneWay = true)]
        void Calculate ( CalculationRequest request );

        /// <summary>
        /// Debugging ping of service method
        /// </summary>
        /// <param name="caller">caller id</param>
        /// <returns>Hello + caller id</returns>
        [OperationContract(IsOneWay = false)]
        string Ping(string caller);
    }

Issue:

In BETA-1 we created the channel to the service, hosted in IIS, implementing the contract and the consumer and service chatted happily ever after. With WinFX BETA-2, on XP ... it worked on Windows 2003 for some strange reason ... the same code, same configuration, fails with the error "HTTP could not register UTL http://+;80/Temporary_Listen_Addresses/GUID-OMITTED/ because TCP port 80 is being used by another application".

Feedback from Microsoft:

"The behavior you are witnessing is to be expected.  In a duplex exchange, the service will open an HTTP connection back to the client, and, by default, the base address where the client will be listening will be the same as the base address where the service is listening.  Hence, in your case, the client will attempt to bind to port 80, and will fail in that endeavor if IIS is listening on its default port." 

Resolution:

Add the attribute highlighted in red to the configuration file specifying the callback port to avoid the obvious invasion and clash around port 80:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.serviceModel>
    <client>
      <endpoint
          name="WSDualHttpBinding_ICalculationRequest"
          address="http://localhost/CalculationService/CalculationService.svc"
          bindingConfiguration="WSDualHttpBinding_ICalculationRequest"
          binding="wsDualHttpBinding" contract="ICalculationRequest" />
    </client>
    <bindings>
      <wsDualHttpBinding>
        <binding name="WSDualHttpBinding_ICalculationRequest"
                 clientBaseAddress="http://localhost:8099/CalculationClient/">
        </binding>
      </wsDualHttpBinding>
    </bindings>
  </system.serviceModel>
</configuration>

Unresolved to date:

While it is "expected" ...

1. Why did it work in BETA-1? What has changed under the bonnet?
2. Why did it work on Windows 2003, same code, same configuration ... breaking only on XP?