Проблемы WCF Duplex net.tcp на win7

У нас есть служба WCF с несколькими клиентами для планирования операций между клиентами. Он отлично работал на XP. Переходя на win7, я могу подключить клиента к серверу только на той же машине. На данный момент я думаю, что это как-то связано с IPv6, но я не понимаю, как действовать дальше.

Клиент, пытающийся подключиться к удаленному серверу, дает следующее исключение:

System.ServiceModel.EndpointNotFoundException: не удалось подключиться к net.tcp: //10.7.11.14: 18297 / zetec / Service / SchedulerService / Scheduler. Попытка подключения длилась 00: 00: 21.0042014. Код ошибки TCP 10060: попытка подключения не удалась из-за того, что подключенная сторона не ответила должным образом по прошествии определенного периода времени, или установление соединения не удалось из-за того, что подключенный хост не ответил 10.7.11.14:18297. ---> System.Net.Sockets.SocketException: попытка подключения не удалась, потому что подключенная сторона не ответила должным образом по прошествии определенного периода времени, или установление соединения не удалось из-за того, что подключенный хост не ответил 10.7.11.14:18297

Сервис настроен так:

<system.serviceModel>
  <services>
     <service
         name="SchedulerService"
         behaviorConfiguration="SchedulerServiceBehavior">
        <host>
           <baseAddresses>
              <add baseAddress="net.tcp://localhost/zetec/Service/SchedulerService"/>
           </baseAddresses>
        </host>
        <endpoint address="net.tcp://localhost:18297/zetec/Service/SchedulerService/Scheduler"
                  binding="netTcpBinding"
                  bindingConfiguration = "ConfigBindingNetTcp"
                  contract="IScheduler" />
        <endpoint address="net.tcp://localhost:18297/zetec/Service/SchedulerService/Scheduler"
                  binding="netTcpBinding"
                  bindingConfiguration = "ConfigBindingNetTcp"
                  contract="IProcessingNodeControl" />
     </service>
  </services>
  <bindings>
     <netTcpBinding>
        <binding name = "ConfigBindingNetTcp" portSharingEnabled="True">
           <security mode="None"/>
        </binding>
     </netTcpBinding >
  </bindings>

  <behaviors>
     <serviceBehaviors>
        <behavior name="SchedulerServiceBehavior">
           <serviceDebug includeExceptionDetailInFaults="true" />
           <serviceThrottling maxConcurrentSessions="100"/>
        </behavior>
     </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Клиент подключается так:

String endPoint = "net.tcp://" + GetIPV4Address(m_SchedulerHostAddress) + ":" + m_SchedulerHostPort.ToString(CultureInfo.InvariantCulture) + "/zetec/Service/SchedulerService/Scheduler";

NetTcpBinding binding = new NetTcpBinding();
binding.Security.Mode = SecurityMode.None;

m_Channel = new DuplexChannelFactory<IProcessingNodeControl>(this, binding, endPoint);
m_IProcessingNodeControl = m_Channel.CreateChannel();

Я проверял свой брандмауэр около десятка раз, но думаю, что-то мне не хватает. Пытался отключить брандмауэр Windows. Я попытался изменить localhost на свой адрес ipv4, чтобы избежать ipv6, я попытался удалить любой код anti-ipv6.

Не знаю, означает ли это что-нибудь, но:

Microsoft Telnet> открыть 10.7.11.14 18297
Подключение к 10.7.11.14 ... Не удалось открыть подключение к узлу, на порту 18297: подключение не удалось

К сожалению, тест telnet не является ключевым. Я успешно подключился к порту моей службы с локального хоста и удаленного компьютера, когда служба работает, но мой клиент не работал с удаленного компьютера.

Похоже, подключение к localhost не всегда гарантируется. Рабочий стол (win7 / 32) работает, ноутбук (win7 / 64) не работает. Однако другие коробки win7 / 64 работают. Возможно, из-за того, что на ноутбуке есть несколько ников? Также не объясняются сбои при подключении к системам тестировщиков.

