There is already a listener on IP endpoint 0.0.0.0:13000. ?? (TCP using WCF)

Question

I'm trying to figure out why the port is being used even after restarting the computer!

System.ServiceModel.AddressAlreadyInUseException: There is already a listener on IP endpoint 0.0.0.0:13000. 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 System.Net.Sockets.Socket.Bind(EndPoint localEP) at System.ServiceModel.Channels.SocketConnectionListener.Listen() --- End of inner exception stack trace --- at System.ServiceModel.Channels.SocketConnectionListener.Listen() at System.ServiceModel.Channels.TracingConnectionListener.Listen() at System.ServiceModel.Channels.ConnectionAcceptor.StartAccepting() at System.ServiceModel.Channels.ExclusiveTcpTransportManager.OnOpen() at System.ServiceModel.Channels.TransportManager.Open(TransportChannelListener channelListener) at System.ServiceModel.Channels.TransportManagerContainer.Open(SelectTransportManagersCallback selectTransportManagerCallback) at System.ServiceModel.Channels.TcpChannelListener`2.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.Communicat ionObject.Open(TimeSpan timeout) at System.ServiceModel.Dispatcher.ChannelDispatcher.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at System.ServiceModel.ServiceHostBase.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at Microsoft.Tools.SvcHost.ServiceHostHelper.OpenService(ServiceInfo info) System.Net.Sockets.SocketException (0x80004005): 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 System.Net.Sockets.Socket.Bind(EndPoint localEP) at System.ServiceModel.Channels.SocketConnectionListener.Listen()

How do you figure out which process is listening to that port (13000)? Netstat shows nothing on that port.

Here's my App.config:

  <system.web>
    <compilation debug="true" />
  </system.web>
  <!-- When deploying the service library project, the content of the config file must be added to the host's 
  app.config file. System.Configuration does not support config files for libraries. -->
  <system.serviceModel>
    <services>
      <service name="SomeTarget.SomeTargetService">
        <endpoint address="" binding="customBinding" bindingConfiguration="NetTcpBinding"
          contract="SomeTarget.ISomeTargetService">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexTcpBinding" bindingConfiguration=""
          contract="IMetadataExchange" />
        <host>
          <baseAddresses>
            <add baseAddress="net.tcp://localhost:13000" />
          </baseAddresses>
        </host>
      </service>
    </services>

    <bindings>
      <customBinding>
        <binding name="NetTcpBinding" sendTimeout="00:05:00" closeTimeout="00:00:30" openTimeout="00:00:30" receiveTimeout="00:05:00">
          <transactionFlow />
          <binaryMessageEncoding />
          <windowsStreamSecurity protectionLevel="None" />
          <tcpTransport maxBufferPoolSize="524288"
                        maxReceivedMessageSize="1024"
                        maxBufferSize="1024" >
            <connectionPoolSettings groupName="default" leaseTimeout="00:05:00"
                                    idleTimeout="00:02:00" maxOutboundConnectionsPerEndpoint="20" />
          </tcpTransport>
        </binding>
      </customBinding>
    </bindings>

    <behaviors>
      <serviceBehaviors>
        <behavior name="">
          <serviceMetadata httpGetEnabled="false" httpsGetEnabled="false" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

</configuration>

Answer 1

I experienced this issue after installing .Net 4.5 and am posting a solution here to help others if they stumble into it. @berkayk's answer above worked (exposing the mex on a different port), but I needed to expose both endpoints through the same port.

Assume you have two endpoints, one using netTcpBinding and one using mexTcpBinding. When using the default bindings, some of the defaults are calculated using OSEnvironmentHelper.ProcessorCount instead of hard coded values as they were in .Net 4.0.

In my case, when using a named netTcpBinding bindingConfiguration, the value supplied for the MaxConnections property was 20. Setting the MaxConnections property on the NetTcpBinding also sets it's TcpTransportBindingElement's MaxPendingConnections property and the TcpTransport's ConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint property to the same value.

When not using a named netTcpBinding bindingConfiguration, and only using the default, the MaxPendingConnections property was calculated by using the following algorithm:

 return (12 * OSEnvironmentHelper.ProcessorCount);

The mexTcpBinding's transport also calculated it's MaxPendingConnections property using the above algorithm, so when neither is using a named bindingConfiguration the default values match and there is no issue.

When using a named netTcpBinding bindingConfiguration, the transport's MaxPendingConnections was 20, and the mexTcpBinding's transport's MaxPendingConnections was, on my machine, 96. The difference in values for the MaxPendingConnections between these two endpoints sharing the same port is incompatible.

I also found that this issue occurred with the ListenBacklog set as well. (I do not know of all the possible conflicting values that may exist.)

To resolve the issue, you can create a custom binding for mex that matches the named bindingConfiguration for netTcpBinding. Example below:

<endpoint binding="netTcpBinding" bindingConfiguration="TestNetTcpBinding"
      contract="YourContract" />
<endpoint address="mex" binding="customBinding" bindingConfiguration="TestMexBinding"
      contract="IMetadataExchange" />

<bindings>
<customBinding>
<binding name="TestMexBinding">
<tcpTransport maxPendingConnections="20" listenBacklog="20">                   
<connectionPoolSettings groupName="default"  maxOutboundConnectionsPerEndpoint="20" />
</tcpTransport>
</binding>
</customBinding>
<netTcpBinding>
<binding name="TestNetTcpBinding" listenBacklog="20" maxConnections="20"/>
</netTcpBinding>
</bindings>

Or, you can not specify any values that are calculated (like maxConnections and listenBacklog) and accept the defaults (note that MaxOutboundConnectionsPerEndpoint will still retain the default value of 10 as it is not calculated in the same way that the MaxPendingConnections property is):

<binding name="TestNetTcpBinding" ...someOtherProperties except listenBacklog and maxConnections/>

Note: The issue is described here: http://msdn.microsoft.com/en-us/library/aa702636.aspx , but the only solution given is to expose the mex on a different port. Below are some screenshots in reflector that show the difference between .net 4.0 and 4.5 when calculating the MaxPendingConnections defaults:

Answer 2

I am having the same problem after I installed Visual Studio 2012 to evaluate. It seems that normal service and mex service cannot share same port as it used to be in .NET 4.0 with same config file (I dont know why, there must be a reason). Briefly I have my service client references on a different assembly and wpf application on a different assembly. I published mex with different port as this

<service name="X.XService.XService" behaviorConfiguration="myServiceBehavior">
            <endpoint address="" binding="netTcpBinding" bindingConfiguration="NetTcpBinding_IXService" contract="X.XService.IXService">
                <identity>
                    <dns value="localhost" />
                </identity>
            </endpoint>
            <endpoint address="net.tcp://localhost:9103/XService/mex" binding="mexTcpBinding" bindingConfiguration="" contract="IMetadataExchange" />
            <host>
                <baseAddresses>
                    <add baseAddress="net.tcp://localhost:9102/XService" />
                </baseAddresses>
            </host>
        </service>

My service reference assembly config

<endpoint address="net.tcp://localhost:9103/XService/mex"
            binding="netTcpBinding" bindingConfiguration="NetTcpBinding_IXService"
            contract="XService.IXService" name="NetTcpBinding_IXService">
            <identity>
                <dns value="localhost" />
            </identity>
        </endpoint>

Finally my client app config

    <endpoint address="net.tcp://localhost:9102/XService" binding="netTcpBinding"
            bindingConfiguration="NetTcpBinding_IXService" contract="XService.IXService"
            name="NetTcpBinding_IXService" behaviorConfiguration="endPointBehavior">
            <identity>
                <dns value="localhost" />
            </identity>
        </endpoint>

Answer 3

Are you sure your service is the only one listening to port 13000?

Run netstat -noa | find "13000" netstat -noa | find "13000" before starting your program to identify which process has port 13000 open. The number in the far right-hand column will be the process ID.

Then run tasklist | find "<pid>" tasklist | find "<pid>" where is the ID of the process from the previous command. This will tell you which process has 13000 open.

Answer 4

netsat -anb （需要管理员权限）会告诉你在所有端口上监听什么...如果没有显示任何内容你可能有一个错误，你试图不止一次创建端点。

Answer 5

Do you have .Net Framework 4.5 beta installed? I have seen the same error when running on machines with 4.5 while it ran perfectly on 4.0. But then it works again if I remove the mex endpoint.

In my case something in the 4.5 changes caused the same error message. Maybe an automatic mex endpoint was created or something.

Did not see any other app using the port either, netstat showed nothing. So it was some kind of self-denial...

Answer 6

Well... mine worked when I changed the target framework to .Net framework 4 Client Profile.

Try it out... hope it works for you as well!