Реализация мультиплексирования протоколов в Windows NT
Windows NT представляет собой хороший пример операционной системы, мультиплексирующей несколько стеков протоколов - NetBEUI/SMB, TCP/IP и Novell IPX/NCP (компонента NWLink реализует протокол сетевого уровня IPX, а NWCS - протокол NCP, обеспечивающий доступ к файлам и принтерам).
Мультиплексирование может осуществляться на каждом из трех уровней коммуникационных средств: на нижнем уровне драйверов сетевых адаптеров, на уровне сетевых протоколов и на прикладном уровне (рисунок 8.1).
Рис. 8.1. Мультиплексирование в Windows NT
Для того, чтобы один сетевой протокол мог использовать несколько канальных протоколов (реализованных в виде драйверов сетевых адаптеров) и наоборот - один драйвер сетевого адаптера мог работать с несколькими сетевыми протоколами, в Windows NT на нижнем уровне используется мультиплексор NDIS (Network Driver Interface Specification), новая 32-разрядная версия 3.0 которого была разработана специально для Windows NT. NDIS выполняет не только функции мультиплексора, но и функции программной среды, изолирующей драйвер сетевого адаптера от аппаратуры, то есть от самого сетевого адаптера. NDIS предоставляет разработчику драйвера функции управления сетевым адаптером, например, функции ввода-вывода или обработки прерываний, что делает код драйвера более мобильным и переносимым. Windows NT поддерживает драйверы сетевых адаптеров не только в стандарте NDIS, но и в популярном стандарте ODI, используемом в сетях Novell NetWare.
На среднем уровне Windows NT вводит свой стандарт на интерфейс транспортных протоколов - TDI (Transport Driver Interface). Слово Driver говорит о том, что в Windows NT эти протоколы реализованы в виде драйверов системы ввода-вывода. Если редиректоры и транспортные протоколы написаны в соответствии с правилами TDI, то они могут образовывать произвольные связи между собой, то есть мультиплексироваться. Разработчикам приложений для доступа к функциям транспортного уровня Windows NT предлагает два популярных API - NetBIOS и Windows Sockets, которые в свою очередь обращаются к транспортным протоколам через интерфейс TDI.
Кроме собственных отдельных драйверов, разработанных в стандарте TDI (например, NetBEUI), Windows NT использует также модифицированную среду STREAMS, созданную в свое время знаменитым Денисом Ритчи для операционной системы Unix. Изменения среды STREAMS заключались в согласовании ее верхнего уровня с интерфейсом TDI. Это позволило использовать в Windows NT значительную часть кодов уже разработанных транспортных протоколов для этой среды.
На верхнем уровне в Windows NT имеется два мультиплексора - MUP и MPR, соответствующие двум сценариям доступа приложений к сетевым ресурсам в гетерогенной сети.
Первый сценарий состоит в том, что приложение обращается к операционной системе с запросом, указывая в явном виде имя сетевого ресурса без предварительного установления соединения. Такой запрос может быть выполнен при условии, что имя задано в соответствии с универсальным соглашением о именовании UNC (Universal Naming Convention).
В имени UNC сначала указывается имя сервера, предваряемое двумя слэшами, а затем сетевое имя разделяемого каталога и составное имя файла. Например, приложение может открыть файл, используя имя \\tandem\C$\Ann\article.doc, где tandem - имя компьютера, C$ - сетевое имя разделяемого каталога, назначенное пользователем или системой, \Ann\article.doc - составное имя файла относительно каталога C$.
Когда подсистема ввода-вывода Windows NT анализирует имя файла и обнаруживает, что оно является UNC-именем, то вызывается MUP (Multiple UNC Provider), которому передается это имя для дальнейшей обработки. В обязанности MUP входит определение принадлежности сетевого ресурса с заданным именем той или иной сети, инсталлированной в системе. Если обращение по этому имени происходит впервые, то MUP просто передает данное имя для опознания всем редиректорам, которые установлены в системе (их список имеется в базе конфигурации системы Registry). Каждый редиректор в соответствии с поддерживаемым им протоколом производит поиск ресурса по заданному имени и возвращает результат поиска мультиплексору MUP. MUP анализирует ответы редиректоров, и, если один из них распознал ресурс, передает ему запрос приложения для выполнения. Одновременно MUP кэширует соответствие имени сетевого ресурса определенному редиректору, чтобы не выполнять описанную процедуру каждый раз при поступлении запроса к этому ресурсу.
Реализован MUP в виде драйвера, в чем можно убедиться, просматривая список имен драйверов в группе Devices утилиты Control Panel.
В соответствии со вторым сценарием доступа приложение предварительно отображает сетевой ресурс на локальный ресурс (устанавливает соединение), а затем обращается к нему как к локальному ресурсу. Например, сначала разделяемый каталог \\tandem\C$ отображается на локальный дисковод F:, а затем приложение обращается к файлу F:\Ann\article.doc как к локальному файлу.
Процедура установления соединения в общем случае состоит из двух этапов:
- просмотр пользователем разделяемых сетевых ресурсов и выбор нужного ресурса,
- отображение выбранного ресурса на локальный ресурс.
Просмотр сетевых ресурсов - это необязательный этап, но он может существенно облегчить жизнь пользователю в большой сети, так как в этом случае пользователь не должен помнить имена всех серверов и разделяемых каталогов. В различных сетях сервис просмотра ресурсов организован по-разному. В сетях Novell NetWare 3.x, например, редиректор собирает список доступных серверов с помощью широковещательного протокола SAP, а в сетях NetWare 4.x редиректор для этой цели обращается с запросами к централизованной справочной службе NDS. В сетях Microsoft Windows NT список доступных серверов предоставляет специальная компонента - Computer Browser, а список разделяемых каталогов выясняется в результате диалога редиректора и сервера по протоколу SMB. В сетях TCP/IP при использовании сервисов ftp, telnet или www услуга по просмотру сетевых ресурсов вообще не предусмотрена, и пользователь должен явно задавать символьные имена ftp- или www-хостов, на которых хранятся нужные ему данные.
Процедуры просмотра ресурсов и установления соединения выполняются в Windows NT с участием еще одного мультиплексора прикладного уровня - маршрутизатора поставщиков услуг MPR (Multiple Provider Router). MPR, реализованный в виде динамической библиотеки DLL, выполняет общие для всех типов сетей действий по просмотру и отображению сетевых ресурсов в одном стиле. Действительно, пользователь видит, что в диалоговом окне Connect Network Drive утилиты File Manager перечень поддерживаемых сетей, набор имеющихся в них серверов и список разделяемых каталогов на серверах отображаются с помощью одних и тех же графических иконок, независимо от того, сеть ли это NetWare или Microsoft Windows. Другим примером может служить процедура дополнительной аутентификации при подключении к новой сети - она может быть выполнена одинаковым образом для сетей разных типов.
Другой основной функцией MPR является мультиплексирование связей между приложением и несколькими редиректорами. Если приложение не делает запрос на доступ к сетевому ресурсу в явном виде по UNC имени, а хочет сначала просмотреть и/или отобразить ресурсы, то такой запрос попадает сначала в MPR, который переправляет его нужному редиректору. Запросы от приложений могут явно указывать, с каким типом сети нужно работать - в этом случае MPR просто передает запрос указанному редиректору. Если же в запросе тип сети не указан, то MPR поступает так же, как и MUP - он передает запрос для опознания ресурса всем редиректорам и ждет от них ответы.
MPR взаимодействует с редиректорами не непосредственно, а через промежуточные компоненты, называемые сетевыми поставщиками услуг (network provider). Эти промежуточные компоненты обеспечивают согласование исходного интерфейса каждого редиректора с единым стандартным интерфейсом, с помощью которого MPR общается с редиректорами. Таким образом, для включения в Windows NT нового типа сети нужно разработать две компоненты - редиректор и сетевой поставщик услуг.
Разделение обязанностей между сетевым поставщиком услуг и редиректором - их внутреннее дело, главное, чтобы поставщик поддерживал стандартный интерфейс с MPR. Встроенный поставщик сети Microsoft для получения списка доменов, рабочих групп и компьютеров обращается к сервису Computer Browser, а список разделяемых каталогов на сервере получает с помощью редиректора. При отображении разделяемого каталога на локальный дисковод, например, \\tandem\C$ на F:, поставщик услуг сам создает в дереве имен объектов Windows NT новый объект - символьную связь с именем F:, которая указывает на редиректор сети Microsoft. После создания такой связи работа мультиплексора MPR по поддержанию доступа к файлам (и подкаталогам) каталога F:\ закончена. Теперь эти обращения будут обрабатываться системой ввода-вывода Windows NT, которая, разбирая имя файла, обнаружит, что диск F: - это не реальное устройство, а символьная связь, и вызовет для дальнейшей обработки указанный в символьной связи нужный редиректор.
