Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Любой анализатор сетевых пакетов, который может отображать необработанные пакеты, можно использовать для проверки запросов обмена метаданными HTTP. Рекомендуется использовать Microsoft Network Monitor 3 (Netmon). Дополнительные сведения о Netmon см. в загрузке Netmon и примерах фильтров DPWS.
Эта диагностическая процедура может оказаться не столь полезной для клиентов и узлов, использующих безопасный канал для обмена данными, так как содержимое сообщения шифруется.
Проверка сетевых трассировок для обмена метаданными HTTP
Настройте узел и клиент для выполнения в сети (то есть убедитесь, что узел и клиент будут работать на разных компьютерах).
Установите анализатор пакетов (Netmon) на клиенте или узле.
Настройте анализатор пакетов для перехвата трафика на сетевом адаптере, соединяющем хост и клиент.
Воспроизведение сбоя путем запуска узла и клиента или нажатием клавиши F5 в сетевом обозревателе.
Отфильтруйте результаты, чтобы изолировать трафик обмена WS-Discovery и метаданными. Сведения о просмотре примеров фильтров Netmon см. в статье Скачивание фильтров Netmon и примеров фильтров DPWS.
Заметка
Этот шаг является необязательным.
Убедитесь, что сообщения, отправленные между клиентом и узлом, соответствуют основным требованиям к трафику.
Проверка соответствия сообщений требованиям к трафику
Клиенты и узлы WSDAPI должны отправлять сообщения, соответствующие следующим критериям. Общую информацию о моделях сообщений см. в Модели сообщений для обнаружения и обмена метаданными.
Сообщения должны соответствовать требованиям к трафику, представленным в разделе «Проверка трассировок сети для обнаружения WS-Discovery по UDP», если только нет абсолютной уверенности, что WS-Discovery не используется для обмена метаданными.
Необходимо установить TCP-подключение между клиентом и первым адресом транспорта, указанным в элементе XAddrs сообщения ProbeMatches или ResolveMatches. В следующем списке показан типичный обмен пакетами, используемый для установления TCP-подключения.
- Клиент отправляет пакет TCP SYN на узел по указанному порту.
- Хост отправляет пакет TCP SYN/ACK клиенту.
- Клиент отправляет пакет TCP ACK на узел по указанному порту.
После отправки клиентом пакета TCP ACK устанавливается TCP-подключение. Обратите внимание, что обмен сообщениями не будет происходить, если ранее было установлено TCP-подключение.
Клиент должен отправить действительный HTTP-запрос GET и сообщение.
Этот хост должен прослушивать URL-путь, указанный в HTTP-запросе Get.
Элемент To сообщения Get метаданные должен присутствовать и не быть пустым. Значение элемента To должно соответствовать одному из конечных адресов узла. Адрес конечной точки узла обычно указывается в сообщении ProbeMatches или ResolveMatches.
Хост должен отправить допустимый заголовок ответа HTTP. Если первоначальный запрос выполнен успешно, заголовок ответа должен содержать код состояния HTTP/1.1 200.
Ведущий должен отправить допустимое сообщение GetResponse.
Элемент RelatesTo в сообщении GetResponse должен присутствовать и не должен быть пустым. Его значение должно соответствовать значению элемента MessageId из соответствующего сообщения Get.
Если HTTP-запросы или сообщения обмена метаданными, отправленные программой, не соответствуют этим требованиям к трафику, причина проблемы была успешно определена, и дальнейшие действия по устранению неполадок не необходимы. Переопределите программу, чтобы она создавала соответствующие сообщения и запросы и повторно тестирует программу.
Если источник проблемы по-прежнему не удается определить, обратитесь в службу поддержки Майкрософт за помощью. Перед обращением в службу поддержки соберите соответствующие файлы журналов, чтобы определить первопричину проблемы. Дополнительные сведения см. в разделе Включение трассировки WSDAPI.
Связанные разделы