"Impossible de se connecter au serveur distant"

StackOverflow https://stackoverflow.com/questions/1752646

  •  20-09-2019
  •  | 
  •  

Question

Je suis en mesure d'appeler un service Web du fournisseur 3ème partie d'un programme de formulaire Windows très bien. Quand je tente d'appeler le même service Web et la méthode Web et même URL d'un service Web WCF je reçois l'erreur suivante: 

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

Je suis fondamentalement en train d'écrire un wrapper WCF pour le vendeur .asmx / service WSE3. Il ne faut pas descendre le point - mais Microsoft dit WCF peut appeler WSE3, mais seulement avec SSL activé, et mon fournisseur - croyez-le ou non - ne permet pas une connexion SSL. Alors I'mn coincé écrire l'emballage afin que je puisse appeler à partir de BizTalk 2009. En ce moment, je teste l'emballage au moyen d'un programme de console.

Qu'est-ce que je peux même le faire pour déboguer? J'ai ajouté EventLog traces avant et après le service WCF où il appelle le service .asmx - donc je sais que ce où le vent souffle (plus le numéro de ligne dans l'erreur ci-dessus).

J'ai ce qui suit dans mon 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>

et j'ai donné le répertoire complet d'accès à tout le monde - mais aucune trace apparaît là.

Quelles sont les choses que je peux rechercher ou essayer à côté de débugger?

En théorie « ping » résultats ne doivent pas d'importance, parce que le site fonctionne à partir du programme de formulaire Windows qu'il appelle très bien.

Mais - voici ce que Ping montre et il semble un peu douteux pour moi:

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

Merci,

Neal Walters

analyse WireShark

J'ai couru Wireshark - publié quelques résultats dans les commentaires ci-dessous. Cependant, après avoir lu plus, il ne dit pas toujours « Destination Inaccessible ». Mais dans le cas où il est défaillant, je ne peux plus me dateur. Je ne comprends toujours pas quoi faire. J'ai comparais des paquets, mais il est lent et confus. Par exemple, je n'ai pas encore trouvé la clé (une policyNum spécifique) que je passe dans le paquet de demande. Je vois aussi quelques déclarations « Destination Unreachable » dans celui qui a travaillé.

Dans celui qui fonctionne, je ne vois 66.77.241.76, je ne vois que le proxy de l'entreprise. Mais je ne vois rien dans la configuration (ou code) qui raconterait WSE3 à utiliser ou ne pas utiliser le proxy.

Résultats 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

Je ne sais pas ce que cela prouve. Comme je l'ai dit, je peux certainement appeler le même webservice d'un formulaire Windows en appelant directement son interface WSE3. Je sais que je peux y arriver de cette façon.

Je pense les principales différences entre les deux programmes est que l'un est en cours d'exécution sous forme Win et d'appeler directement WSE3. Que l'on travaille. Celui qui n'est essentiellement 99% même code, publié en tant que service WCF, il est donc en cours d'exécution sous IIS (puis un programme de console appelle le service WCF / IIS sur ma machine, qui à son tour appelle le service WSE3).

Y at-il une raison IIS ne pas utiliser le même proxy?

Était-ce utile?

La solution

Merci à toute l'aide ci-dessus - mais voici la vraie réponse:

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

Le service WCF en cours d'exécution sous IIS n'a apparemment pas d'utiliser le même proxy, donc je l'ai mis manuellement dans le code. Je posterai une autre question pour voir s'il y a une façon de le faire dans le fichier de configuration.

Autres conseils

Vous pouvez utiliser Wireshark pour voir ce qui se passe avec le trafic réseau.

Demandes Ping (paquets ICMP) peuvent être désactivés sur le pare-feu. Il est donc parfaitement possible de ne pas obtenir une réponse ping arrière, tout en étant en mesure d'accéder à la boîte sur des ports différents.

Essayez d'utiliser telnet pour se connecter à 66.77.241.56 sur le port 80 et voir si vous obtenez une réponse.

telnet 66.77.241.56 80

Alternativement, un tracerte à ladite adresse IP peut fournir des informations plus détaillées pour l'un de vos administrateurs réseau, car il pourrait aussi avoir à faire avec le routage réseau ou NAT.

troisième possibilité est que vous devrez peut-être définir explicitement la propriété Proxy sur votre SoapHttpClientProtocol exemple SOAP client. WinForms prendre cette place automatiquement, mais d'un service Web / app ce n'est pas le cas.

Voir mes commentaires sur les messages des autres aussi, mais en plus, en rapport avec votre journal de diagnostic, c'est le XML que j'ai dans ma config pour vider un journal de trace 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>
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top