Уже есть слушатель на конечной точке IP 0.0.0. 13:13000.?? (TCP с использованием WCF)

Ответ 1

Я столкнулся с этой проблемой после установки .Net 4.5 и размещаю решение здесь, чтобы помочь другим, если они спотыкаются на него. Ответ на @berkayk выше работал (разоблачение mex на другом порту), но мне нужно было разоблачить обе конечные точки через один и тот же порт.

Предположим, у вас есть две конечные точки, одна из которых - netTcpBinding, а другая - с помощью mexTcpBinding. При использовании привязок по умолчанию некоторые значения по умолчанию вычисляются с использованием OSEnvironmentHelper.ProcessorCount вместо жестко закодированных значений, как это было в .Net 4.0.

В моем случае при использовании имени netTcpBinding bindingConfiguration значение, указанное для свойства MaxConnections, равно 20. Установка свойства MaxConnections в NetTcpBinding также устанавливает его свойство TcpTransportBindingElement MaxPendingConnections и свойство TcpTransport ConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint равным одному значению.

Если вы не используете именованную netTcpBinding bindingConfiguration и только по умолчанию, свойство MaxPendingConnections вычислялось с использованием следующего алгоритма:

 return (12 * OSEnvironmentHelper.ProcessorCount);

Транспортировка mexTcpBinding также рассчитала свойство MaxPendingConnections с использованием вышеприведенного алгоритма, поэтому, когда ни один из них не использует именованную конфигурацию связывания, значения по умолчанию совпадают, и проблем нет.

При использовании имени netTcpBinding bindingConfiguration транспортный пакет MaxPendingConnections составлял 20, а перенос MaxPendingConnections на mexTcpBinding был на моей машине 96. Разница в значениях для MaxPendingConnections между этими двумя конечными точками, использующими один и тот же порт, несовместима.

Я также обнаружил, что эта проблема возникла и с набором ListenBacklog. (Я не знаю всех возможных противоречивых значений, которые могут существовать.)

Чтобы устранить эту проблему, вы можете создать настраиваемую привязку для mex, которая соответствует именованной bindingConfiguration для netTcpBinding. Пример ниже:

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

Или вы не можете указать любые значения, которые вычисляются (например, maxConnections и listenBacklog), и принимать значения по умолчанию (обратите внимание, что MaxOutboundConnectionsPerEndpoint по-прежнему сохраняет значение по умолчанию 10, поскольку оно не вычисляется так же, как свойство MaxPendingConnections ):

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

Примечание. Проблема описана здесь: http://msdn.microsoft.com/en-us/library/aa702636.aspx, но единственным решением является разоблачение mex на другом порту. Ниже приведены некоторые снимки экрана в отражателе, которые показывают разницу между .net 4.0 и 4.5 при вычислении значений по умолчанию MaxPendingConnections:

Ответ 2

У меня такая же проблема после установки Visual Studio 2012 для оценки. Кажется, что обычный сервис и служба mex не могут использовать тот же порт, что и раньше, в .NET 4.0 с таким же конфигурационным файлом (я не знаю, почему, должна быть причина). Вкратце, у меня есть ссылки на мои клиентские ссылки на другую сборку и приложение wpf на другой сборке. Я опубликовал mex с другим портом, поскольку это

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

Конфигурация сборки справки

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

Наконец, мое конфигурационное приложение для клиента

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

Ответ 3

netsat -anb (требует прав администратора) сообщит вам, что прослушивает все порты... если это ничего не показывает, у вас, вероятно, есть ошибка, когда вы пытаетесь создать конечную точку более одного раза.

Ответ 4

Вы уверены, что ваш сервис является единственным, кто слушает порт 13000?

Запустите netstat -noa | find "13000", прежде чем запускать свою программу, чтобы определить, какой процесс имеет порт 13000. Число в крайнем правом столбце будет идентификатором процесса.

Затем запустите tasklist | find "<pid>", где Идентификатор процесса из предыдущей команды. Это скажет вам, какой процесс имеет 13000 открытых.

Ответ 5

У вас установлена ​​бета-версия .NET Framework 4.5? Я видел ту же ошибку при работе на машинах с 4.5, пока она отлично работала на 4.0. Но затем он снова работает, если я удаляю конечную точку mex.

В моем случае что-то в изменениях 4.5 вызвало одно и то же сообщение об ошибке. Возможно, была создана автоматическая конечная точка mex или что-то в этом роде.

Не видел другого приложения, использующего порт, netstat ничего не показывал. Так что это было какое-то самоотречение...

Ответ 6

Ну... моя работала, когда я сменил целевую структуру на .Net framework 4 Client Profile.

Попробуйте... надеюсь, что это сработает и для вас!