Назад в раздел
Краткий Обзор ОТКРЫТОГО ИНТЕРФЕЙСА КАНАЛА СВЯЗИ (The Open Data-Link Interface, ODI).
- 1 -
Краткий Обзор ОТКРЫТОГО ИНТЕРФЕЙСА КАНАЛА СВЯЗИ
(The Open Data-Link Interface, ODI).
-------------------------------------------------
Обсуждение того, почему Novell поддерживает переход к ODI-спецификации:
- Сравнение специализированного IPX-драйвера фирмы Novell и
ODI-драйвера;
- краткий обзор ODI - архитектуры;
- и сравнение между ODI и NDIS фирмы Microsoft.
Разработано службой Маркетинга Novell-Лабораторий.
Версия 1.4.
ВВЕДЕНИЕ.
Этот документ представляет краткий обзор ODI с нескольких существен-
ных точек зрения. В первом разделе ODI будет сравниваться со Специализи-
рованным IPX. Второй раздел содержит краткий обзор архитектуры ODI, объ-
ясняет различные компоненты и как они взаимодействуют. Третий раздел -
сравнение ODI с NDIS фирмы Microsoft. В этом документе внимание будет
сфокусировано на том, чтобы помочь понять преимущества ODI и объяснять,
почему ODI - рекомендуемый фирмой Novell протокол.
Специализированные IPX-драйверы используются в большинстве установок
СИСТЕМЫ NETWARE начиная с СИСТЕМЫ NETWARE версии 2.0a, и до сих пор еще
имеют самое большое распространение для драйверов ЛВС различных типов.
Как и в любой другой технологии, эти драйверы создавались, чтобы служить
определенной цели - работать как мост между платами адаптера и сетевым
протоколом связи, соединяющим аппаратные средства с сетевой операционной
системой. Однако большое число компаний в настоящее время перешло к вы-
пуску больших и более сложным систем, где применение специализированных
IPX-драйверов имеет ограничения. Эта возрастающая потребность в гибкости
сетевой связи и породила разработку Открытого Интерфейса КАНАЛА СВЯЗИ
(The Open Data-Link Interface, ODI).
ODI - это драйвер канала связи, разработанный совместно фирмами App-
le Computer и Novell и объявлен к промышленному применению для работы с
сетями в 1989. Стратегическая цель ODI состoит в том, чтобы обеспечивать
прозрачную интеграцию сетей на транспортном, сетевом и канальном уров-
нях. ODI упрощает разработку сетевых драйверов для широкого разнообразия
сетевых адаптеров и набора сетевых транспортных протоколов. Результат -
более простой доступ к широкому разнообразию сетевых ресурсов без приме-
нения многократных соединений с сетью или дополнительных капиталовложе-
ний в аппаратные средства и программное обеспечение.
- 2 -
РАЗДЕЛ I: Сравнение Специализированного IPX и ODI.
IPX: как было дело.
Чтобы полностью понимать улучшенные функциональные возможности,
предложенные ODI-драйверами, вы должны сначала понять, как работает спе-
циализированный IPX-драйвер и в чем его ограничения.
Специализированный IPX-драйвер на рабочей станции, функционирующей
по управлением DOS, позволяет пользователям сети связываться с серверами
СИСТЕМЫ NETWARE по единственному протоколу.
В типичном случае установки IPX-драйвера на DOS-станции, пользова-
тель, чтобы соединяться с сетью, использует адаптер ЛВС и специализиро-
ванный IPX-драйвер, использующий IPX-протокол для связи с сервером СИС-
ТЕМЫ NETWARE. На стороне сервера другой адаптер ЛВС получает данные,
сформированные по IPX-протоколу, и обрабатывает входящую информацию.
Связь между этими двумя объектами в обоих направлениях осуществляется по
этому единственному каналу, использующему только IPX-протокол.
Это работает хорошо, если сервер целиком должен обрабатывать лишь
DOS- и OS/2-пользователей, использующих только IPX-протокол. Но сети
становятся все более и более сложными, сетевые администраторы теперь
должны связывать на одном сервере все большее и большее количество раз-
личных типов пользователей и целый набор протоколов. Что делать, если
вам надо связать в сеть рабочие станции DOS, AppleTalk и UNIX? Эта зада-
ча не может быть выполнена под старой IPX-архитектурой.
ODI: Как он поддерживает потребность в гибком протоколе.
Архитектура ODI разработана для того, чтобы радикально упростить
поддержку множества протоколов на одной сети. Вместо того, чтобы уста-
навливать отдельный драйвер и адаптер для каждого типа пользователя, ко-
торый должен работать в сети, ODI объединяет поддержку многих протоколов
в одном драйвере. Это означает, что один адаптер в сервере может поддер-
живать в сети различных пользователей.
ODI обеспечивает транспортную поддержку, так что компьютер Apple Ma-
cintosh (использующий AFP-протокол) может использовать сервер СИСТЕМЫ
NETWARE для постановки в очередь и печати документов, а также для хране-
ния файлов данных, которые могут использоваться совместно с рабочими
станциями других типов. Подобным же способом могут обслуживаться рабочие
станции UNIX, OS/2, TCP/IP и других типов.
ODI позволяет сети легко поддерживать большое количество различных
протоколов (типа IPX/SPX, TCP/IP и AppleTalk ). ODI также позволяет се-
тевым администраторам вводить в существующие сети новые протоколы (или
расширения к существующим протоколам) по мере того, как они становятся
доступными.
ODI также усиливает услуги на рабочей станции пользователя. При ис-
пользовании правильной комбинации ODI-адаптера/ драйвера, рабочая стан-
ция может иметь доступ как к услугам сервера СИСТЕМЫ NETWARE и главной
ЭВМ UNIX-системы без перезагрузки рабочей станции. И пользователю требу-
ется всего одна плата, чтобы поддерживать и IPX, и TCP/IP.
Таким образом, ODI позволяет многим типам рабочих станций связывать-
ся с сетевыми средствами одного и того же сервера. Кроме того, ODI поз-
- 3 -
воляет одному и тому же стеку протокола проходить через различные платы
ЛВС (например, в IPXмаршрутизаторе),что было ранее невозможно со Специа-
лизированным IPX.
ODI-драйверы также более просты в инсталляции и в переходе к новым
версиям, чем Специализированные IPX-драйверы: при использовании Специа-
лизированного IPX-протокола драйвер должен связываться с операционной
системой через NETGEN или SHGEN. Если бы пользователь захотел перейти к
новой версии драйвера, то он был бы должен заново устанавливать (переге-
нерировать) операционную систему. Этот процесс мог потребовать много
времени, особенно если принять во внимание, что операционная система
должна повторно устанавливаться точно так же, как она была установлена
прежде - и кто бы ни выполнял эту инсталляцию, он должен знать все зна-
чения системы, действующие по умолчанию, и назначения, которые были ус-
тановлены на исходной файловой системе, иначе система не будет функцио-
нировать полностью так же, как исходная система.
ODI облегчает эту задачу полностью благодаря тому, что позволяет
загружать новые и модифицированные драйверы в процессе работы. Просто
выгрузите существующий драйвер и загрузите новый, а рабочая файловая
система остается незатронутой.
ODI имеет множество преимуществ над Специализированным IPX. Вследс-
твие этих преимуществ, система OS/2 всегда была с ODI, а ODI для DOS
поставляется в составе Netware, начиная с версий v3.10 и v2.2 и позже.
Сравнение некоторых особенностей и возможностей этих двух систем пере-
числено ниже.
Сравнение Специализированного IPX и ODI.
Поддержка типов фреймов.
СПЕЦИАЛИЗИРОВАННЫЙ IPX:
Поддерживает
фреймы типа Ethernet:
802.3
Ethernet II
Token Ring
ODI:
Поддерживает
фреймы типа Ethernet:
802.2
802.3
Ethernet II
Snap
Token Ring:
802.5
802.2 Snap
ВЫГОДЫ ODI:
Один драйвер позволяет заказчику легко поддерживать многие типы
фреймов в одной и той же сети. Это открывает сеть для большего количест-
ва программ и платформ.
- 4 -
Поддержка Протокола.
СПЕЦИАЛИЗИРОВАННЫЙ IPX:
Поддерживает единственный стек протокола:
IPX
Appletalk ( на сервере )
ODI:
Поддерживает много стеков протокола одновременно:
IPX
TCP/IP
AppleTalk
OSI
... И т.д....
ВЫГОДЫ ODI:
Позволяет поддержку многих протоколов с помощью одной платы и одного
драйвера. Это обеспечивает более простое сопровождение при подключении
разнотипных пользователей на один сервер и доступ к ресурсам разнотипных
серверов.
Поддержка физических плат.
СПЕЦИАЛИЗИРОВАННЫЙ IPX:
Поддерживает до 4 физических плат в станции
ODI:
Поддерживает до 255 логических плат в сервере или столько физических
плат, сколько их будет установлено в ЭВМ.
ВЫГОДЫ ODI:
Обеспечивает поддержку большего числа плат в ЛВС. Позволяет сбалан-
сировать сетевую загрузку при использовании разнотипных плат.
Пропускная способность сети.
СПЕЦИАЛИЗИРОВАННЫЙ IPX:
Максимальный размер пакета = До 4 КБ
Только в степенях 2 ( 512, 1 КБ, 2 КБ, 4 КБ )
ODI:
Максимальный размер пакета = До 24 КБ в зависимости от физических
характеристик сети и ограничений платы.
ВЫГОДЫ ODI:
Существенно увеличивает общую сетевую пропускную способность.
- 5 -
Легкость сопровождения.
СПЕЦИАЛИЗИРОВАННЫЙ IPX:
Драйверы не могут выгружаться.
ODI:
Драйверы могут загружаться в процессе работы.
ВЫГОДЫ ODI:
Позволяет вам наращивать вычислительные возможности драйверов ЛО-
КАЛЬНОЙ ВЫЧИСЛИТЕЛЬНОЙ СЕТИ с минимальным вмешательством в работу сети.
Не требуется переустановка операционной системы.
Дополнительные возможности.
Также поддерживает:
Анализатор ЛВС для СИСТЕМЫ NETWARE;
Распаковку пакетов;
Локально управляемую адресацию узлов.
ВЫГОДЫ ODI:
ODI поддерживает сетевые услуги, которые Специализированный IPX в
настоящее время не поддерживает. Дополнительные сетевые средства, кото-
рые будут поставляться в дальнейшем, будут совместимы с ODI.
- 6 -
РАЗДЕЛ II: Краткий Обзор Архитектуры.
При применении ODI любой драйвер ЛВС может связываться с любым
ODI-стеком протокола. На приведенной ниже диаграмме показана модульная
структура ODI. Тремя компонентами ODI-технологии являются:
Драйвер Интерфейса Мульти-Связи (Multi-Link Interface Driver, MLID);
Уровень Поддержки Связи (Link Support Layer, LSL);
Стеки Протоколов (Protocol Stacks).
Драйвер Интерфейса Мульти-Связи MLID.
Драйвер Интерфейса Мульти-Связи MLID - сетевой драйвер интерфейсной
платы, разработанный по спецификации ODI MLI. MLID управляет связью меж-
ду платой ЛВС и Уровнем Поддержки Связи LSL. В MLID имеются две части:
Модуль Связи с Физической Средой (the Media Support Module, MSM) и Мо-
дуль Поддержки, Специфический для аппаратного средства модуль (Hardwa-
re-Specific Module, HSM). MSM - исходный текст, поставляемый фирмой No-
vell, который осуществляет стандартные функции драйверов ЛВС в ODI для
каждого стандартного типа физической среды. HSM - код, написанный разра-
ботчиком платы, чтобы обрабатывать специфические функции платы ЛВС.
Когда MLID получает пакет данных, он удаляет информацию доступа к
физической среде (MAC-заголовок) и передает пакет на Уровень Поддержки
Связи (LSL). Так как информация о передающей среде невидима для LSL,
этот модуль разрабатывается обеспечивающим истинную независимость от пе-
редающей среды.
Уровень Поддержки Связи LSL.
Уровень Поддержки Связи LSL - технологический уровень, который поз-
воляет единственному драйверу поддерживать многие протоколы и для одного
протокола использовать многие драйверы. Когда LSL получает пакет данных
из MLID, LSL действует как коммутатор, определяя,стек какого протокола
должен получить данный пакет. Эта функция "регулировщика уличного движе-
ния" устраняет потребность в написании раздельных драйверов для каждой
комбинации фрейм/протокол, таким образом существенно уменьшая число
драйверов, которые разработчик должен написать, а пользователь должен
устанавливать.
Стеки Протоколов.
Стек протокола получает пакеты информации из LSL и не знает ни сре-
ды, через которую были переданы эти пакеты, ни тип платы ЛВС, через ко-
торую эти пакеты прошли. После получения пакета, стек протокола удаляет
из пакета специфическую для данного протокола заголовочную информацию и
передает пакеты другим протоколам более высокого уровня или прикладным
программам. Наиболее популярные типы стеков протокола - IPX/SPX, TCP/IP,
AppleTalk, и OSI.
Модульная структура ODI - ключ к его гибкости. Эта модульность соз-
дает полную уверенность, что стеки протокола ничего не знают о физичес-
кой среде и что MLIDы ничего не знают о протоколах. Драйверы и стеки
протокола функционируют независимо друг от друга, делая возможным легко
добавлять к файловой системе новые среды или новые протоколы.
- 7 -
РАЗДЕЛ III: Сравнение NDIS и ODI.
NDIS - это совместная разработка фирм 3COM и Microsoft. Ниже приво-
дится рисунок, на котором сравниваются концептуальные архитектурные мо-
дели NDIS и ODI. Он послужит основой для понимания различий между этими
двумя спецификациями. (Примечание: это обсуждение не предполагает срав-
нения на уровне инженера-проектировщика, а дает лишь основные понятия
относительно важных различий между NDIS и ODI).
Имеются несколько отчетливых различий между ODI и NDIS, которые, в
конечном счете, влияют на ценность программ, написанных в этих двух раз-
личных спецификациях. Хотя обе спецификации реализуют схемы, поддержива-
ющие множественные протоколы при межсетевом взаимодействии, их различные
подходы в реализации этих схем приводят к драматическому различию в
действиях пользователя.
Фирма Novell при поддержке драйвера ориентируется на то, что эта
поддержка должна быть как можно более невидимой для пользователя. Имеет-
ся множество точек зрения, рассматривающих попытки сделать поддержку
драйвера невидимой для пользователя:
* Техническое соответствие: Действительно ли драйвер делает то, что и
предполагается, чтобы он делал: т.е. поддерживает множество протоко-
лов? Он делает это эффективно и элегантно?
* Гибкость: Могут ли поддерживаться дополнительные протоколы по мере то-
го, как они разрабатываются? А как относительно дополнительных сред
передачи, типа FDDI или ATM? Насколько трудно будет включить поддержку
новых изделий (программ) по мере их появления? Будут ли программы, ос-
нованные на новых средах передачи информации или на новых протоколах,
работать с программами, разработанными на существующих архитектурных
спецификациях?
* Совместимость Снизу вверх: Если вы - заказчик и вложили капитал в
программы, которые поддерживают ODI, будут ли будущие версии ODI про-
должать поддерживать эти программы или вы будете должны заменить драй-
веры? А как относительно совместимости с NDIS?
* Надежность: Как заказчик может определить, что программа, купленная со
стороны, действительно соответствует спецификациям либо ODI, либо
NDIS? Какая разница для заказчика? Хорошо ли будут взаимодействовать
различные программы от различных изготовителей, написанные в одних и
тех же спецификациях?
* Сроки Разработки: Как долго разрабатывать драйверы ODI? Что надо сде-
лать, чтобы уменьшить время разработки в будущем? Как это влияет на
доступность драйвера заказчику? Каковы преимущества "модульного" под-
хода над "ориентированным на среду" подходом? Каким образом ODINSUP
"камуфляж" (доступный через ODI) делает фактически ненужной разработку
драйвера NDIS?
Гибкость.
NDIS стеки протокола ориентированы на среду передачи: они содержат
знание этой среды в стеке протокола. Почти все стеки NDIS распознают
протоколы либо Ethernet 802.3, либо TokenRing 802.5, либо и тот и дру-
гой. Это означает, что драйверы для других сред типа Arcnet или ATM
должны "камуфлировать" эти среды, делая их похожими на 802.3 или 802.5.
- 8 -
В результате этого драйверы NDIS более трудны для разработки в случае
сред, отличных от Ethernet и TokenRing.
Для ODI это не так. ODI был разработан, чтобы прозрачно поддерживать
любую сетевую передачу, независимо от того, на основе какой среды она
происходит. Например, ODI может интегрировать в вашу уже действующую
сеть и FDDI, и беспроволочную технологию, и другие типы сред, без необ-
ходимости переписывать или изменять стеки протокола.
Метод, который NDIS использует для поддержки многих стеков протоко-
ла, может оказаться подходящим, особенно в случаях, где необходима ис-
тинная поддержка многих протоколов. Когда система использует множество
стеков протокола, NDIS устроен так, что он передает пакеты последова-
тельно от стека к стеку (через Администратора Протоколов), пока пакет не
будет распознан и принят. Это работает хорошо, если пакет данных всегда
должен идти к первому в цепочке стеку протокола, но если трафик равно-
мерно распределяется по нескольким стекам, или впоследствии добавляется
новый стек, тогда Администратор Протоколов будет тратить много времени
на переключение между стеками в поисках правильного маршрута для переда-
чи данных. А в этом случае стеки впереди цепочки будут обрабатываться
более эффективно, чем те, которые находятся в конце цепочки.
Чтобы ускорить производительность, фирма Microsoft предлагает загру-
жать протоколы в порядке сетевого использования трафика. Но когда к сети
добавляется новый протокол, это будет последний протокол, к которому бу-
дет передан пакет информации. Если вы собираетесь использовать этот но-
вый протокол для наибольшего количества сетевых передач, то, чтобы полу-
чить оптимальное быстродействие под NDIS, вы должны будете потребовать
перезагрузить все стеки протокола так, чтобы быть уверенным, что новый
стек загрузился в начале. В любом случае, заказчик должен знать NDIS и
"влезать" в систему NDIS, чтобы получить хорошую эффективность системы.
С другой стороны, философия ODI заключается в том,чтобы минимизиро-
вать вовлечение заказчика в систему: установите систему, и система забо-
тится о всех деталях передачи данных. Под ODI, LSL определяет и то, ка-
кой стек протокола должен получать каждый пакет информации, и то, каков
порядок загрузки стеков. Стек может добавляться в систему, и ODI автома-
тически поддерживает его. А загрузка и выгрузка драйверов с ODI более
проста, чем с NDIS: в NDIS загрузка драйвера выполняется в файле con-
fig.sys, в то время как в ODI - это TSR программа и, под DOS, обеспечи-
вается большая гибкость для загрузки и выгрузки драйверов.
Надежность.
Другой важный показатель для сравнения ODI и NDIS - это степень на-
дежности драйверов, написанных в каждой из этих двух спецификаций. В
настоящее время Microsoft поставляет разработчикам инструментальные
средства для тестирования, поэтому они могут проверять свои собственные
драйверы после того, как напишут их. Нет никаких независимых способов
тестирования или проверки для драйверов, так что заказчик на самом деле
не имеет никакого способа, чтобы узнать, как хорошо проверен и надежен
NDIS драйвер.
Это более рискованно по сравнению со стандартами, которые фирма No-
vell установила для ODI. Фирма Novell учредила специальный отдел, пред-
назначенный для того, чтобы проверять и сертифицировать драйверы, напи-
санные разработчиками. Это сделано, чтобы гарантировать, что драйверы
отвечают спецификации и выполняются в различных конфигурациях. В некото-
- 9 -
ром смысле, Novell-Лаборатория установила "планку", которую разработчики
должны преодолеть, чтобы их изделие называлось ODI драйвером.
Кроме того, если только ODI драйвер сертифицирован, Служба сопровож-
дения Novell рассматривает его, как будто это один из драйверов самой
фирмы Novell. Если заказчик, эксплуатирующий систему NetWare сталкивает-
ся со связанной с этим драйвером проблемой, Novell принимает участие в
решении проблемы. Однако, если это NDIS драйвер, Служба сопровождения не
имеет никакой документации, чтобы отыскать решение проблемы, и мало чем
может помочь заказчику.
С точки зрения пользователя это - важное различие. Если пользователи
основывают свои системы на ODI драйверах, они знают, что программы, ко-
торые они используют, уже продемонстрировали значительный уровень сов-
местимости с СИСТЕМОЙ NETWARE и, если что -нибудь не так, будут поддер-
живаться фирмой. Если же они имеют дело с NDIS, они рассчитывают на
собственную удачу. И мы имеем сведения, что в значительной степени из-за
этих показателей надежности большое количество крупных проектов приняли
за стандарт применение ODI драйверов.
ODI драйверы сертифицируются Novell Лабораторией; другие драйверы не
отвечают этому требованию.
Совместимость Снизу вверх.
Другое важное различие между двумя спецификациями заключено в проб-
леме совместимости снизу вверх. Например, рассмотрим пользователя, рабо-
тающего с NDIS драйверами v2.0, который хочет нарастить свои вычисли-
тельные возможности, перейдя к Windows NT. А NT требует драйверов v3.0.
Этот переход представит целую проблему, если изготовитель платы не раз-
работал драйвер v3.0 для имеющейся у заказчика платы.
По иронии судьбы, т.к. ODI поддерживает любой стек протокола, ODI
драйвер для определенной платы может использоваться также и для того,
чтобы соединяться в NT через shim, называемый ODINSUP. Этот модуль поз-
воляет пользователю связываться с немодифицированным стеком протоколов
NDIS через ODI драйвер. ODINSUP обсуждается более подробно в следующем
разделе.
С точки зрения пользователя фирмы Novell, ODI обеспечивает полную
совместимость снизу вверх, делающую наращивание вычислительных возмож-
ностей гораздо более простой. Опять же, как только ODI драйвер установ-
лен, все изменения системы, а это могут быль и новые стеки протокола, и
новые среды передачи информации, и программы, которые поддерживают новые
ODI спецификации, - не имеют никакого влияния на совместимость драйвера.
Это существенно уменьшает поддержку пользователей и бремя сопровождения.
Время выпуска на рынок.
До ввода в эксплуатацию ODI разработка драйверов ЛВС обычно занимала
от шести до восьми недель. Вследствие модульной архитектуры ODI, это
время от начала разработки до выпуска на рынок значительно уменьшилось.
Как мы уже ранее подчеркнули, ODI драйверы состоят из двух частей:
Модуль Поддержки Среды (Media Support Module, MSM) и СПЕЦИФИЧЕСКИЙ ДЛЯ
АППАРАТНОГО СРЕДСТВА Модуль (Hardware-Specific Module HSM). В прошлом,
когда разработчики писали драйверы, они были должны создавать коды дос-
- 10 -
тупа к протоколу, обслуживания платы и обращения к среде передачи. Чтобы
упростить разработку драйвера, в настоящее время фирма Novell, как часть
фирменного Комплекта Разработки Драйвера ЛВС (the Novell LAN Driver De-
velopment Kit), поставляет исходные тексты модулей связывать с различны-
ми средами (MSM). Это снижает бремя, которое несут разработчики по коди-
рованию драйверов: теперь они могут сосредоточиться на создании специфи-
ческих для аппаратного средства частей драйвера и добавления любых фа-
культативных функций. Драйверы ODI MSM/HSM могут быть разработаны за 2-3
недели.
Разработчики микросхем также помогли сделать разработку драйверов
еще более простой, чем это было в прошлом. Главные кремниевые разработ-
чики (включая National, Intel, Texas Instruments и AMD) имеют типовые
проекты, исходные тексты программного обеспечения, перечни материалов и
другие методические пособия, необходимые для построения программ, кото-
рые поддерживают ODI. Эти методические материалы доступны разработчикам,
которые используют их микросхемы.
Это упрощение процесса разработки дает пользователям выгоду двумя
способами:
* Драйверы становятся более стандартизированными, более простыми в
создании и более простым в тестировании. В конечном счете, это означает,
что они будут менее дорогими в производстве, что приведет к более деше-
вым и более доступным для пользователей программным продуктам.
* Поскольку все большая и большая часть программирования, связанного
с сетевыми интерфейсами, становится стандартизированной, разработчики
могут сосредоточить свое внимание на разработке больших функциональных
возможностей и эффективности своих программ. Более быстрый выход прог-
рамм на рынок означает, что ошибки будут обнаружены и "залатаны", а это
значит, что повышающие эффективность средства (типа разрывающегося паке-
та NLM) будут интегрированы более быстро и с меньшим временем простоя,
чем было возможно до этого.
ODINSUP.
Поскольку совместимость с другими системами является частью политики
фирмы Novell, ODI поддерживает NDIS. Модульная архитектура ODI позволяет
пользователям поддерживать стеки протокола NDIS. Модуль, называемый
ODINSUP, позволяет стекам протокола NDIS в немодифицированный виде вы-
полняться совместно с ODI LSL и обмениваться информацией с ODI драйвером
ЛВС (посмотрите, пожалуйста, на рисунок на следующей странице). Поэтому
транспортные сетевые протоколы многих изготовителей сетевых средств, та-
ких как NetBEUI фирмы IBM, DEC's LAT или 3COM's XNS, могут выполняться с
помощью общих спецификаций (драйверов) Data-Link. Эта особенность обес-
печивает два значительных преимущества:
* Она позволяет заказчикам интегрировать сетевые средства многих из-
готовителей, сохраняя предыдущие капиталовложения. Поскольку ODI поддер-
живает стеки NDIS, заказчики могут стандартизировать свои сетевые средс-
тва на базе ODI-драйверов, зная, что эти драйверы будут поддерживать все
их потребности работы с сетями, независимо от того, разработаны ли они
на NDIS или каком-либо другом сетевом транспортном протоколе.
* Возможность доступа к NDIS через ODINSUP также означает, что раз-
работчики могут разрабатывать программы) на базе ODI-спецификаций, зная,
что эти драйверы будут способны поддерживать стеки протокола NDIS. Эта
- 11 -
особенность значительно облегчает разработчику бремя по кодированию
драйвера ЛВС.
Модульная архитектура ODI позволяет интегрировать новые технологии,
включая поддержку для стеков NDIS и FDDI, без прерывания текущей работы
сети.
Резюме.
ODI разработан на основе модульной архитектуры, что делает его дейс-
твительно независимым от среды и протокола. ODI обеспечивает большую
гибкость в конфигурировании сетевого интерфейса, более эффективно ис-
пользует ресурсы и сохраняет ранее сделанные капиталовложения в аппарат-
ные средства и другие сетевые ресурсы. При примени ODI интеграция новых
технологий может быть выполнена легко и без прерывания текущей работы.
ODI драйверы сертифицируются Novell Лабораториями и, следовательно, яв-
ляются очень надежными и совместимы с предыдущими версиями ODI специфи-
каций. Благодаря исходному тексту, поставляемому фирмой Novell, время
разработки драйвера уменьшилось; это означает что заказчики в более ко-
роткие сроки получат программы более высокого качества. ODI драйверы с
помощью ODINSUP могут взаимодействовать со стеками NDIS, позволяя заказ-
чикам принять в качестве стандарта всего один тип драйвера. Вследствие
всех этих преимуществ, фирма Novell рекомендует программы, написанные в
ODI.
Как переключиться на ODI.
Вследствие всех этих преимуществ, фирма Novell в составе операцион-
ной системы NETWARE v4.0 поставляет только ODI драйверы. Более старые
специализированные IPX драйверы подлежат постепенному изъятию- Novell
Лаборатории, начиная с июня 1992 г., прекратили сертификацию специализи-
рованных DOS IPX драйверов. В настоящее время имеются ODI драйверы для
всех популярных адаптеров ЛВС. См. приложение с перечнем протестирован-
ных драйверов.
Чтобы помочь в переходе от специализированных IPX драйверов к ODI на
автоматизированных рабочих местах DOS, Novell поставляет утилиту (имеет-
ся в поставляемых для пользователя АРМ комплектах), называемую WSUPGRD,
которая предназначается для использования администратором системы, чтобы
перейти на большом количестве аналогично конфигурированых рабочих мест.
Эта утилита предназначена для выполнения из системного сценария входа в
систему. Она будет просматривать специализированный файл IPX.COM на ра-
бочей станции, с помощью утилиты SHGEN определять, с каким драйвером он
компоновался и какие были выбраны опции аппаратных средств. Затем она
создаст ссылку на инсталляционный файл, созданный системным администра-
тором, для того, чтобы выбрать соответствующий ODI драйвер, а затем ус-
тановить этот драйвер вместе с его Модулем поддержки связи (ODI Link
Support Layer Module, LSL) и соответствующим файлом NET.CFG (которые все
должны быть конфигурированы и определены системным администратором).Эта
утилита предназначается для использования в обновлении больших локальных
вычислительных сетей, где рабочие станции с одними и теми же марками
адаптеров ЛВС также подобны и в конфигурации (обычно при контроле адми-
нистратора системы). Например, когда командные строки в файлах autoe-
xec.bat подобны,эта утилита будет легко обновлять все подобные адаптеры.
|
|
 |
|
