Главное из них состоит в том, что драйвер реализован в среде NT executive и может вызывать кэш-менеджер NT непосредственно, что оптимизирует передачу данных. Например, когда сервер получает запрос на чтение большого количества данных, он вызывает кэш-менеджер для определения места расположения этих данных в кэше (или для загрузки этих данных в кэш, если их там нет) и для фиксации данных в памяти. Затем сервер передает данные непосредственно из кэша в сеть, минуя доступ к диску. Аналогично, при запросе на запись данных сервер вызывает кэш-менеджер для резервирования места для поступающих данных. Затем сервер пишет данные непосредственно в кэш. Записывая данные в кэш, сервер возвращает управление клиенту гораздо быстрее; затем кэш-менеджер записывает данные на диск в фоновом режиме (используя страничные средства менеджера виртуальной памяти).
Будучи драйвером файловой системы, сервер несколько более гибок по сравнению с его реализацией в виде процесса. Например, он может регистрировать функции завершения ввода-вывода, что позволяет ему получать управление немедленно после завершения работы драйверов нижнего уровня. Хотя сервер Windows NT реализован как драйвер файловой системы, другие серверы могут быть реализованы и как драйверы, и как серверные процессы.
Асинхронные вызовы обрабатываются сервером аналогично, с использованием пула рабочих нитей.
И редиректоры, и серверы, и транспортные драйверы могут быть в любое время загружены и выгружены.
Открытая архитектура сетевых средств Windows NT обеспечивает работу своих рабочих станций (и серверов) в гетерогенных сетях не только путем предоставления возможности динамически загружать и выгружать сетевые средства, но и путем непосредственного переключения с программных сетевых средств, ориентированных на взаимодействие с одним типом сетей, на программные средства для другого типа сетей в ходе работы системы. Windows NT поддерживает переключение программных средств на трех уровнях:
Для доступа к другим типам сетей в Windows NT, помимо встроенного, могут загружаться дополнительные редиректоры. Специальные компоненты Windows NT решают, какой редиректор должен быть вызван для обслуживания запроса на удаленный ввод-вывод. За последние десятилетия получили распространение различные протоколы передачи информации по сети. И хотя Windows NT поддерживает не все эти протоколы, она, по крайней мере, разрешает включать их поддержку.
После того, как сетевой запрос достигает редиректора, он должен быть передан в сеть. В традиционной системе каждый редиректор жестко связан с определенным транспортным протоколом. В Windows NT поставлена задача гибкого подключения того или иного транспортного протокола, в зависимости от типа транспорта, используемого в другой сети. Для этого во всех редиректорах нижний уровень должен быть написан в соответствии с определенными соглашениями, которые и определяют единый программный интерфейс, называемый интерфейсом транспортных драйверов (TDI).
TDI позволяет редиректорам оставаться независимым от транспорта. Таким образом, одна версия редиректора может пользоваться любым транспортным механизмом. TDI обеспечивает набор функций, которые редиректоры могут использовать для пересылки любых типов данных с помощью транспортного уровня. TDI поддерживает как связи с установлением соединения (виртуальные связи), так и связи без установления соединения (датаграммные связи). Хотя LAN Manager использует связи с установлением соединений, Novell IPX является примером сети, которая использует связь без установления соединения. Microsoft изначально обеспечивает транспорты - NetBEUI (NetBIOS Extended User Interface), TCP/IP, IPX/SPX, DECnet и AppleTalk.
Сетевые адаптеры поставляются вместе с сетевыми драйверами, которые раньше часто были рассчитаны на взаимодействие с определенным типом транспортного протокола. Так как Windows NT позволяет загружать драйверы различных транспортных протоколов, то производители сетевых адаптеров, использующие такой подход, должны были писать различные варианты одного и того же драйвера, рассчитанные на связь с разными протоколами транспортного уровня.
Чтобы помочь производителям избежать этого, Windows NT обеспечивает интерфейс и программную среду, называемые "спецификация интерфейса сетевого драйвера" (NDIS), которые экранируют сетевые драйверы от деталей различных транспортных протоколов. Самый верхний уровень драйвера сетевого адаптера должен быть написан в соответствии с рекомендациями NDIS. В этом случае пользователь может работать с сетью TCP/IP и сетью NetBEUI (или DECnet, NetWare, VINES и т.п.), используя один сетевой адаптер и один сетевой драйвер. Среда NDIS использовалась в сетях LAN Manager, но для Windows NT она была обновлена.
Через свою нижнюю границу драйвер сетевого адаптера обычно взаимодействует непосредственно с адаптером или адаптерами, которые он обслуживает. Драйвер сетевого адаптера, реализованный для среды NDIS, управляет адаптером не непосредственно, а использует для этого функции, предоставляемые NDIS (например, для запуска ввода-вывода или обработки прерываний). Таким образом, среда NDIS образует некую оболочку, которая позволяет достаточно просто переносить драйверы сетевых адаптеров из одной ОС в другую. NDIS позволяет сетевым драйверам не содержать встроенных знаний о процессоре или операционной системе, на которых он работает.
6.4.5. Совместимость Windows NT с NetWare
Совместимость сетевых операционных систем предполагает использование одинакового стека коммуникационных протоколов, в том числе и верхнего прикладного уровня. Протоколы верхнего уровня (NCP, SMB, NFS, FTP, telnet) включают две части - клиентскую и серверную. При взаимодействии двух компьютеров на каждой стороне могут присутствовать как обе части прикладного протокола, так и по одной его части, в зависимости от этого образуется или одна, или две пары "клиент-сервер".
Для клиентской части протокола верхнего уровня, реализованного в виде модуля операционной системы, используются разные названия - редиректор (redirector), инициатор запросов или запросчик (requester). Эти компоненты получают запросы от приложений на доступ к удаленным ресурсам, расположенным на серверах, и ведут диалог с сервером в соответствии с каким-либо протоколом прикладного уровня. Совокупность функций, которая может использовать приложение для обращения к редиректору, называется прикладным интерфейсом (API) редиректора.
Существующая версия Windows NT 3.51 имеет встроенную поддержку стека протоколов Novell, а именно протоколов IPX/SPX и клиентской части NCP. При разработке первой версии Windows NT 3.1 между Microsoft и Novell существовало соглашение о том, что редиректор, реализующий клиентскую часть протокола NCP, будет написан силами сотрудников Novell и передан Microsoft в течение 60 дней после выпуска коммерческой версии Windows NT 3.1. Однако первая версия редиректора от Novell появилась только спустя четыре месяца и обладала существенными ограничениями: не поддерживался полностью API редиректора NetWare, в частности, поддерживались только 32-х разрядные вызовы, что означало невозможность работы старых 16 разрядных приложений клиента NetWare.
Через некоторое время Microsoft разработала свою собственную версию редиректора для NetWare, проведя большую работу по освоению NCP. Этот вариант оказался гораздо лучше, однако и он имеет недостатки: в нем отсутствует поддержка входных сценариев NetWare и службы каталогов NetWare Directory Services. Отсутствие поддержки входных сценариев означает, что администратору сети будет сложно автоматизировать создание индивидуальной операционной среды NetWare для пользователей, использующих Windows NT в качестве клиентской машины серверов NetWare.
Организация, использующая NetWare, может добавить Windows NT в качестве:
Сеть с файловыми серверами различных типов (NetWare и Windows NT) порождает сложные технические проблемы. Даже если серверы используют одинаковые транспортные протоколы, в данном случае протокол IPX (в реализации Microsoft имеющий название NWLink), клиентским рабочим станциям все равно придется загружать два разных инициатора запросов. У клиента, работающего в среде MS-DOS, для этого может просто не хватить памяти.
Для смягчения перехода от NetWare к Windows NT Server разработано несколько инструментальных программ, в том числе утилита Migration Tool, которая включена в комплект поставки Windows NT Server. Эта утилита переносит учетную информацию пользователей (имена пользователей, ограничения и права доступа) и данные с одного или нескольких файловых серверов NetWare на сервер Windows NT. Migration Tool подбирает наилучшее соответствие между возможностями NetWare и возможностями Windows NT. Однако имеется ряд существенных различий в том, как обрабатываются такие вещи, как ограничения. В NetWare подобная информация обрабатывается для каждого пользователя в отдельности, а в Windows NT она общая для целого сервера.
Компания Beame and Whiteside Software создала первый NFS сервер для Windows NT, а также продукт под названием BW-Multiconnect, который превращает сервер Windows NT в сервер NetWare. Системы Windows NT с установленным продуктом BW-Multiconnect посылают широковещательные сообщения по протоколу SAP (протокол объявления сервисов и серверов по сети - Service Advertising Protocol, с помощью которого клиенты NetWare узнают о наличии в сети серверов и о тех услугах, которые они предоставляют). BW-Multiconnect должен облегчить сосуществование и миграцию от NetWare к Windows NT. Хотя он и может работать как единственный NCP-сервер сети, он не предназначен для этой роли, так как предоставляет лишь ограниченный набор утилит под Windows и DOS, и не обрабатывает входных командных файлов NetWare. Но когда в сети есть "настоящий" файловый сервер NetWare, то пользователи могут войти в этот сервер, выполнить системный входной командный файл, а затем подсоединиться к серверу Windows NT. Этот продукт превращает в сервер NetWare как Windows NT Server, так и Windows NT Workstation.