Встроенные сетевые компоненты

Хотя за поддержку сети отвечают многие компоненты Windows NT, наиболее важны из них те, которые имеют в Microsoft самую долгую историю: редирек­тор и сетевой сервер. Как и в оригинальной MS-NET, редиректор посылает ло­кально выдаваемые запросы удаленному серверу, а сервер принимает и обра­батывает их.

Конечно, кроме названий, мало что в сервере или редиректоре напомина­ет прежнее программное обеспечение. Первые варианты были написаны на языке ассемблера и выполняли роль надстройки над MS-DOS. Несмотря на то, что новые сервер и редиректор встроены в Windows NT, они не зависят от аппа­ратной архитектуры, на которой выполняется ОС. Они написаны на языке С и реализованы в виде загружаемых драйверов файловых систем, которые могут загружаться и выгружаться динамически. Кроме того, они могут сосуществовать с серверами и редиректорами других фирм.

Реализация редиректора и сервера в виде драйверов файловой системы де­лает их частью исполнительной системы NT. В связи с этим они имеют доступ к специализированным интерфейсам, которые предоставляет драйверам диспет­чер ввода-вывода. В свою очередь, данные интерфейсы разрабатывались с учетом потребностей сетевых компонентов. Эта возможность доступа к интерфейсам драйвера плюс способность прямого вызова функций диспетчера кэша вносят существенный вклад в повышение производительности сервера и редиректора.

Послойная модель драйвера диспетчера ввода-вывода напоминает есте­ственное расположение сетевых протоколов один над другим. Поскольку редирек­тор и сервер являются драйверами, под ними может быть расположено столько слоев драйверов протоколов, сколько необходимо. Такая структура обеспечивает модульность сетевых компонентов и создает эффективные переходы от уровня ре­директора или сервера вниз к транспортным и физическим уровням сети.

Редиректор

Сетевой редиректор предоставляет средства, необходимые машине с Windows NT для доступа к ресурсам на другой машине в сети. Редиректор Windows NT может осуществлять доступ к удаленным файлам, именованным каналам и прин­терам. Благодаря тому, что в нем реализован протокол SMB, редиректор может работать с существующими серверами MS-NET и LAN Manager, обеспечивая Windows NT доступ к системам MS-DOS, Windows и OS/2. Механизмы защиты гарантируют, что данные Windows NT, совместно используемые через сетевое соединение, будут защищены от несанкционированного доступа.

Будучи драйвером файловой системы, редиректор работает, как и любой другой драйвер. Когда он загружается в систему, его процедура инициализации создает объект-устройство (под названием \Device\Redirector) для представления редиректора в системе. Кроме того, процедура инициализации определяет коды функций, поддерживаемых редиректором, и записывает точки входа драйвера (процедуры распределения) для этих операций. Когда диспетчер ввода-вывода получает сетевой запрос ввода-вывода, он создает IRP и вызывает одну из про­цедур распределения редиректора, передавая ей этот пакет. После того как реди­ректор обработает запрос (посредством обращения к сети), IRP завершается, и результаты возвращаются вызывающей программе.

В промежутке между посылкой запроса и получением ответа у редиректо­ра есть одна основная задача: предоставить "файловую систему", которая ведет себя как локальная файловая система, хотя и работает с ненадежным по своей природе носителем (сетью). Физическое соединение между двумя компьютера­ми нарушается значительно чаще, чем связь между компьютером и его жестким диском или приводом гибких дисков. При нарушении связи редиректор отвеча­ет за ее восстановление, если это возможно, или за корректную обработку сбоя, позволяющую приложениям повторно выполнить текущую операцию. Для этой цели редиректор применяет различные методы. Например, при потере связи с сервером он просто восстанавливает ее. Кроме того, он запоминает, какие фай­лы были открыты и при определенных обстоятельствах открывает их снова. (Драйверы транспортов, лежащие ниже редиректора, обеспечивают надежность передачи данных на уровне битов.)

