Послав диагностический пакет всем станциям, ваша программа получит несколько пакетов конфигурации, поэтому она должна заранее (перед посылкой диагностического пакета) зарезервировать достаточное количество блоков ECB и буферов для приема пакетов конфигурации.
Принятый пакет конфигурации состоит из стандартного заголовка IPX-пакета и блока данных. Принятый блок данных состоит из двух частей. Первая часть имеет фиксированную структуру, структура второй части зависит от конфигурации программного и аппаратного обеспечения станции, от которой пришел пакет конфигурации.
Приведем структуру первой части:
struct _RESPONSE { unsigned char MajorVersion; unsigned char MinorVersion; unsigned SPXDiagnosticSocket; unsigned char ComponentCount; };
В полях MajorVersion и MinorVersion находится соответственно верхний и нижний номер версии диагностического сервиса.
Поле SPXDiagnosticSocket содержит номер сокета, который должен быть использован для SPX-диагностики.
Самое интересное поле - ComponentCount. В нем находится количество компонентов программного и аппаратного обеспечения, информация о которых имеется в принятом пакете конфигурации.
Далее в принятом пакете сразу за полем ComponentCount следуют структуры, описывающие отдельные компоненты. Они могут быть двух типов - простые и расширенные. Первое поле размером в один байт имеет одинаковое значение в обоих типах структур - это идентификатор компонента. По идентификатору компонента можно однозначно судить о том, какая используется структура - простая или расширенная.
Простая структура и в самом деле несложна. Она состоит всего из одного байта идентификатора компонента:
struct _SIMPLE_COMPONENT { unsigned char ComponentID; };
Значениями поля ComponentID для простой структуры могут быть числа 0, 1, 2, 3 или 4:
| Значение поля ComponentID | Компонент |
| 0 | Драйвер IPX/SPX |
| 1 | Драйвер программного обеспечения моста |
| 2 | Драйвер сетевой оболочки рабочей станции |
| 3 | Сетевая оболочка |
| 4 | Сетевая оболочка в виде VAP-процесса |