NetTcpBinding & mexTcpBinding sharing same port throws AddressAlreadyInUseException on upgrade to .net 4.5?

  • Article

 

Do you notice that your WCF NetTcp endpoint sharing port with a mexTcp endpoint fails to activate with a AddressAlreadyInUseException on upgrade to .Net 4.5?

System.ServiceModel.AddressAlreadyInUseException: There is already a listener on IP endpoint 0.0.0.0:[Port#] . This could happen if there is another application already listening on this endpoint or if you have multiple service endpoints in your service host with the same IP endpoint but with incompatible binding configurations. --->

System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress) at

…

Here are some pointers for you to get it fixed.

  • Check if you have explicitly configured listenBackLog or maxConnections property of the NetTcp binding to a .Net 4.0 default of 10 like this:

<netTcpBinding><binding listenBacklog="10" maxConnections="10" >…

  • If so delete these explicitly defined settings on the NetTcp binding and restart the service.

 

Does that resolve your problem? Here is a little bit background about the problem. There are some limitations when it comes to port sharing for TCP endpoints which are documented here under the section "Sharing a port between a service endpoint and a mex endpoint using the NetTcpBinding". If you are sharing port between two TCP endpoints these listenBackLog & maxConnections parameters used by both the endpoints should be the same. If they are different you will run into this issue.

Now, why does that work on .Net 4.0 but not on .Net 4.5?

In .Net 4.0 defaults for these properties are 10. Since the configured values match with the mexTcpEndpoint’s default values it works fine on .Net 4.0

On the other hand, in .Net 4.5 the revised defaults for these properties = 12 * ProcessorCount. Since the configured values (10) does not match with the mexTcpEndpoint’s default values of 12 * ProcessorCount it throws this exception.

If you notice, the 4.5 defaults for these values are definitely higher than 4.0 defaults. So by removing the explicitly configured properties your service will start working fine. Alternatively you can expose the mex endpoint on a different port as described in this post.