Как и другие драйверы файловых систем, редиректор должен соответство­вать асинхронной модели ввода-вывода, поддерживая выполнение асинхрон­ных запросов ввода-вывода. Когда запрос пользовательского режима выдается асинхронно, редиректор должен вернуть управление немедленно, независимо от того, завершена ли удаленная операция ввода-вывода. В большинстве случаев удаленный запрос ввода-выво­да не завершается сразу же, поэтому, вернув управление вызывающей програм­ме, редиректор должен ждать его завершения. Парадоксально, но код драйвера всегда активизируется вызывающим потоком, в контексте этого потока. У него нет адресного пространства своих потоков или каких-либо еще. Каким же об­разом драйвер может вызвать процедуру ожидания?

Данная проблема не уникальна для редиректоров; большинство драйверов файловых систем сталкиваются с той же дилеммой. В первоначальном варианте системы ввода-вывода драйверы файловых систем, которым нужно было вы­полнять обработку в своем собственном контексте, просто создавали процесс режима ядра, связанный с драйвером, и использовали его потоки для асинхрон­ной обработки. Однако такой подход оказался слишком дорогим с точки зрения использования системной памяти. Поэтому было придумано новое решение.

У Windows NT имеется специальный системный процесс для инициализа­ции системы во время ее загрузки. В этом процессе есть несколько рабочих потоков, ожидающих в цикле поступления запросов от драйверов и других ком­понентов исполнительной системы, которые и выполняют асинхронную рабо­ту, Если для выполнения асинхронной работы драйверу нужен поток, он поме­щает задание в очередь этого специального процесса, прежде чем вернуть уп­равление вызывающей программе. Поток системного процесса пробуждается и выполняет операции, необходимые для обработки запроса ввода-вывода и за­вершения IRP исходной вызывающей программы.

Для выполнения своих задач редиректор отправляет и принимает SMB. Протокол SMB является прото­колом прикладного уровня, как показано на рис. 9-6.

Интерфейс, через который редиректор посылает свои SMB, называется интерфейсам драйвера транспорта (transport driver interface, TDI). Редиректор вызывает TDI для передачи SMB различным драйверам транспорта, загруженным в систему. Для того, чтобы вызвать функции TDI, редиректор должен открыть для связи с удаленной машиной канал, называемый виртуальным контуром (virtual circuit), и затем посылать SMB через этот контур. Редиректор поддерживает по одному виртуальному контуру для каждого сервера, с которым связана Windows NT, и мультиплексирует все запросы к данному серверу в один контур. Транспорт­ный уровень, располагающийся под редиректором, определяет способы реализа­ции виртуального контура и посылает данные через сетевое соединение.

Помимо повышения надежности, от переписанного редиректора также требовалось обеспечить стопроцентную совмести­мость с существующим протоколом SMB. Для выполнения этих требований он использовал все тот же протокол для передачи сообщений серверам старых мо­делей (MS-NET и LAN Manager). Сохранение этого базового протокола позволя­ет Windows NT взаимодействовать с серверами Windows, OS/2 или MS-DOS, работающими под LAN Manager. Для обмена данными между системами Windows NT был расширен базовый протокол SMB для поддержки распространенных опе­раций системы ввода-вывода NT. Например, расширенный протокол способен поддерживать такие специфичные для NT операции, как открытие файла с дос­тупом для удаления, открытие каталога, присоединение к файлам списков управ­ления доступом (ACL) в целях их защиты и выполнение операций опроса для получения информации о файлах. В дополнение к этому новый протокол SMB передает строки в символах UNICODE, чтобы гарантировать правильную пере­дачу символов иностранных языков.

Сервер

Как и редиректор, сервер Windows NT создавался так, чтобы обеспечить стопро­центную совместимость с существующими протоколами SMB MS-NET и LAN Manager. Полная совместимость позволяет серверу обрабатывать запросы, при­ходящие не только от систем Windows NT, но также и от других систем, на ко­торых работает программное обеспечение LAN Manager. Подобно редиректору, сервер реализован в виде драйвера файловой системы.

Может показаться странным, что нечто, называемое "сервером", не реали­зовано в виде серверного процесса. Резонно было бы предположить, что сете­вой сервер должен работать как защищенная подсистема — процесс, чьи потоки ожидают поступления запросов из сети, выполняют их и возвращают результаты обратно в сеть. Но решено было реализовать сервер как драйвер файловой системы. Хотя сервер не является драйвером в обычном смысле и не управляет какой-либо файловой системой, использование модели драйвера имеет свои преимущества по сравнению с реализацией сервера в виде процесса.

