Компоненты IPX IPX взаимодействует с сетью через драйвер платы локальной сети, поэтому для работы он должен загружаться в память с драйве- ром платы локальной сети, запрограммированным специально для ра- боты с IPX. На рабочей станции и на сервере это делается по-раз- ному. Использующие IPX приложения должны особым образом подготав- ливать пакеты и соблюдать процедуры инициации передачи данных с помощью IPX. Сам пакет состоит из 30-байтового заголовка и имеет рекомендованный максимум в 546 байт данных. Для каждого запроса IPX требуется также создать и инициализировать блок управления событием ECB (Event Control Block). Иногда (обычно для обработки приходящих пакетов информации) требуются подпрограммы обслужива- ния события ESR (Event Service Routine). Перед получением требуется открыть гнездо IPX. Гнездо IPX рекомендуется также открывать и перед передачей пакетов, хотя это и не требуется. После подготовки ECB и информации пакета в буфе- ре, можно начать передачу и получение пакетов. ECB имеет поля, которые отслеживаются и обновляются для определения статуса и по- ведения каждой выполняемой вами функции IPX. Структура заголовка IPX представлена ниже. Большинство чис- ловых значений в NetWare имеет порядок байт "старший-младший". Отметьте также специальные правила и исключительные ситуации. typedef struct IPXHeader { WORD checkSum /* старший-младший */ WORD length; /* старший-младший */ BYTE transportControl; /* используется маршрутизаторами сети */ BYTE packetType; /* тип связанного с пакетом средства */ IPXAddress destination; /* целевой адрес пакета */ IPXAddress source; /* исходный адрес пакета */ } В структуре IPXAddress 4 байта отводится под номер сети, 6 байт для узла (или платы интерфейса локальной сети) и 2 байта для номера гнезда. С учетом значения WORD размером 2 байта, значения BYTE длиной 1 байт и IPXAddress размером 12 байт общий размер IPXHeader в байтах составляет 2 + 2 + 1 + 1 + 12 + 12 = 30. Вы должны указать целевой адрес, но исходный адрес посылаемых паке- тов IPX будет заполнять сам. Чтобы клиент и сервер могли общаться друг с другом, они должны иметь возможность найти или уже знать гнездо, через кото- рое будут обмениваться данными. Если номер гнезда определяется при написании приложения, то он и будет каждый раз использовать- ся. Такой тип гнезда можно рассматривать как статическое гнездо, поскольку каждый раз используется одно и то же гнездо. Если есть опасение, что такой тип гнезда в приложении может привести к конфликту с использованием гнезда в другом приложении, вы можете разработать метод выделения динамического гнезда, которое можно использовать и объявлять об этом другим, чтобы они также не за- действовали это гнездо. Таким образом, если гнездо, которое вы обычно используете, задействовано другим приложением, вы можете просто использовать другое. Если вы хотите зарезервировать гнездо для исключительного использования вашим приложением, свяжитесь с отделом разработки Novell (Novell Development Relations) и запро- сите его номер.