c# - net - Ya hay un escucha en el punto final de IP 0.0.0.0:13000. ??(TCP utilizando WCF)

servicio net tcp (6)

¡Estoy tratando de averiguar por qué se usa el puerto incluso después de reiniciar la computadora!

System.ServiceModel.AddressAlreadyInUseException: ya hay un oyente en el punto final de IP 0.0.0.0:13000. Esto podría suceder si ya hay otra aplicación escuchando en este punto final o si tiene múltiples puntos finales de servicio en su host de servicio con el mismo punto final IP pero con configuraciones de enlace incompatibles. ---> System.Net.Sockets.SocketException: normalmente se permite un uso de cada dirección de socket (protocolo / dirección de red / puerto) en System.Net.Sockets.Socket.DoBind (EndPoint endPointSnapshot, SocketAddress socketAddress) en el sistema. Net.Sockets.Socket.Bind (EndPoint localEP) en System.ServiceModel.Channels.SocketConnectionListener.Listen () --- Fin del seguimiento de la pila de excepciones internas --- en System.ServiceModel.Channels.SocketConnectionListener.Listen () en System. ServiceModel.Channels.TracingConnectionListener.Listen () en System.SceliceMronel.pay.Pay.pay.pay.png.png.png.png. ServiceModel.Channels.TransportManagerContainer.Open (SelectTransportManagersCallback selectTransportManagerCallback) en System.ServiceModel.Channels.TcpChannelListener`2.OnOpen (TimeSpan timeout) en System.ServiceModel.Channels.Communicat ionObject.Open (TimeSpan timeout) en System.ServiceModel.Dispatcher.ChannelDispatcher.OnOpen (TimeSpan timeout) en System.ServiceModel.Channels.Servicio de búho en el ojete de la mano o de la empresa. ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) en Microsoft.Tools.SvcHost.ServiceHostHelper.OpenService (ServiceInfo info) System.Net.Sockets.SocketException (0x80004005): Solo un uso de cada dirección de socket (protocolo / dirección de red / puerto) Normalmente se permite en System.Net.Sockets.Socket.DoBind (EndPoint endPointSnapshot, SocketAddress socketAddress) en System.Net.Sockets.Socket.Bind (EndPoint localEP) en System.ServiceModel.Channels.SocketConnectionListener.Listen ()

¿Cómo averiguas qué proceso está escuchando ese puerto (13000)? Netstat no muestra nada en ese puerto.

Aquí está mi App.config:

<system.web> <compilation debug="true" /> </system.web>  <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>

¿Está seguro de que su servicio es el único que escucha el puerto 13000?

Ejecutar netstat -noa | find "13000" netstat -noa | find "13000" antes de iniciar su programa para identificar qué proceso tiene abierto el puerto 13000. El número en la columna del extremo derecho será el ID de proceso.

A continuación, ejecute la tasklist | find "<pid>" tasklist | find "<pid>" donde está el ID del proceso del comando anterior. Esto te dirá qué proceso tiene 13000 abiertos.

¿Tienes .Net Framework 4.5 beta instalado? He visto el mismo error cuando se ejecuta en máquinas con 4.5, mientras que funcionó perfectamente en 4.0. Pero luego vuelve a funcionar si elimino el punto final de mex.

En mi caso, algo en los cambios 4.5 causó el mismo mensaje de error. Tal vez se creó un punto final de mex automático o algo así.

Tampoco vi ninguna otra aplicación usando el puerto, netstat no mostró nada. Así que fue una especie de abnegación ...

Bueno ... el mío funcionó cuando cambié el marco de destino a .Net framework 4 Client Profile.

Pruébalo ... ¡Espero que también te funcione!

Estoy teniendo el mismo problema después de instalar Visual Studio 2012 para evaluar. Parece que el servicio normal y el servicio mex no pueden compartir el mismo puerto que solía estar en .NET 4.0 con el mismo archivo de configuración (no sé por qué, debe haber una razón). Brevemente tengo las referencias de mis clientes de servicio en un conjunto diferente y la aplicación wpf en un conjunto diferente. Publiqué mex con diferente puerto como este.

Mi servicio de configuración de montaje de referencia

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

Finalmente mi configuración de la aplicación cliente

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

Experimenté este problema después de instalar .Net 4.5 y estoy publicando una solución aquí para ayudar a otros si se tropiezan con ella. La respuesta de @ berkayk anterior funcionó (exponiendo el mex en un puerto diferente), pero necesitaba exponer ambos puntos finales a través del mismo puerto.

Supongamos que tiene dos puntos finales, uno con netTcpBinding y otro con mexTcpBinding. Cuando se usan los enlaces predeterminados, algunos de los valores predeterminados se calculan utilizando OSEnvironmentHelper.ProcessorCount en lugar de los valores codificados como estaban en .Net 4.0.

En mi caso, al usar una netTcpBinding bindingConfiguration nombrada, el valor proporcionado para la propiedad MaxConnections fue 20. La configuración de la propiedad MaxConnections en la NetTcpBinding también establece su propiedad MaxPendingConnections de TcpTransportBindingElement y en el punto de vista de la conexión TcpTransport.

Cuando no se usa una configuración de enlace netTcpBinding con nombre, y solo se usa el valor predeterminado, la propiedad MaxPendingConnections se calculó utilizando el siguiente algoritmo:

return (12 * OSEnvironmentHelper.ProcessorCount);

El transporte de mexTcpBinding también calculó que es la propiedad MaxPendingConnections utilizando el algoritmo anterior, de modo que cuando ninguno de los dos está usando una configuración de binding con nombre, los valores predeterminados coinciden y no hay problema.

Al usar una netTcpBinding bindingConfiguration nombrada, la MaxPendingConnections del transporte era 20, y la MaxPendingConnections del transporte mexTcpBinding era, en mi máquina, 96. La diferencia en los valores para la MaxPendingConnections entre estos dos puntos finales que comparten el mismo puerto es incompatible.

También encontré que este problema ocurrió con el conjunto ListenBacklog también. (No conozco todos los posibles valores en conflicto que puedan existir).

Para resolver el problema, puede crear un enlace personalizado para mex que coincida con la configuración bindinging nombrada para netTcpBinding. Ejemplo a continuación:

O, no puede especificar ningún valor que se calcule (como maxConnections y listenBacklog) y aceptar los valores predeterminados (tenga en cuenta que MaxOutboundConnectionsPerEndpoint aún conservará el valor predeterminado de 10, ya que no se calcula de la misma manera que la propiedad MaxPendingConnections):

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

Nota: el problema se describe aquí: http://msdn.microsoft.com/en-us/library/aa702636.aspx , pero la única solución es exponer el mex en un puerto diferente. A continuación se muestran algunas capturas de pantalla en el reflector que muestran la diferencia entre .net 4.0 y 4.5 al calcular los valores predeterminados de MaxPendingConnections:

netsat -anb (requiere privilegios de administrador) le dirá lo que está escuchando en todos los puertos ... si eso no muestra nada, probablemente tenga un error en el que está intentando crear el punto final más de una vez.