Я установил две машины win7 с полностью отключенным IPv6 (используя 0xffffffff, как в http://support.microsoft.com/kb/929852). Нет помощи.


person Thomas    schedule 12.03.2010    source источник
comment
Только что немного хлопнул по лбу. У потребителя контракта IScheduler нет проблем при работе на разных машинах. Только клиенты IProcessingNodeControl не могут подключиться. Они используют практически идентичный код для подключения. Прямо сейчас я думаю, что у них должны быть разные относительные URL-адреса, но это, похоже, не помогает.   -  person Thomas    schedule 15.03.2010
comment
Хорошо, поэтому я могу наблюдать, как мой клиент терпит неудачу, терпит неудачу, не может подключиться, затем выключаю брандмауэр Windows, и он преуспевает. В моем хостинге уже есть исключение, что еще мне нужно, кроме?   -  person Thomas    schedule 16.03.2010


Ответы (2)


Что-то не так с базовым адресом вашего хоста, а затем с адресами конечных точек. У одного есть явная ссылка на порт, у другого - нет. Обычно, когда вы используете базовый адрес, вы используете относительный URL-адрес в адресе конечной точки.

Я не могу понять, почему это может быть связано с IPv6, потому что ни в одном из сообщений об ошибках не упоминаются адреса IPv6.

Возможно, попробуйте еще раз после отключения опции совместного использования порта net.tcp. Без совместного использования портов вы должны иметь возможность конфигурировать соединение с помощью telnet, как вы это делали.

Кроме того, как ваша служба размещена в Win7? В IIS7 или в службе Windows? Для размещения его в службе может потребоваться предоставить некоторые разрешения для вашего exe, помимо открытия портов на вашем брандмауэре (например, вам иногда приходится делать для размещения службы Windows в HTTP в Win XP).

Извините, я тороплюсь и не могу найти для них URL-адреса.

person ligos    schedule 13.03.2010
comment
спасибо за отзыв, завтра поиграю с адресами. Это автономная служба в приложении, которое пользователь запускает от имени администратора. Он живет в системном трее. - person Thomas; 15.03.2010
comment
Что ж, вы специально не решили мою проблему, но переход на относительные пути действительно выявил тот факт, что / Scheduler использовался для двух разных контрактов, и это казалось странным. Я изменил второй на / NodeControl, и он работает над настройкой моего разработчика! Интересно, почему он работает на XP, а не на Win7. Спасибо! - person Thomas; 15.03.2010
comment
Ну развернули для тестирования и дела обстоят еще хуже. Ни клиенты планировщика, ни клиенты NodeControl не могут подключиться, если сервер не находится на локальном хосте. - person Thomas; 16.03.2010

У меня нет времени возвращаться и проверять, является ли это комбинацией помощи, которую я получил от ligos, или нет, но основное исправление, похоже, заключается в добавлении SMSvcHost.exe в исключения в брандмауэре Windows.

Большое спасибо за вашу помощь, ligos. Я был готов сдаться, пока вы не ответите на мой вопрос.

Инструкции по добавлению net.tcp в брандмауэр Windows:

  1. Перейдите в раздел «Службы», найдите службу совместного использования портов net.TCP и дважды щелкните ее. Проведите по пути к исполняемому файлу (не беспокойтесь, если он не весь на экране, при смахивании он должен прокручиваться) и скопируйте его (ctrl-c)
  2. Зайдите в свой брандмауэр и добавьте новую программу, которой будет разрешено общаться через брандмауэр Windows. Вставьте путь из Services и нажмите ОК.
person Thomas    schedule 15.03.2010
comment
Я предполагаю, что SMSvsHost.exe - это процесс, который творит чудеса, лежащие в основе совместного использования портов Net.TCP. Рад, что это работает на тебя. - person ligos; 16.03.2010