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.CommunicationObject.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>

firewall shouldn't give you an AddressAlreadyInUseException. — Yaur, Mar 16 '12 at 21:28
I'm also having this issue. I've tried changing ports and nothing works. — Justin Drury, Mar 26 '12 at 18:43

dugas · Answer 1 · 2012-09-19T16:58:59.527

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:

.Net 4.0 ConnectionOrientedTransportBindingElement Calculating default MaxPendingConnections

.Net 4.5 ConnectionOrientedTransportBindingElement Calculating default MaxPendingConnections

.Net 4.5 GetMaxPendingConnections method

You're a life saver! Spent 2 days on this but couldn't get it to work. Just deleted `listenBacklog` and `maxConnections` from the `binding` tag and its working fine now! Thanks a mil! — Vishal Shah, Nov 06 '12 at 07:58
Great explanation and answer. I knew this was an issue but never understood the reasons behind it. Thank you :) — Jonathan Coffey, Oct 07 '16 at 10:14

score 14 · Answer 2 · answered Aug 23 '12 at 05:37

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>

score 7 · Answer 3 · answered Mar 16 '12 at 21:28

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

Run 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>" where is the ID of the process from the previous command. This will tell you which process has 13000 open.

score 4 · Answer 4 · answered Mar 16 '12 at 21:27

4

netsat -anb (requires admin privileges) will tell you what is listening on all ports... if that shows nothing you probably have a bug where you are trying to create the endpoint more than once.

answered Mar 16 '12 at 21:27

Yaur

7,333
1
25
36

1

Then set up VS studio to break on all exceptions and when you see the address in use exception re run the command. – Yaur Mar 16 '12 at 22:47

score 2 · Answer 5 · answered May 26 '12 at 09:58

2

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...

answered May 26 '12 at 09:58

Per Salmi

1,398
1
14
28

Now I am having this problem, did you find any solution? – Vasea May 30 '12 at 13:06
Only removing the metadata endpoint config in the app.config helped. – Per Salmi Jun 01 '12 at 15:27
I had the issue in .net 4.5 - see my post in this thread for a solution. – dugas Sep 13 '12 at 18:49

score -1 · Answer 6 · edited Mar 28 '14 at 07:46

-1

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!

edited Mar 28 '14 at 07:46

lucian.pantelimon

3,673
4
29
46

answered Mar 28 '14 at 07:26

Ozesh

6,536
1
25
23

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

6 Answers6

Linked