-
Протокол spx
Последовательный обмен пакетами SPX (Sequenced Packet Exchange) (рис. 44) обеспечивает возможность повторной передачи и тайм-аута, отсутствующие в IPX. Он ориентирован:
-
на доставку сообщений, возможно состоящих из нескольких пакетов;
-
на доставку нумерованных пакетов без идентификации границ сообщения;
-
на передачу последовательности пакетов с сохранением порядка поступления, но без дублирования.
Обмен нумерованными пакетами происходит с типом пакета 5 в межсетевом заголовке.
Поля «Идентификатор связи» предназначены для установления номера виртуального канала. При установлении канала SPX-источник создает пакет, в котором указывает свое значение идентификатора связи, в поле приемника это значение еще не известно и равно нулю. SPX-приемник, принимая пакет, назначает свой идентификатор, который помещается в первый ответный пакет. Специальный системный пакет-подтверждение не требуется. Обратите внимание на то, что все виртуальные каналы в этом случае «висят» на одном сокете IPX и только номера каналов позволяют их различить. Кроме того, сама фаза установки виртуального канала предельно упрощена, что позволяет классифицировать подобные протоколы как протоколы «быстрой выборки» или «виртуального вызова».
Рис. 44 — Формат пакета SPX
Далее наступает фаза передачи данных нумерованными пакетами, которые квитируются с помощью поля квитанции. В этом поле указывается номер ожидаемого пакета. Квитирование возможно на отдельный пакет (SPX) либо на целую последовательность пакетов (XSIS). Поле «Максимальный номер» служит для управления потоком данных и указывает на наибольший номер пакета, который принимающая станция может использовать. Значение этого поля увеличивается после каждого квитирования.
Поле «Тип потока данных» необходимо для выбора прикладной программы.
Основная разница между IPX и SPX состоит в том, что заголовки и дополнительные операции, предусмотренные в SPX, обеспечивают гарантированную доставку пакетов. Гарантированная доставка означает в данном случае выполнение некоторого числа повторных попыток передачи адресату запроса на установку соединения, пока число повторных передач не превысит некоторое, заранее зарезервированное, число переспросов (в этом случае передавшему запрос посылается уведомление). При пересылке нумерованного пакета также используется механизм повторной передачи. Таким образом, передающей стороне не нужно проверять доставку пакета. SPX будет уведомлять прикладную программу о состоянии передачи.
Обновленная версия протокола SPX называется SPX II. Одним из основных вопросов, который особенно беспокоил Novell при разработке транспортного протокола следующего поколения, был вопрос обеспечения совместимости с уже имеющимися продуктами; поэтому вместо того, чтобы дать ему совершенно новое имя, протокол назвали SPX II. Основное назначение SPX II состоит в использовании пакетов большего размера, реализации действительно оконного протокола и обеспечении поддержки унифицированного транспортного интерфейса API TLI (Transport Layer Interface).
Наиболее важно то, что SPX II обладает полной совместимостью с протоколом SPX. По сравнению с SPX протокол SPX II обладает повышенными возможностями в области обработки больших пакетов данных. Различные сети могут обрабатывать различные размеры пакетов. Многие сети могут обрабатывать пакеты с размером, превышающим 576 байт (размер пакета SPX и XSIS). Заголовок пакета SPX размером 42 байта оставляет для данных только 534 байта в одном пакете. Если нужно послать больше данных, то нужно подготовить и передать другой пакет SPX. При передаче большого объема информации наиболее эффективным является увеличение размера пакета.
Протокол SPX II автоматически использует преимущества тех сетей, которые допускают передачу пакета большего размера, т.е. подстраивает длину передаваемого пакета.
Другим реализованным в SPX II средством является механизм окна. Окно организуется, когда нужно передать несколько пакетов с одной квитанцией для всех пакетов. Число передаваемых пакетов может быть различным (это называется размером окна). Если один из пакетов не получен, запрос на этот пакет может быть возвращен передающему узлу.
Все рассмотренные механизмы позволяют уменьшить сетевой трафик и ускорить процесс передачи данных.
-
ODI и NDIS
Хотя в политике обеспечения межсистемного взаимодействия TCP/IP уделяется все большее внимание, существуют также другие стандарты, такие как AppleTalk и, конечно, OSI. Поэтому Novell разработала интерфейс ODI (Open Data-Link Interface), позволяющий сосуществовать на сервере или рабочей станции нескольким стекам протокола. Кроме того, в него недавно добавлена поддержка NDIS (Network Driver Interface Specification) — интерфейс для сетевых плат Microsoft. NDIS используется для связи различных систем. NDIS и ODI могут сосуществовать на рабочей станции, так что пользователям обеспечивается доступ и к сетям NetWare. Назначением NDIS и ODI является стандартизация интерфейса между драйверами и интерфейсными платами. Благодаря этому для каждого типа протокола, который вы хотите реализовать через плату, не требуются отдельные драйверы. Интерфейс ODI обеспечивает взаимодействие между платами сетевого интерфейса и различными протоколами. Когда драйверы платы сетевого интерфейса пишутся в соответствии со спецификацией ODI, они могут использовать один или более протоколов, таких, как AppleTalk и TCP/IP.
Компоненты ODI структурированы по уровням. Внизу расположены интерфейсы для различных типов сетевых интерфейсных плат. Верхнюю часть образуют протоколы, представляющие интерфейс с операционной системой NetWare. Расположенный между ними уровень LSL управляет трафиком между компонентами.
Для тех, кому требуется взаимодействие с системами, отличными от NetWare, ODI дает следующие преимущества:
-
одна плата сетевого интерфейса с различными стеками протоколов;
-
создается логическая сетевая плата, которая обрабатывает пакеты различных систем; эти пакеты могут посылаться по той же сетевой кабельной системе, подключенной к одной сетевой плате;
-
рабочая станция без перезагрузки может использовать другой стек протоколов;
-
ODI позволяет NetWare-серверам и рабочим станциям взаимодействовать со многими другими системами, использующими другие стеки протоколов, включая большие ЭВМ.
ODI стандартизирует разработку драйверов плат сетевых интерфейсов. Производителям не нужно больше беспокоиться о соответствии конкретного стека протоколов. Драйверы просто подключаются к уровню LSL (Link Suppirt Layer). LSL напоминает коммутационную панель, используемую для переключения на соответствующий стек протоколов.
LSL обеспечивает связь между драйверами (нижний уровень) и протоколами (верхний уровень). Уровень MPI (Multiple Protocol Interface) обеспечивает интерфейс для подключения стеков протоколов (таких, как AppleTalk, TCP/IP и IPX; в будущем будут доступны другие стеки протоколов, такие, как OSI и SNA). Уровень MLI (Multiple Link Interface) — это тот интерфейс, куда подключаются драйверы платы сетевого интерфейса. Драйверы устройств пишутся разработчиками плат сетевого интерфейса в соответствии со спецификацией LSL Novell. Эти драйверы называются драйверами MLID (Multiple Link Interface Driver).
Когда пакет попадает в плату сетевого интерфейса, он обрабатывается драйвером MLID платы и передается LSL. LSL определяет, в какой стек протокола должен попасть пакет, и направляет его этому протоколу. Пакет обычным образом передается через стек протоколов, где обрабатывается протоколами высокого уровня.
Спецификация NDIS (Microsoft Network Device Interface Specification) была разработана, чтобы предоставить пользователю сети доступ к различным протоколам, отделив эти протоколы от плат сетевого интерфейса. В соответствии с этим протоколом не требовалось ничего знать об интерфейсных платах. Здесь отсутствует специфический для плат интерфейс, а есть только общий интерфейс для протоколов. Чтобы использовать плату NDIS, вы устанавливаете плату и ее драйвер, загружаете все протоколы, которые хотите использовать, и связываете их с помощью команды NETBIND.