Esiste già un listener su endpoint IP 0.0.0.0:13000. ?? (TCP using WCF)

Question

Sto cercando di capire perché la porta viene utilizzata anche dopo il riavvio del computer!

System.ServiceModel.AddressAlreadyInUseException: esiste già un listener su endpoint IP 0.0.0.0:13000. Ciò potrebbe accadere se è già in ascolto un'altra applicazione su questo endpoint o se si dispone di più endpoint del servizio nel proprio host di servizio con lo stesso endpoint IP ma con configurazioni di rilegatura incompatibili. ---> System.Net.Sockets.SocketException: solo un utilizzo di ciascun indirizzo socket (protocollo/indirizzo/porta di rete) è normalmente consentito in System.Net.Sockets.SoDub (EndPoint endPointSnapshot, SocketAddress socketAddress) in System.Net.Sockets.Socket.Bind (EndPoint localEP) in System.ServiceModel.Channels.SocketConnectionListener.Listen() --- Fine della traccia dello stack di eccezioni interne --- in System.ServiceModel.Channels.SocketConnectionListener.Listen() a System.ServiceModel.Channels.TracingConnectionListener.Listen() a System.ServiceModel.Channels.ConnectionAcceptor.StartAccepting() a System.ServiceModel.Channels.ExclusiveTcpTransportManager.OnOpen() a System.ServiceModel.Channels.Trans portManager.Open (TransportChannelListener channelListener) a System.ServiceModel.Channels.TransportManagerContainer.Open (SelectTransportManagersCallback selectTransportManagerCallback) a System.ServiceModel.Channels.TcpChannelListener`2.OnOpen (TimeSpan timeout) a System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) a System.ServiceModel.Dispatcher.ChannelDispatcher.OnOpen (TimeSpan timeout) a System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) a System.ServiceModel.ServiceHostBase.OnOpen (TimeSpan timeout) presso System .ServiceModel.Channels.CommunicationObject.Open (timeout TimeSpan) in Microsoft.Tools.SvcHost.ServiceHostHelper.OpenService (informazioni ServiceInfo) System.Net.Sockets.SocketException (0x80004005): è consentito un solo utilizzo di ciascun indirizzo socket (protocollo/indirizzo di rete/porta) in System.Net.Sockets.SoBind (EndPoint endPointSnapshot, SocketAddress socketAddress) in corrispondenza di System.Net.Sockets.Socket.Bind (EndPoint localEP) a System.ServiceModel.Channels.SocketConnectionListener.Listen()

Come si fa a capire quale processo sta ascoltando quella porta (13000)? Netstat non mostra nulla su quella porta.

Ecco il mio 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

netsat -anb (richiede privilegi di amministratore) vi dirà che cosa è in ascolto su tutte le porte ... se che non mostra nulla probabilmente avete un bug in cui si sta tentando di creare l'endpoint più di una volta.

Answer 2

Sei sicuro che il tuo servizio sia l'unico ad ascoltare la porta 13000?

Eseguire netstat -noa | find "13000" prima di avviare il programma per identificare quale processo ha la porta 13000 aperta. Il numero nella colonna di estrema destra sarà l'ID del processo.

Quindi eseguire tasklist | find "<pid>" dove è l'ID del processo dal comando precedente. Questo ti dirà quale processo ha aperto 13000.

Answer 3

Avete installato .Net Framework 4.5 beta?Ho visto lo stesso errore durante l'esecuzione su macchine con 4.5 mentre funzionava perfettamente su 4.0. Ma poi funziona di nuovo se rimuovo l'endpoint mex.

Nel mio caso qualcosa nelle modifiche 4.5 ha causato lo stesso messaggio di errore. Forse è stato creato un endpoint automatico di mess o qualcosa del genere.

Non ho visto nessuna altra app che utilizzava la porta, Netstat non ha mostrato nulla. Quindi era una sorta di abnegazione ...

Answer 4

Ho lo stesso problema dopo aver installato Visual Studio 2012 per valutare. Sembra che il servizio normale e il servizio mess non possano condividere la stessa porta utilizzata in .NET 4.0 con lo stesso file di configurazione (non so perché, ci deve essere una ragione). In breve, ho i riferimenti ai miei client di servizio su un assembly diverso e l'applicazione wpf su un assembly diverso. Ho pubblicato mex con porta diversa da questa

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

mio assemblaggio riferimento al servizio di configurazione

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

Infine il mio cliente 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 5

ho vissuto questo problema dopo l'installazione di .Net 4.5 e sono pubblicare una soluzione qui per aiutare gli altri se ci inciampano. La risposta di @ berkayk ha funzionato sopra (esponendo il mess a una porta diversa), ma ho dovuto esporre entrambi gli endpoint attraverso la stessa porta.

Si supponga di avere due endpoint, uno con netTcpBinding e uno con mexTcpBinding. Quando si utilizzano i collegamenti predefiniti, alcuni dei valori predefiniti vengono calcolati utilizzando OSEnvironmentHelper.ProcessorCount anziché i valori codificati come erano in .Net 4.0.

Nel mio caso, quando si utilizza un nome netTcpBinding bindingConfiguration, il valore fornito per la proprietà MaxConnections era 20. Impostazione dei MaxConnections proprietà sul NetTcpBinding stabilisce anche che è di TcpTransportBindingElement immobili MaxPendingConnections e la proprietà ConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint del TcpTransport per lo stesso valore.

Quando non si utilizza un nome netTcpBinding bindingConfiguration, e solo con l'impostazione predefinita, la MaxPendingConnections proprietà è stato calcolato utilizzando il seguente algoritmo:

return (12 * OSEnvironmentHelper.ProcessorCount); 

trasporto del mexTcpBinding anche calcolato che sia di proprietà MaxPendingConnections utilizzando l'algoritmo di cui sopra, in modo da quando nessuno dei due utilizza un bindingConfiguration con nome, i valori predefiniti corrispondono e non vi è alcun problema.

Quando si utilizza un bindingConfiguration netTcpBinding denominato, MaxPendingConnections del trasporto era 20 e il MaxPendingConnections del trasporto di mexTcpBinding era, sulla mia macchina, 96. La differenza nei valori per MaxPendingConnections tra questi due endpoint che condividono la stessa porta non è compatibile.

Inoltre, ho riscontrato che questo problema si verificava anche con il set ListenBacklog. (non so di tutti i possibili valori in conflitto che possono esistere.)

Per risolvere il problema, è possibile creare un binding per mex che corrisponde al nome bindingConfiguration per netTcpBinding personalizzato.Esempio di seguito:

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

O, non è possibile specificare i valori che sono calcolati (come maxConnections e ListenBacklog) e accettare le impostazioni predefinite (da notare che MaxOutboundConnectionsPerEndpoint continuerà ad avere il valore predefinito di 10 in quanto non è calcolato nel allo stesso modo che la proprietà MaxPendingConnections è):

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

Nota: il problema è descritto qui: http://msdn.microsoft.com/en-us/library/aa702636.aspx, ma l'unica soluzione proposta è quella di esporre l'mex su una porta diversa. Qui di seguito alcuni screenshot in riflettore che mostrano la differenza tra .net 4.0 e 4.5 per il calcolo dei valori di default: MaxPendingConnections

Answer 6

Beh ... il mio lavorato quando ho cambiato il framework di riferimento per .Net framework 4 Client Profile.

Provalo ... spero che funzioni anche per te!