"Невозможно подключиться к удаленному серверу" - PullRequest
4 голосов
/ 18 ноября 2009

Я могу нормально вызывать веб-службу стороннего поставщика из программы Windows. Когда я пытаюсь вызвать тот же веб-сервис и веб-метод и тот же URL-адрес из веб-сервиса WCF, я получаю следующую ошибку:

ExportValuationPolicyNumber:Exception=System.Net.WebException: Unable to connect to the remote server ---> 
System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly 
respond after a period of time, or established connection failed 
because connected host has failed to respond 66.77.241.76:80

   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetRequestStream()
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at TFBIC.RCT.WCFWebServices.ExpressLync.ValuationServiceWse.ExportValuationPolicyNumber(String PolicyNumber) in c:\Source\TFBIC.RCT.WCFWebServices\TFBIC.RCT.WCFWebServices\Web References\ExpressLync\Reference.cs:line 519
   at TFBIC.RCT.WCFWebServices.ValuationService.ExportValuationPolicyNumber(String PolicyNumber) in c:\Source\TFBIC.RCT.WCFWebServices\TFBIC.RCT.WCFWebServices\ValuationService.svc.cs:line 97

Я в основном пытаюсь написать оболочку WCF для поставщика .asmx / WSE3. Давайте не будем отвлекаться - но Microsoft говорит, что WCF может вызывать WSE3, но только с включенным SSL, а мой поставщик - верьте этому или нет - не разрешает соединение SSL. Так что я застрял в написании оболочки, чтобы можно было звонить из BizTalk 2009. Сейчас я тестирую оболочку через консольную программу.

Что я могу сделать для отладки? Я добавил трассировки EventLog до и после службы WCF, где она вызывает службу .asmx - так что я знаю, что это там, где происходит (плюс номер строки в ошибке выше).

В моем web.config есть следующее:

<microsoft.web.services3>
        <diagnostics>
                <trace enabled="true" 
                           input="c:\inetpub\wwwroot\wsetraces\InputTrace.webinfo" 
                           output="c:\inetpub\wwwroot\wsetraces\OutputTrace.webinfo" />
                <detailedErrors enabled="true" />
        </diagnostics>
</microsoft.web.services3>

и я дал каталогу полный доступ ко всем, но никаких следов там нет.

Какие вещи я могу найти или попытаться отладить?

Теоретически результаты ping не должны иметь значения, поскольку веб-сайт работает из программы Windows form, которая вызывает его просто отлично.

Тем не менее - вот что показывает Пинг, и это выглядит немного сомнительно для меня:

C: \ Users \ uxnxw01> ping rct.msbexpress.net

Pinging rct.msbexpress.net [66.77.241.56] with 32 bytes of data:
Reply from 10.193.99.5: Destination net unreachable.
Reply from 10.193.99.5: Destination net unreachable.
Request timed out.
Reply from 10.193.99.5: Destination net unreachable.

Ping statistics for 66.77.241.56:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

Спасибо,

Нил Уолтерс


Анализ WireShark

Я запустил Wireshark - опубликовал некоторые результаты в комментарии ниже. Тем не менее, после прочтения, он не всегда говорит, что пункт назначения недоступен. Но в случае неудачи я никогда не получаю никаких данных. Я все еще не понимаю, что делать дальше. Я сравнивал пакеты, но это медленно и запутанно. Например, я до сих пор не нашел ключ (конкретный policyNum), который я передаю в пакете запроса. Я также вижу несколько утверждений "Назначение недоступно" в том, что сработало.

В том, который работает, я никогда не вижу 66.77.241.76, я вижу только прокси нашей компании. Но я не вижу ничего в конфигурации (или коде), который сказал бы WSE3 использовать или не использовать прокси.


Результаты Telnet:
C:\Users\uxnxw01>telnet 66.77.241.56 80
Connecting To 66.77.241.56...Could not open connection to the host, on port 80:
Connect failed

C:\Users\uxnxw01>telnet 66.77.241.76 80
Connecting To 66.77.241.76...Could not open connection to the host, on port 80:
Connect failed

Я не уверен, что это доказывает. Как я уже сказал, я МОГУ определенно вызывать тот же веб-сервис из формы Windows, напрямую вызывая его интерфейс WSE3. Я знаю, что смогу добраться туда таким образом.

Я думаю, что основные различия в этих двух программах заключаются в том, что одна из них работает под Win Form и вызывает WSE3 напрямую. Это работает. Неудачный код - это на 99% тот же код, опубликованный как служба WCF, поэтому он работает под управлением IIS (затем консольная программа вызывает службу WCF / IIS на моем компьютере, которая, в свою очередь, вызывает службу WSE3).

Есть ли какая-то причина, по которой IIS не будет использовать тот же прокси-сервер?

Ответы [ 4 ]

3 голосов
/ 18 ноября 2009

Благодаря всей вышеупомянутой помощи - но вот реальный ответ:

valservice.Proxy = new System.Net.WebProxy ("http://10.192.xx.xx:8080", true);

Служба WCF, работающая под IIS, по-видимому, НЕ использует тот же прокси-сервер, поэтому я установил его вручную в коде. Я отправлю еще один вопрос, чтобы узнать, есть ли способ сделать это в конфигурационном файле.

2 голосов
/ 18 ноября 2009

Вы можете использовать Wireshark , чтобы увидеть, что происходит с сетевым трафиком.

2 голосов
/ 18 ноября 2009

Ping-запросы (ICMP-пакеты) могут быть отключены на брандмауэре. Таким образом, вполне возможно не получить ответ ping, в то же время имея возможность доступа к блоку на разных портах.

Попробуйте использовать telnet для подключения к 66.77.241.56 через порт 80 и посмотрите, получите ли вы ответ.

telnet 66.77.241.56 80

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

Третья возможность заключается в том, что вам может потребоваться явно установить свойство Proxy в экземпляре клиента SoapHttpClientProtocol SOAP. WinForms подхватывает это автоматически, но в веб-сервисе / приложении это не так.

0 голосов
/ 18 ноября 2009

См. Также мои комментарии к постам других людей, но, кроме того, в связи с вашим журналом диагностики, это XML, который у меня есть в моей конфигурации для вывода журнала трассировки WCF:

<configuration>

    <system.diagnostics>
        <sources>
            <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
                <listeners>
                    <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData= "MyService.svclog" />
                </listeners>
            </source>
        </sources>
    </system.diagnostics>

</configuration>
...