Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dowolny analizator pakietów sieciowych, który może wyświetlać nieprzetworzone pakiety, może służyć do sprawdzania żądań wymiany metadanych HTTP. Zalecany jest program Microsoft Network Monitor 3 (Netmon). Aby uzyskać więcej informacji na temat Netmon, zobacz Pobieranie Netmonu i przykładowych filtrów DPWS.
Ta procedura diagnostyczna może nie być tak przydatna dla klientów i hostów korzystających z bezpiecznego kanału komunikacji, ponieważ zawartość wiadomości jest szyfrowana.
Aby sprawdzić ślady sieci na potrzeby wymiany metadanych HTTP
Skonfiguruj hosta i klienta do uruchamiania w sieci (czyli upewnij się, że host i klient będą działać na różnych komputerach).
Zainstaluj analizator pakietów (Netmon) na kliencie lub hoście.
Skonfiguruj analizator pakietów, aby monitorować ruch na adapterze sieciowym łączącym hosta i klienta.
Odtwórz błąd, uruchamiając hosta i klienta lub naciskając F5 w Eksploratorze sieci.
Przefiltruj wyniki, aby odizolować ruch WS-Discovery i ruch związany z wymianą metadanych. Aby wyświetlić przykładowe filtry Netmon, zobacz Pobieranie Netmon i przykładowych filtrów DPWS.
Notatka
Ten krok jest opcjonalny.
Sprawdź, czy komunikaty wysyłane między klientem a hostem spełniają podstawowe wymagania dotyczące ruchu.
Sprawdzanie, czy komunikaty spełniają wymagania dotyczące ruchu
Klienci i hosty WSDAPI muszą wysyłać komunikaty zgodne z następującymi kryteriami. Aby uzyskać ogólne informacje na temat wzorców komunikatów, zobacz Odkrywanie i wzorce komunikatów wymiany metadanych.
Komunikaty muszą spełniać wymagania dotyczące ruchu podane w temacie Inspekcja śladów sieci dla UDP WS-Discovery, chyba że jest absolutnie pewne, że WS-Discovery nie jest używany do wymiany metadanych.
Połączenie TCP musi zostać ustanowione między klientem a pierwszym adresem transportowym podanym w elemencie XAddrs wiadomości ProbeMatches lub ResolveMatches. Na poniższej liście przedstawiono typową wymianę pakietów używaną do nawiązywania połączenia TCP.
- Klient wysyła pakiet TCP SYN do hosta na określonym porcie.
- Host wysyła pakiet TCP SYN/ACK do klienta.
- Klient wysyła pakiet TCP ACK do hosta na określonym porcie.
Po wysłaniu przez klienta pakietu TCP ACK zostanie nawiązane połączenie TCP. Pamiętaj, że ta wymiana komunikatów nie zostanie wykonana, jeśli połączenie TCP zostało wcześniej nawiązane.
Klient musi wysłać prawidłowe żądanie HTTP typu Get i komunikat.
Host musi nasłuchiwać na ścieżce adresu URL określonej w żądaniu HTTP Get.
Element To w elemencie Get wiadomości metadanych musi być obecny i nie może być pusty. Wartość elementu To musi być zgodna z jednym z adresów końcowych hosta. Adres punktu końcowego hosta jest zazwyczaj komunikowany w komunikacie ProbeMatches lub komunikacie ResolveMatches.
Host musi wysłać prawidłowy nagłówek odpowiedzi HTTP. Jeśli początkowe żądanie zakończyło się pomyślnie, nagłówek odpowiedzi powinien zawierać kod stanu HTTP/1.1 200.
Host musi wysłać prawidłowy komunikat GetResponse.
Element RelatesTo elementu GetResponse musi być obecny i nie może być pusty. Jego wartość musi odpowiadać wartości elementu MessageId z odpowiedniego komunikatu Get.
Jeśli żądania HTTP lub komunikaty wymiany metadanych wysyłane przez program nie są zgodne z tymi wymaganiami dotyczącymi ruchu, przyczyna problemu została pomyślnie zidentyfikowana i nie są wymagane żadne dalsze kroki rozwiązywania problemów. Zapisz ponownie program, aby wygenerował zgodne komunikaty i żądania i ponownie przetestował program.
Jeśli nie można zidentyfikować źródła problemu, skontaktuj się z pomocą techniczną firmy Microsoft, aby uzyskać pomoc. Przed skontaktowaniem się z pomocą techniczną zbierz odpowiednie pliki dziennika, aby pomóc zidentyfikować główną przyczynę problemu. Aby uzyskać więcej informacji, zobacz Włączanie śledzenia WSDAPI.
Tematy pokrewne