Основным преимуществом является то, что сервер находится в исполни­тельной системе NT и может непосредственно вызывать диспетчер кэша для оп­тимизации передачи данных. Например, если сервер получает запрос на чтение большого объема данных, он вызывает диспетчер кэша, чтобы найти в кэше нуж­ные данные (или загрузить с диска, если их нет в кэше) и зафиксировать их в памяти.

Рис. 9-6. Использование протокола SMB.

Затем сервер передает данные в сеть непосредственно из кэша, избегая лишних обращений к диску или копирования. Аналогично, при поступлении за­проса на запись данных сервер вызывает диспетчер, чтобы выделить для посту­пающих данных место в кэше и получить адрес этого места. Затем сервер запи­сывает данные непосредственно в кэш. Благодаря записи данных в кэш, а не на диск сервер может быстрее вернуть управление вызывающей программе; дис­петчер кэша затем пересылает данные на диск в фоновом режиме (используя средства подкачки страниц диспетчера виртуальной памяти).

Вызывая диспетчер кэша, сервер фактически берет на себя некоторые обя­занности диспетчера ввода-вывода для упрощения обработки. Кроме того, сер­вер играет роль диспетчера ввода-вывода, создавая собственные IRP и посылая их непосредственно драйверам NTFS, FAT и HPFS, Он может принять решение непосредственно пересылать данные в кэш и из кэша, не создавая IRP. Если бы сервер был подсистемой пользовательского режима (или даже режима ядра), ему пришлось бы для обработки поступающих запросов вызывать сервисы вво­да-вывода NT, что связано с несколько большими накладными расходами.

Будучи драйвером файловой системы, сервер также более гибок, по срав­нению с процессом. Например, он может зарегистрировать процедуру заверше­ния ввода-вывода, что дает ему возможность быть вызванным сразу же, как толь­ко драйверы нижнего уровня завершат обработку, и выполнить необходимые завершающие действия. Несмотря на то, что сервер Windows NT реализован в виде драйвера файловой системы, другие серверы могут быть как драйверами, так и серверными процессами.

Подобно редиректору, сервер использует начальный системный процесс для обработки асинхронных операций ввода-вывода и тех периодически встре­чающихся "дорогих" операций, выполнение которых не требует максимальной скорости — например, открытия файла. Операции, требующие высочайшей ско­рости выполнения, такие как чтение или запись, исполняются, если возможно, непосредственно в драйвере, чтобы избежать накладных расходов, связанных с переключением контекста. Несмотря на необходимость переключения контек­ста, использование начального системного процесса для выполнения сетевых операций позволяет серверу при необходимости ждать у описателей объектов или генерировать страничные ошибки, чего он не может сделать, выполняясь в контексте другого потока на повышенном IRQL. Возможность генерации стра­ничных ошибок означает, что меньшая часть кода сервера должна оставаться резидентной в памяти.

При запуске Windows NT диспетчер ввода-вывода загружает те драйверы, которые требуются на ранних стадиях загрузки системы (драйверы файловой системы и диска, видеодрайвер, драйверы мыши и клавиатуры). После того, как процесс загрузки системы продвинется достаточно далеко, чтобы переключить­ся из режима ядра в пользовательский режим, для загрузки остальных драйве­ров, включая редиректор, сервер и драйверы транспортов, вызывается контрол­лер сервисов. Он загружает эти драйверы, вызывая сервисы системы ввода-вы­вода, которые копируют драйверы в память и выполняют процедуры их иници­ализации. Процедура инициализации каждого драйвера создает объект-устрой­ство и помещает его в пространство имен диспетчера объектов. Контроллер сер­висов можно также вызвать в любой момент работы системы для загрузки и вы­грузки сетевых серверов или для запуска и останова сетевых сервисов.

62. Открытая архитектура. Доступ пользовательского режима:

маршрутизатор для API Wnet, многосетевой UNC для файлового I\O Win32.