Inspection des traces réseau pour l’échange de métadonnées HTTP
Tout analyseur de paquets réseau pouvant afficher des paquets bruts peut être utilisé pour inspecter les demandes d’échange de métadonnées HTTP. Microsoft Network Monitor 3 (Netmon) est recommandé. Pour plus d’informations sur Netmon, consultez Téléchargement de Netmon et Exemples de filtres DPWS.
Cette procédure de diagnostic peut ne pas être aussi utile pour les clients et les hôtes qui utilisent un canal sécurisé pour les communications, car le contenu des messages est chiffré.
Pour inspecter les traces réseau pour l’échange de métadonnées HTTP
Configurez l’hôte et le client pour qu’ils s’exécutent sur le réseau (c’est-à-dire, assurez-vous que l’hôte et le client fonctionneront sur différents ordinateurs).
Installez l’analyseur de paquets (Netmon) sur le client ou l’hôte.
Configurez l’analyseur de paquets pour capturer le trafic sur la carte réseau qui connecte l’hôte et le client.
Reproduisez l’échec en démarrant l’hôte et le client ou en appuyant sur F5 dans le Explorer réseau.
Filtrez les résultats pour isoler WS-Discovery et le trafic d’échange de métadonnées. Pour afficher les exemples de filtres Netmon, consultez Téléchargement de Netmon et Exemples de filtres DPWS.
Notes
Cette étape est facultative.
Vérifiez que les messages envoyés entre le client et l’hôte répondent aux exigences de trafic de base.
Vérification que les messages répondent aux exigences de trafic
Les clients et hôtes WSDAPI doivent envoyer des messages conformes aux critères suivants. Pour obtenir des informations générales sur les modèles de message, consultez Modèles de message d’échange de métadonnées et de découverte.
Les messages doivent répondre aux exigences de trafic fournies dans la rubrique Inspection des traces réseau pour UDP WS-Discovery, sauf s’il est absolument certain que WS-Discovery n’est pas utilisé pour l’échange de métadonnées.
Une connexion TCP doit être établie entre le client et la première adresse de transport fournie dans l’élément XAddrs d’un message ProbeMatches ou ResolveMatches . La liste suivante présente un échange de paquets classique utilisé pour établir une connexion TCP.
- Le client envoie un paquet TCP SYN à l’hôte à un port spécifié.
- L’hôte envoie un paquet TCP SYN/ACK au client.
- Le client envoie un paquet TCP ACK à l’hôte à un port spécifié.
Une fois que le client a envoyé un paquet TCP ACK, la connexion TCP est établie. Notez que cet échange de messages ne se produit pas si une connexion TCP a déjà été établie.
Le client doit envoyer une requête et un message Get HTTP valides.
L’hôte doit être à l’écoute sur le chemin d’URL spécifié dans la requête HTTP Get .
L’élément To d’un message Get metadata doit être présent et non vide. La valeur de l’élément To doit correspondre à l’une des adresses de point de terminaison de l’hôte. L’adresse de point de terminaison d’un hôte est généralement annoncée dans un message ProbeMatches ou ResolveMatches .
L’hôte doit envoyer un en-tête de réponse HTTP valide. Si la requête initiale a réussi, l’en-tête de réponse doit contenir le code HTTP/1.1 200 status.
L’hôte doit envoyer un message GetResponse valide.
L’élément RelatesTo d’un message GetResponse doit être présent et ne doit pas être vide. Sa valeur doit correspondre à la valeur de l’élément MessageId du message Get correspondant.
Si les requêtes HTTP ou les messages d’échange de métadonnées envoyés par le programme ne sont pas conformes à ces exigences de trafic, la cause du problème a été identifiée et aucune autre étape de dépannage n’est nécessaire. Réécrire le programme afin qu’il génère des messages et des requêtes conformes et reteste le programme.
Si la source du problème ne peut toujours pas être identifiée, contactez le support Microsoft pour obtenir de l’aide. Avant de contacter le support technique, collectez les fichiers journaux appropriés pour identifier la cause racine du problème. Pour plus d’informations, consultez Activation du suivi WSDAPI.
Rubriques connexes