Сетевая архитектура Windows NT

Эта глава посвящена рассмотрению сетевой архитектуры ОС Windows NT. Рассматривается соответствие сетевой архитектуры модели OSI, описаны сетевые интерфейсы, сетевые компоненты, их предназначение и взаимосвязи. Обзор сетевой архитектуры позволит определить, через какие сетевые компоненты и в какой последовательности проходят данные приложений перед тем, как попасть в сеть.
Windows NT содержит механизмы динамической загрузки и выгрузки встроенной сетевой поддержки, те же самые механизмы могут использоваться для загрузки и выгрузки сетевого программного обеспечения других производителей. После инсталляции сетевое программное обеспечение становится неотъемлемой частью операционной системы, например, сетевые файловые системы, драйверы сетевых протоколов и драйверы сетевых устройств являются расширением подсистемы ввода/ вывода исполнительной системы. Таким образом, в Windows NT сетевое программное обеспечение может задействовать внутренние интерфейсы, предоставляемые компонентами исполнительной системы, ядром и HAL, тем самым, увеличивая свою производительность.
Дополнительная информация о встроенных сетевых компонентах может быть получена при непосредственном анализе реестра Windows NT, а точнее его ключа HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services, где, помимо прочих сервисов ОС, хранится информация о сетевых компонентах:

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

Соответствие сетевой архитектуры Windows NT модели OSI

Чтобы помочь производителям в стандартизации и интегрировании их сетевого программного обеспечения, Международная организация по стандартизации (ISO) определила программную модель пересылки сообщений между компьютерами - модель соединения открытых систем (Open System Interconnection reference model, OSI). В модели определены семь уровней программного обеспечения.
Сетевой запрос должен спуститься до самого нижнего уровня на клиентской машине, затем он передается по физическому носителю и вновь поднимается на серверной машине до уровня, который его поймет и обработает. Каждый уровень иерархии считает, что он общается с аналогичным уровнем на другой машине и использует некоторый стандартный протокол. Набор протоколов, в соответствии с которыми запрос проходит вниз по уровням и обратно, называется стеком протоколов.
На рис. 17 представлен общий вид сетевых компонентов Windows NT, а также их соответствие уровням модели OSI. Модель OSI далеко не всегда точно соответствует
коммерческим сетевым программным продуктам, реальные программные модули которых объединяют несколько уровней модели OSI или разбивают один уровень на несколько.

Рис.17. Соответствие сетевой архитектуры ОС Windows NT модели OSI

Задача каждого уровня состоит в том, чтобы предоставить обслуживание верхним уровням, абстрагируясь от того, как реализовано это обслуживание на нижних уровнях. Далее приводится краткое описание этих уровней:

1. Физический уровень. Физический уровень является самым нижним уровнем в модели OSI. Задачи этого уровня связаны с отправкой и получением неструктурированного потока бит по физической среде передачи. Он характеризует электрический/ оптический, механический и функциональный интерфейс к физической среде. В Windows NT физический уровень реализуется сетевой картой, ее трансивером, и средой передачи данных, к которой она присоединена. Для сетевых компонентов, которые используют последовательный порт, физический уровень может также включать низкоуровневое сетевое программное обеспечение, которое определяет, как поток последовательных бит делится на пакеты данных.
2. Канальный уровень. Пересылает низкоуровневые кадры данных, ожидает подтверждения их получения и повторяет передачу потерянных кадров.
В официальной терминологии модели OSI группа бит, посылаемая канальным уровнем, называется physical layer service data unit (единица данных, обслуживаемая физическим уровнем), на практике эту группу бит называют фреймом.
Канальный уровень делится на два подуровня: подуровень управления логической связью (Logical Link Control, LLC) и подуровень управления доступом к среде (Media Access Control, MAC). LLC управляет взаимодействием с верхним сетевым уровнем и обеспечивает безошибочную передачу фреймов от одного узла к другому. Этот уровень отвечает за установление и завершение логической связи, контроль последовательности фреймов, подтверждение приема фрейма и повтор передачи неподтвержденных фреймов. В сетевой архитектуре Windows NT функции подуровня LLC реализуются в транспортных драйверах (transport driver).
MAC подуровень управляет доступом к среде передачи, проверяет ошибки во фреймах, распознает адреса полученных фреймов. Подуровень MAC обеспечивает стандартные интерфейсы для сетей Ethernet (со случайным коллективным доступом с контролем несущей и обнаружением конфликтов, Carrier Sense Multiple Access with Collision Detection, CSMA/CD), для сетей, где используется передача маркера на общей шине (ArcNet) и в кольце (Token Ring). В сетевой архитектуре Windows NT функции подуровня MAC реализуются в сетевой карте.
3. Сетевой уровень. Сетевой уровень контролирует операции подсети. Он решает, какой физический путь должны пройти данные в зависимости от условий передачи, приоритетов сервиса и других факторов. Он отвечает за маршрутизацию, контроль интенсивности трафика, фрагментацию пакетов, распознавание адресов и межсетевой обмен. Это самый низкий из уровней, понимающих топологию сети, то есть физическую конфигурацию машин в ней, тип физических соединений между ними и ограничения пропускной способности, длины используемых кабелей и т.д. .
Сетевой уровень имеет дело с пакетами, которые могут быть меньше или больше чем фрейм. Если пакет больше, чем фрейм, то сетевой уровень разбивает его на несколько фреймов, и собирает их при получении. Если пакет меньше фрейма, то сетевой уровень объединяет несколько пакетов во фрейм, и разбивает этот фрейм на пакеты при получении.
В модели Windows NT сетевой и транспортный уровни реализуются в транспортных драйверах, иначе называемых драйверами протоколов верхнего уровня (protocol driver). Windows NT поставляется со следующими транспортными драйверами: TCP/ IP, IPX/SPX, NetBEUI, AppleTalk и DLC.
4. Транспортный уровень. Транспортный уровень имеет дело с сообщениями, которые могут быть больше или меньше, чем пакеты. Транспортный уровень гарантирует безошибочную доставку сообщений, в нужной последовательности, без потерь и повторов.
Если стек протоколов не включает подуровень LLC, и если сетевой уровень ненадежный и поддерживает передачу дейтаграмм (например, уровень IP в стеке TCP/IP или IPX в NWLink), то транспортный уровень должен включать контроль последовательности пакетов и их подтверждение, а также повторную передачу неподтвержденных пакетов. Другой пример: так как транспортный драйвер протокола NetBEUI включает функции подуровня LLC, то ему необходимо реализовать лишь минимум функций транспортного уровня.
5. Сеансовый уровень. Управляет соединением между взаимодействующими приложениями на разных компьютерах, включая синхронизацию высокого уровня, и контроль за тем, какое из приложений «говорит», а какое «слушает». Он знает имена компьютеров в сети.
Интерфейсы NetBIOS и WinSockets являются примерами типичного программно2 го обеспечения сеансового уровня.
6. Уровень представления. Предоставляет сервисы, используемые приложениями, такие как шифрование, сжатие, или преобразование символов (PC ASCII в EBCDIC). Отвечает за форматирование данных, в том числе решает, должны ли строки заканчиваться парой символов «возврат каретки/перевод строки» (CR/LF) или только символом «возврат каретки» (CR).
Примером программного модуля, реализующего уровень представления, является XDR (External Data Representation) под управлением средства удаленного вызова процедур RPC (Remote Procedure Call).
7. Прикладной уровень. Обрабатывает передачу данных между двумя сетевыми приложениями, включая проверку прав доступа, идентификацию взаимодействующих машин и инициирование передачи данных.
Прикладной уровень обрабатывает запросы от приложений, например, обращение к базе данных или доставку почты. Этот уровень доступен приложениям напрямую. RPC является примером реализации прикладного уровня. Множество известных протоколов объединяют прикладной уровень и уровень представления, например: именованные каналы и FTP (File Transfer Protocol). Клиенты используют именованные каналы, например, для взаимодействия с Microsoft SQL Server.

Сетевые API

Windows NT реализует несколько сетевых API для обеспечения поддержки сетевых приложений и совместимости с промышленными стандартами. Важно иметь в виду, что решение о том, какое API должно использовать приложение, зависит от характеристик API. Таких характеристик как, например, поддерживает ли API надежное или двунаправленное взаимодействие, над каким протоколом располагается API, переносимость API на другие Windows-платформы, на которых должно исполняться приложение. Итак, Windows NT предоставляет несколько способов получения доступа к сети, то есть несколько механизмов межпроцессных коммуникаций, часть которых описана ниже.

Стандартный API ввода/вывода Win32

Приложения получают доступ к удаленным файлам, используя стандартные Win32-функции ввода/вывода (открытия, закрытия, чтения, записи и т. п). Соответствующие запросы проходят по сети только в том случае, когда файл или устройство находятся на удаленной машине. Как правило, это означает, что имя файла является именем UNC (Uniform Naming Convention, то есть начинается с символов \\), или начинается с буквы, указывающей на диск на удаленной машине. Функции API ввода/вывода Win32, большая часть которых оптимизирована в DLL клиентской стороны, реализуются путем вызова системных сервисов системы ввода/вывода NT, в результате чего диспетчер ввода/вывода посылает пакеты IRP сначала драйверу mup.sys, а затем соответствующему редиректору, взаимодействующему с драйвером файловой системы сервера на сервере.

Сетевые API Win32 (Wnet и Net)

Windows NT обеспечивает множество независимых от сети WNet-функций, которые позволяют работать через провайдеров разных сетей.
Функции этого интерфейса полезны таким приложениям, как File Manager, которые выполняют соединение с удаленными файловыми системами и их просмотр. Функции WNet можно использовать для просмотра файловых систем Microsoft и других файловых систем по сетям LAN Manager, NetWare, VINES и т.д. Вызовы интерфейса API WNet, реализованного в виде DLL, проходят через сетевой компонент, называемый сервисом рабочей станции. Этот сервис - серверный процесс, похожий на защищенную подсистему. Сервис рабочей станции является, в сущности, надстройкой пользовательского режима для редиректора. Он поддерживает API WNet, предоставляет функции конфигурации редиректора и содержит код пользовательского режима для получения статистики редиректора. Когда приложение вызывает функции API WNet, этот вызов в начале поступает сервису рабочей станции, а затем уже к диспетчеру ввода/вывода и далее к редиректору.
Net-функции, предоставляемые сетевым интерфейсом Net, поддерживаются в «сетевой ОС» Microsoft LAN Manager, основанной на OS/2. В Windows NT большая часть сетевой функциональности является встроенной, поэтому некоторые из первоначальных Net-функций уже не поддерживаются. В Windows NT множество Net-функций, предоставляемых библиотекой netapi32.dll, дополняет встроенную сетевую функциональность, не обеспечиваемую другими сетевыми интерфейсами. Например, Net-функции позволяют приложениям взаимодействовать с сервисом рабочей станции, сервисом сервера, сервисом оповещений, сервисом передачи сообщений, репликатором и т.д.
Если существует базовая функция или WNet-функция, требуемая приложению, то лучше использовать ее, чем эквивалентную Net-функцию по двум причинам. Во-первых, WNet-функции являются независимыми от сети, в то время как Net-функции работают только в сетях Microsoft Windows. Во-вторых, некоторые из Net-функций могут быть замещены функциями базовых сетевых интерфейсов или WNet-функциями, и не поддерживаться в будущих версиях Windows NT.

API NetBIOS (Network Basic Input/Output System)

Это прикладной программный интерфейс, позволяющий обмениваться запросами ввода/вывода с удаленным компьютером. Этот интерфейс используется для создания приложений для локальных сетей Microsoft LAN Manager, IBM LAN Server, Microsoft MS-Net или операционной среды OS/2. Этот API обеспечивает обратную совместимость для программ MS-DOS, 16-разрядной Windows и OS/2, которые передают данные по сети. Имеется также новая 32-разрядная версия. Интерфейс NetBIOS используется для посылки запросов, имеющих структуру формата SMB, на другой компьютер.
NetBIOS полагается на соглашение об именах, согласно которому компьютерам и сетевым сервисам назначаются 16-байтные имена, называемые NetBIOS-именами. Сетевой сервис WINS (Windows Internet Name service) поддерживает отображение между NetBIOS-именами и адресами протокола TCP/IP. NetBIOS-функции, как и Net-функции, экспортируются приложениям библиотекой Netapi32.dll (см. рис. 18). Эта библиотека открывает описатель драйвера уровня ядра, называемого эмулятором NetBIOS - NetBIOS.sys (драйвер файловой системы NetBIOS), и вызывает функцию DeviceloControl по команде приложения. Эмулятор NetBIOS транслирует NetBIOS-команды, выданные приложениями, в TDI-команды, которые посылаются драйверам протоколов. Если приложение хочет использовать NetBIOS поверх протокола TCP/IP, эмулятор NetBIOS требует присутствия драйвера NetBT.sys. Этот драйвер отвечает за поддержку семантики NetBIOS, присущей протоколу NetBEUI, а не протоколу TCP/IP. NetBIOS полагается на передачу NetBEUI-сообщений и средство разрешения имен NetBIOS, поэтому драйвер NetBT реализует их в вершине протокола TCP/IP. Подобно этому, драйвер NwLinkNB реализует семантику NetBIOS поверх протокола IPX/SPX.

Рис. 18. Интерфейс NetBIOS

Win32 API именованных каналов (named pipes) и почтовых ящиков (mailslots)

Именованные каналы обеспечивают надежное двунаправленное взаимодействие между двумя процессами, независимо от того, является ли принимающая сторона локальной или удаленной. Почтовые ящики выполняют аналогичные функции, однако, вместо обеспечения канала «один к одному» между принимающей и передающей сторонами, они предоставляют ненадежную однонаправленную передачу данных типа «один ко многим» и «многие к одному». Почтовые ящики полезны для посылки широковещательных сообщений произвольному числу процессов.
Именованные каналы предоставляют абстрактный и удобный сетевой интерфейс. Вместо того чтобы иметь дело с маршрутизацией и пересылкой данных, программист, использующий именованные каналы, может просто открыть канал и поместить в него данные. Пользователь именованного канала открывает его и считывает данные. Передача данных между компьютерами выполняется автоматически и один вызов именованного канала эквивалентен нескольким операциям на уровне транспорта.
Все функции именованных каналов и почтовых ящиков реализованы в DLL клиентской части подсистемы Win32 - kernel32.dll (см. рис. 19). Однако имена, задаваемые приложениями, использующими именованные каналы и почтовые ящики, определяют системное пространство имен, управляемое драйвером файловой системы именованных каналов (Named Pipes File System, NPFS.sys) и драйвером файловой системы почтовых ящиков (Mail Slots File System, MSFS.sys). Драйвер файловой системы именованных каналов создает объект-устройство, называемое \Device\NamedPipe, и символическую ссылку к этому объекту, называемую \??\Pipe, а драйвер файловой системы почтовых ящиков создает объект-устройство, называемое \Device\Mailslot, и символическую ссылку \??\Mailslot, указывающую на этот объект. Имена, передаваемые функции CreateFile вида \Y\Pipe\.... и \V\Mailslot\...., имеют префикс \\.\, преобразуемый в \??\, так что имена разрешаются через символическую ссылку к объекту-устройству.

Рис. 19. Интерфейс именованных каналов и почтовых ящиков

Позже мы обсудим, как драйвер файловой системы редиректора вовлекается, когда разрешаются имена, определяющие именованные каналы и почтовые ящики на удаленной системе. Однако, когда именованные каналы и почтовые ящики создаются сервером, или открываются клиентом, вовлекается соответствующий драйвер файловой системы на машине, где располагается именованный канал или почтовый ящик.
Обработка запроса к локальному именованному каналу или прием запроса к нему от удаленного компьютера выполняется файловой системой именованных каналов. Если же запрос к именованному каналу происходит по имени UNC, то обработка выполняется так же, как и для других запросов к удаленным файлам: запрос перехватывается драйвером mup.sys и направляется соответствующему редиректору.

API Windows Sockets

Этот API реализует 16 и 32-разрядные сокеты - стандартный сетевой интерфейс, используемый UNIX. Winsock поддерживает надежное, ориентированное на соединение, а также ненадежное, не ориентированное на соединение взаимодействия.
Прикладной интерфейс Windows Sockets состоит из DLL Ws2_32.dll, которая обеспечивает приложениям доступ к Winsock-функциям (см. рис. 20). Ws2_32.dll вызывает сервисы пространства имен и провайдеров сервисов транспорта для выполнения операций по разрешению имен и передачи сообщений. Библиотека Msafd.dll действует как провайдер сервисов транспорта. Msafd.dll использует библиотеки-помощники для Winsock (которые являются специфичными для протоколов), для взаимодействия с драйверами протоколов уровня ядра. Например, Wshtcpip.dll является помощником для протокола TCP/IP, а Wshnetbs.dll - для протокола NetBEUI. Библиотека Mswsock.dll реализует расширенную функциональность Microsoft Winsock.

Рис. 20. Интерфейс WinSockets

Провайдер сетевого транспорта Msafddll использует сервисы драйвера файловой системы AFD.sys (Ancillary Function driver, AFD) для реализации функций сокетов. AFD является TDI-клиентом и исполняет сетевые операции с сокетами, такие как посылка и получение сообщений, путем отправки запросов TDI IRP драйверам протоко-
лов. AFD не запрограммирован для использования определенных драйверов протоколов, поэтому Msafd.dll информирует AFD об имени протокола, используемого определенным сокетом, так чтобы AFD мог открыть объект-устройство, представляющее этот протокол.

Средство удаленного вызова процедур (Remote Procedure Call, RFC)

Средство удаленного вызова процедур позволяет создавать распределенные приложения, вызывающие функции, реализованные как локально, так и на удаленных компьютерах. RPC предоставляет модель работы с сетью, ориентированную на процедуры, а не на транспорты, что позволяет упростить разработку распределенных приложений. Библиотека RPC (rpcrt4.dll) и компилятор MIDL (Microsoft Interface Definition Language, MIDL - язык описания интерфейса фирмы Microsoft) позволяют программистам с легкостью создавать распределенные приложения.
Библиотека RPC периода выполнения включает процедуры для управления RPC по сети, а также разновидность RPC, называемою локальным RPC. Локальный RPG может быть использован для взаимодействия между двумя процессами, располагающимися на одной и той же машине, для этого библиотека RPC периода выполнения использует средство LPC в режиме ядра в качестве локального сетевого API. Когда RPC базируется на нелокальных механизмах взаимодействия, библиотека RPC использует такие интерфейсы как Winsock и именованные каналы (см. рис. 21).

Рис. 21. Интерфейс RPC

Для регистрации и поиска имен RPC-приложещя связываются с клиентской библиотекой сервиса имен RPC - rpcns4.dll. Эта DLL взаимодействует с подсистемой
RPCSS (RPCSS.exe для WinNT, RPCSS.dll для Win2000), стартующей автоматически при загрузке ОС, и реализованной как Win32-сервис. Сервис Rpcss сам является RFC-приложением, которое взаимодействует с такими же приложениями на других системах для выполнения поиска имен и регистрации.
Сервис Rpcss реализует некоторые RPC и OLE сервисы, включая динамическое назначение и разрешение адреса серверного процесса и разрешение DCOM-объектов (Distributed Component Object Model). Также при загрузке ОС автоматически стартует и исполняется в собственном процессе сервис locator.exe — провайдер сервиса имен для RPC. Сервис имен - сервис, отображающий имена в объекты и хранящий пары имя/объект в базе данных. Например, сервис имен RPC locator.exe отображает логические имена в описатели соединений (структуры данных, представляющие логические соединения между клиентом и сервером), чтобы клиентское приложение могло обращаться по этому логическому имени, а не использовать последовательность протоколов и сетевые адреса.
Библиотека RPC периода выполнения использует для взаимодействия с транспортным протоколом единый интерфейс доступа к транспорту RPC (RPC transport provider interface). Этот интерфейс служит прослойкой между средством RPC и транспортом и предоставляется различными библиотеками. Например:

1. rpcltcl.dll - библиотека клиентского приложения, предоставляющая транспорт именованных каналов;
2. rpcltsl.dll - библиотека серверного приложения, предоставляющая транспорт именованных каналов;
3. rpcltc3.dll - библиотека клиентского приложения, предоставляющая транспорт TCP/IP;
4. rpclts3.dll - библиотека серверного приложения, предоставляющая транспорт TCP/IP.

Существуют и другие библиотеки для серверных и клиентских приложений, предоставляющие транспорты NetBIOS, Winsock и т.д.
Средство RPC может работать поверх большого количества транспортов, однако при работе по сети LAN Manager средство RPC использует в качестве сетевого транспорта именованные каналы.
Большинство сетевых сервисов Windows NT являются RPC-приложениями, и могут вызываться как локальными процессами, так и процессами на удаленных машинах.

Средство динамического обмена данными (Network Dynamic Data Exchange, NetDDE)

Network DDE используется для установления и поддержания сетевых соединений, необходимых для динамического обмена данными между приложениями, выполняющимися на разных компьютерах в сети. Для реализации динамического обмена данными, приложениям необходимо использовать библиотеки nddeapi.dll (см. рис. 22) или ddeml.dll (DDE Management Library - библиотека управления динамическим обменом данными).

Рис. 22

Приложения могут, либо использовать протокол DDE (подключая библиотеку nddeapi.dll), являющийся множеством правил передачи определенных DDE-сообщений, либо могут использовать библиотеку ddeml.dll. Ddeml.dll обеспечивает интерфейс, который облегчает задачу добавления возможностей динамического обмена данными \?1п32-приложениям. Вместо отправления, получения и обработки непосредственно DDE-сообщений по протоколу DDE-приложения используют функции, предоставляемые библиотекой ddeml.dll для управления DDE-взаимодействием между клиентским и серверным приложениями. Эта библиотека также делает возможным серверным приложениям регистрировать имена поддерживаемых ими сервисов. Приложения, использующие протокол DDE, основанный на передаче сообщений, полностью совместимы с приложениями, использующими ddeml.dll, но из-за большого числа преимуществ библиотеки ddeml.dll, новым приложениям предпочтительнее использовать эту библиотеку, чем передачу DDE-сообщений.
Во время загрузки компьютера автоматически запускается приложение nddeagntexe (Network DDE Agent), которое служит для обнаружения локальной DDE-активности, после чего, этот агент стартует приложения, необходимые для динамического обмена данными. DDE-взаимодейтствия контролируются посредством DDE-окна, ассоцииро-
ванного с одним из приложений, обеспечивающих DDE (clipsrv.exe, Windows NT DDE Server). Это приложение взаимодействует со всеми локальными и удаленными приложениями, использующими DDE.
Но Nddeagnt не может обнаружить попытку соединения удаленного клиента. Прежде чем удаленный клиент сможет успешно соединиться с серверным приложением, на серверном компьютере должен стартовать сервис netdde.exe. В качестве транспорта механизм DDE использует средство RPC с транспортом именованных каналов.

Сервисы удаленного доступа (Remote Access Services, RAS)

Сервер Windows NT поддерживает удаленный доступ (RAS) для создания временных соединений с системами, которые не находятся в локальной сети, обычно это соединения через телефонные линии. Сервер Windows NT включает встроенную поддержку для модемов, устройств Х.25 и ISDN модемов. Один сервер Windows NT может поддерживать одновременно до 255 удаленных соединений. Новый протокол РРТР (Point-to-Point Tunneling Protocol), заявленный в марте 1996, позволяет пользователям использовать «туннели» в любой сети на базе протокола TCP/IP для достижения своих защищенных сетей с удаленного компьютера.
Функции сервиса RAS позволяют приложениям устанавливать удаленные соединения. Удаленные соединения могут использовать протокол SLIP (Serial Line Internet Protocol), или, более предпочтительный протокол РРР (Point-to-Point Protocol). Сервисом RAS обеспечиваются протоколы РРР аутентификации (PAP, CHAP) и протоколы конфигурирования сети (IPCP, IPXCP, NBFCP, LCP). Когда РРР соединение уже установлено, приложения могут использовать стандартные сетевые интерфейсы, такие как Windows Sockets, NetBIOS, Named Pipes, RPC и взаимодействовать по протоколам: NetBEUI, TCP/IP или IPX/SPX, инкапсулированным в РРР. TCP/IP на основе РРР используется наиболее часто для связи мобильных пользователей с Intranet.
RAS-приложения на клиентском узле, реализующие удаленный доступ к серверному узлу, могут выполнять задачи по обеспечению RAS двумя способами. Первый способ основан на вызове функций, отображающих диалоговые окна сервиса RAS, обеспечиваемые системой для интерфейса с пользователем. Эти функции предоставляются библиотекой rasdlg.dll и позволяют приложениям легко отображать диалоговые окна, знакомые пользователю, чтобы тот мог выполнять RAS-задачи, такие как установление, завершение и наблюдение за удаленными соединениями, или работать с записной книжкой, содержащей телефонные номера.
Второй способ основан на использовании непосредственных функций дозвона, предоставляемых RAS-приложениям библиотекой rasapi32.dll (см. рис. 23). Клиентское приложение может использовать функцию RasDialQ для установления соединения с RAS-сервером. Функция RasDialQ начинает операцию соединения, которая затем будет выполняться программным компонентом, называемым менеджером удаленных соединений (Remote Access Connection Manager). Диспетчер удаленных соединений является сервисом пользовательского уровня, управляющим деталями установления соединения с удаленным сервером и разделяющим процесс (rasman.exe) с другим сервиcом - менеджером автодозвона (Remote Access Autodial Manager). Диспетчер удаленных соединений стартует автоматически, когда приложение загружает библиотеку rasapi32.dll.

Рис. 23. RAS

В процесс rasman.exe для согласования с интерфейсом TAPI (Telephony Application Programming Interface) загружается библиотека rastapi.dll (Remote Access TAPI
Compliance Layer), которая и обращается к функциям интерфейса TAPI, предоставляемым библиотекой tapi32.dll (Microsoft Windows Telephony API Client DLL).
На удаленном серверном компьютере исполняется процесс RAS-сервера - rassrv.exe (Remote Access Server Supervisorfor). Windows NT обеспечивает поддержку администрирования RAS-сервера приложениями сторонних производителей посредством использования библиотеки rassapi.dll (Remote Access Admin APIs dll).

TAPI (Telephony Application Programming Interface)

Интерфейс TAPI - множество функций, позволяющих запрограммировать устройства, передающие данные по телефонным линиям, не зависящим от конкретного устройства образом, предоставляя пользователям возможность взаимодействия по телефону. TAPI поддерживает передачу речи и данных, обеспечивает множество типов соединений и управление вызовами. TAPI позволяет приложениям использовать все возможности телефона, например, поддержку конференций и передачу звуковой почты.
В Windows NT подсистема обеспечения взаимодействия по телефону состоит из следующих компонентов (см. рис. 24):

1. TAPI-сервер tapisrv.exe (telephony service), реализующий TAPI функции;
2. библиотеки динамической загрузки tapi.dll и tapi32.dll, взаимодействующие посредством механизма RPC с TAPI-сервером;
3. один или несколько провайдеров телефонных сервисов (telephony service providers), загружаемых TAPI-сервером.

Приложения полагаются на существование провайдеров телефонных сервисов, которые предоставляют интерфейс TSPI (Telephony Service Provider Interface). Провайдеры телефонных сервисов могут быть разработаны для различных технологий, включая: 1) POTS (Plain Old Telephone Service) для передачи голоса и данных в аналоговом формате по абонентской линии, а далее везде в цифровом виде; 2) ISDN (Integrated Services Digital Network) для передачи в цифровом виде; 3) Т1/Е1 для цифровой передачи со скоростью 1.544 Mbps; 4) Switched 56 и т. д.
Провайдер сервиса является библиотекой динамической загрузки (иногда в его состав входит драйвер устройства), реализующей зависящие от устройства действия для выполнения телефонных операций на оборудовании, таком как телефон, модем, факс или ISDN карта. Таким образом, провайдер во взаимодействии с библиотеками интерфейса TAPI, предохраняет приложения от деталей, зависящих от типа сервиса и технологий коммуникаций по телефонным сетям.
Приложения вызывают функции только из библиотек tapi.dll (16-разрядные приложения) и tapi32.dll (32-разрядные приложения), они никогда не вызывают функции провайдеров напрямую. Библиотека tapi.dll является тонкой прослойкой, которая отображает 16-разрядные адреса в 32-разрядные, и передает запросы tapi32.dll. Библиотека tapi32.dll проверяет параметры функции и направляет запрос на выполнение сервису tapisrv.exe, а когда нужно загружает в процесс TAPI-приложения библиотеки, обеспечивающие интерфейс с пользователем (Telephony service provider user interface DLLs), в том случае, если провайдер реализует какие-либо элементы интерфейса с пользователем

Tapisrv.exe, исполняющийся> в собственном процессе, является ядром TAPI. Tapisrv.exe обрабатывает вызов и передает запрос соответствующему провайдеру сервиса. Получив запрос от tapisrv.exe, провайдер сервиса должен реализовать интерфейс TSPI. Все провайдеры телефонных сервисов исполняются в процессе tapisrv.exe и могут создавать необходимые для них потоки в контексте этого процесса.
DLL провайдера может использовать любые системные функции, включая CreateFileQ и DevicelOControlQ, для работы с драйверами оборудования независимых поставщиков, а также с драйверами стандартных устройств, таких как последовательные и параллельные порты. Они также могут обращаться к сетевым интерфейсам, таким как RPC, Windows Sockets, Named Pipes для клиент-серверного взаимодействия.
В Windows NT есть встроенный провайдер телефонных сервисов юнимодема -unimdm.tsp (Unimodem Service Provider), взаимодействующий с драйвером модема modem.sys, и предоставляющий сервисы TAPI с большинством типов модемов. А также встроенный провайдер сервисов компонента интерфейса TAPI уровня ядра -kmddsp.tsp (TAPI kernel-mode service provider). Kmddsp.tsp предоставляет интерфейс провайдера телефонных сервисов (TSPI) и передает преобразованные пользовательские запросы драйверу ndistapi.sys, который и является компонентом интерфейса TAPI уровня ядра.
TAPI также включает провайдеров сервиса среды (Media Service Providers, MSP), которые дают TAPI-приложению улучшенный, определяемый средой контроль над этой средой. Библиотека MSP, загруженная приложением, имеет соответствующий TSP в TAPI-сервере.
Пользователь может инсталлировать любое количество провайдеров телефонных сервисов, если только они не будут обращаться к одному и тому же устройству одновременно. Пользователь ассоциирует устройство с провайдером сервиса при инсталляции.
Некоторые провайдеры способны обращаться к нескольким устройствам. В некоторых случаях пользователю может понадобиться инсталлировать драйвер устройства вместе с провайдером.

Интерфейс DLC (Data Link Control)

В Windows NT приложения могут использовать интерфейс DLC, обращаясь к библиотеке dlcapi.dll. Интерфейс DLC - это немаршрутизируемый протокол, используемый для взаимодействия между компьютером с ОС Windows и мейнфреймами IBM или принтерами, присоединенными непосредственно к сети.
Интерфейс DLC представляет собой множество команд, которые сохраняются в структуре ССВ (Command Control Block) и передаются драйверу транспорта DLC. (Драйвер транспорта DLC в своей верхней части не предоставляет TDI-интерфейс.)

Протокол SNMP (Simple Network Management Protocol)

Cтандартный протокол Internet для обмена управляющей информацией между консолями управления, такими как HP Openview, Novell NMS, IBM NetView, Sun Net Manager, и набором управляемых устройств, такими как маршрутизаторы, мосты, концентраторы.
SNMP использует распределенную архитектуру, состоящую из менеджеров (консолей управления) и агентов. SNMP-агентами являются приложения, отвечающие за отслеживание и передачу информации об устройстве по запросу SNMP-диспетчера, а также за обновление локальной управляющей информации на основе сообщений, переданных от SNMP-диспетчера. Агент также оповещает зарегистрированных менеджеров о происхождении значительных событий или особых ситуаций. SNMP-диспетчер - это приложение, генерирующее запросы на получение и установку параметров к SNMP-агенту, и получающее оповещения от SNMP-агентов.
В ОС Windows NT SNMP-агент реализован в SNMP-сервисе snmp.exe. Это главный агент, получающий SNMP-запросы и передающий их соответствующей библиотеке DLL расширения агента (extension agent DLL). В Windows NT имеется множество DLLs, расширяющих возможности главного SNMP-агента, например: 1) dhcpmib.dll - DLL расширения агента, реализующая DHCP MIB и инсталлируемая только на DHCP серверах; 2) hostmib.dll - DLL расширения агента, реализующая MIB ресурсов хоста; 3) inetmibl.dll - DLL расширения агента, реализующая MIB-II; 4) Immib2.dll - DLL расширения агента, реализующая LAN Manager MIB-II; 5) winsmib.dll - DLL расширения агента, реализующая WINS MIB, инсталлируемая только на WINS серверах.
Management Information Base (MIB) описывает множество управляемых объектов, имеющих уникальные идентификаторы. SNMP-диспетчер может манипулировать объектами в требуемой базе MIB на определенном компьютере, если на этом компьютере главный SNMP-агент имеет библиотеку DLL расширения агента, поддерживающую требуемую MIB.
DLLs расширения агента для MIB-II, LAN Manager MIB-II и Host Resources MIB инсталлируются вместе с сервисом SNMP (главным агентом). DLLs расширения агента для других MIBs инсталлируются при инсталляции соответствующих им сервисов. Во время запуска некоторого сервиса, SNMP-агент загружает все соответствующие этому сервису DLLs расширения агента, перечисленные в реестре Windows NT.
SNMP-диспетчер обычно является консольным приложением третьих производителей. Windows NT включает библиотеки, поддерживающие SNMP-менеджеров. Консоль управления формирует SNMP-сообщение, используя библиотеки mgmtapi.dll (Microsoft SNMP Management API DLL), wsnmp32.dll (Microsoft WinSNMP Manager API DLL), snmpapi.dll (SNMP Utility Library). Библиотека функций SNMP - snmpapi.dll
используется как консолями управления, так и библиотеками расширения агента. Snmptrap.exe - сервис, получающий SNMP-ловушки и передающий их SNMP-диспет-черу, а snmpcfg.exe - сервис SNMP-конфигурирования. Программные компоненты, отвечающие за передачу SNMP сообщений, используют интерфейс API Windows Sockets.

DCOM

COM API фирмы Microsoft позволяет приложениям состоять из разных компонентов, где каждый компонент является заменяемым самостоятельным модулем. СОМ-объекты экспортируют ориентированный на объекты интерфейс к методам для манипулирования данными внутри объекта. Так как СОМ-объекты предоставляют хорошо определенные интерфейсы, разработчики могут реализовывать новые объекты для расширения существующих интерфейсов и для динамического добавления приложениям новой поддержки.
DCOM расширяет СОМ, позволяя компонентам приложения располагаться на разных компьютерах. Что позволяет приложениям не беспокоиться о том, что один СОМ-объект располагается на локальном компьютере, а другой в сети. DCOM, таким образом, обеспечивает прозрачность расположения, что облегчает разработку распределенных приложений. DCOM не является самостоятельным API, а полагается на RPC для выполнения своей работы.

Сетевые сервисы

Сетевые сервисы - это процессы, похожие на защищенные подсистемы. В отличие от защищенных подсистем, сетевые сервисы, имеющие собственные API, обычно используют RPC, а не LPC для обмена сообщениями со своими клиентами. Применение RPC делает сервисы доступными процессам, как на локальной, так и на удаленной машине. За загрузку и запуск сервисов отвечает компонент, называемый контроллером сервисов (service controller). Он также предоставляет средства загрузки и выгрузки драйверов. Примерами сетевых сервисов являются: 1) сервис рабочей станции (LanmanWorkstation), выполняющий администрирование встроенного редиректора; 2) сервис оповещений (alerter), выполняющий рассылку оповещений подключенным пользователям, например, при переполнении жесткого диска; 3) сервис сообщений (messager), выполняющий прием сообщений от других систем, например, уведомлений о том, что завершено выполнение задания на печать. '
Почти все сетевые сервисы, такие как сервис рабочей станции, сервис сервера (LanMan Server), сервис оповещений, сервис сообщений, обозреватель сети (Computer Browser), DHCP-клиент (DHCP client) содержатся в одном ЕХЕ-файле с именем services.exe. Остальные исполняются в собственных процессах, например, сервис WINS (Windows Internet Name Service) - это сервис динамической регистрации и разрешения имен, отображающий NetBIOS-имена компьютеров в IP-адреса. Сервис системы доменных имен DNS (Domain Name System), преобразующий DNS-имена в IP-адреса.
А также ранее упомянутые при рассмотрении сетевых API сервисы: rpcss.exe (RPC and Distribute СОМ сервисы), locator.exe (провайдер сервиса имен для RPC),
nddeagnt.exe (Network DDE агент), tapisrv.exe (сервер, обеспечивающий телефонные сервисы).
В Win2000 появился сервис репликации файлов (File Replication Service, FSR), главная задача которого состоит в репликации содержимого директории контроллера домена \SYSVOL, в которой контроллер домена хранит скрипты входа в домен и групповую политику. В дополнение FSR может быть использован для репликации разделяемых файлов распределенной файловой системы (Distributed File System) между системами. FSR реализован как Win32-cepBnc Ntfrs.exe, который использует RPC с аутентификацией и шифрованием для взаимодействия между своими же экземплярам, исполняющимися на других компьютерах.

Сетевые файловые системы

Сетевые файловые системы позволяют пользователям разделять свои локальные диски с другими пользователями в локальной или глобальной сети. Любая сетевая файловая система состоит из двух компонентов: сетевого редиректора на клиентской стороне и сетевого сервера на узле с разделяемым диском.

Редиректор

Сетевой редиректор является компонентом уровня ядра, предоставляющий ин-терфейс файловой системы локальным пользователям, для этого он принимает запросы ввода/вывода для удаленных файлов и устройств, пересылает их сетевому серверу на удаленном узле, получает данные с удаленного компьютера и предоставляет их локальному пользователю. Реализован в виде драйвера файловой системы.
Сетевой редиректор использует для взаимодействия с сервером протокол 8MB (протокол прикладного уровня, унаследованный от MS-NET), и поэтому он может работать с существующими серверами MS-NET и LAN Manager, обеспечивая Windows NT доступ к системам MS-DOS, Windows и OS/2. Но для обмена данными между системами Windows NT, базовый протокол 8MB был расширен, чтобы поддерживать распространенные операции ввода/вывода NT.
Редиректор вызывает интерфейс драйвера транспорта TDI для передачи пакета 8MB различным транспортным драйверам. Редиректор должен открыть для связи с удаленной машиной канал, называемый виртуальным контуром, и затем послать пакет 8MB через этот контур. Редиректор поддерживает по одному виртуальному контуру для каждого сетевого сервера, с которым связана операционная система
Windows NT, и мультиплексирует все запросы к данному серверу в один контур. Встроенный редиректор Windows NT может сосуществовать с редиректорами других сетей.
Встроенный редиректор и другие редиректоры создают объект-устройство в пространстве имен диспетчера объектов во время своей загрузки и инициализации. Когда WNet или другой API обращается к диспетчеру объектов для открытия ресурса, расположенного в сети, диспетчер объектов, пройдя по дереву объектов и, обнаружив объект-устройство редиректора (точку входа в удаленную файловую систему), вызывает метод разбора диспетчера ввода/вывода, который передает оставшуюся часть имени ресурса соответствующему редиректору, который и находит удаленный ресурс.

Сетевой сервер

Этот компонент должен отвечать на удаленные запросы, полученные от редиректора на клиентской стороне, взаимодействуя с локальной файловой системой или принтером. Сетевой сервер реализован в виде драйвера: в одних источниках утверждается, что сервер является драйвером файловой системы (согласно реестру тип этого компонента также драйвер файловой системы), а в других - обычным драйвером.
Сетевой сервер обеспечивает совместимость с существующими протоколами 8MB MS-NET и LAN Manager, и обрабатывает запросы, приходящие не только от систем Windows NT, но также и от других систем, на которых работает программное обеспечение LAN Manager. Так как сервер находится в исполнительной системе, то он может непосредственно вызывать диспетчер кэша для оптимизации передачи данных. Если требуемых данных в кэше не оказывается, то сервер создает собственные пакеты зап роса ввода/вывода IRP и посылает их непосредственно драйверам локальных.файло вых систем NTFS, FAT и HPFS.
В 1996 году Microsoft представила на рассмотрение организации IETF специфика цию сетевого протокола Common Internet File System (CIFS) 1.0, являющимся последним расширением и улучшением протокола SMB.

Распределенная файловая система (Distributed File System, DFS)

В случае сетевых файловых систем, несмотря на то, что весь механизм транспо] тировки данных скрыт от пользователя файловой системы, он все равно знает, каю данные хранятся локально, а какие были получены с удаленного серверного узла. Ра пределенные файловые системы предлагают единое глобальное пространство им< файлов для пользователя и полностью скрывают действительное физическое распол жение файлов от пользователя файловой системы. DFS является сервисом, которь располагается выше сервиса рабочей станции, чтобы соединить вместе разделяем) файлы в одно пространство имен.
Распределенные файловые системы имеют сходную архитектуру с сетевыми файловыми системами. Они также имеют клиентскую часть, исполняемую на клиентском узле, и серверную часть, исполняемую на удаленном узле. Клиентская и серверная части могут одновременно исполняться на любом узле, участвующем в реализации распределенной файловой системы.
Корень пространства имен DFS должен быть разделяемым файлом, определенном на Windows 2000 Server. Серверная часть реализации DFS состоит из Win32-cepBHca и драйвера Dfs.sys. DFS-сервис отвечает за экспортирование интерфейса управления DFS-топологией и за поддержание DFS-топологии либо в реестре, либо в Active Directory. Получив запрос от клиента, DFS-драйвер выполняет просмотр топологии и направляет клиента в систему, где находится запрашиваемый им файл.

Маршрутизатор многосетевого доступа

Так как в систему могут быть загружены дополнительные редиректоры для доступа к сетям других типов, то существует компонент, который решает, какой редиректор вызвать для обработки запроса на удаленный ввод/вывод.
Маршрутизатор многосетевого доступа (Multiple Provider Router, MPR) - это библиотека DLL, предоставляющая приложениям интерфейс API WNet, и определяющая к какой сети следует обратиться, когда приложение использует этот интерфейс для просмотра удаленной файловой системы. Когда приложение вызывает некоторою функцию WNet, этот вызов попадает непосредственно в DLL маршрутизатора многосетевого доступа, который принимает вызов и определяет, через какой из компонентов сетевого доступа (сетевых провайдеров) можно осуществить доступ к данному ресурсу. MPR позволяет приложениям взаимодействовать стандартным образом с несколькими редиректорами, установленными в системе.
Компонент сетевого доступа (сетевой провайдер) является программным модулем (DLL), разработанным для работы в тесной кооперации с сетевым редиректором. Провайдер - это как бы надстройка над редиректором в виде DLL, которая позволяет компьютеру взаимодействовать с конкретной сетью. В состав программного обеспечения Windows NT входят: провайдер для сетей на базе Windows NT, провайдер шлюза (и клиента) для NetWare.
Компонент сетевого доступа позволяет Windows NT выступать в качестве клиента некоторого удаленного сервера. Среди операций, выполняемых, например, встроенным компонентом сетевого доступа WNet, можно назвать установление и разрыв сетевого соединения, удаленную печать и передачу данных по сети. Кроме DLL встроенного компонента сетевого доступа и встроенного редиректора в этих операциях принимает непосредственное участие сервис рабочей станции. От других изготовителей сетей требуется предоставить только DLL и редиректор.
MPR определяет два множества функций. Одно множество - независящий от сети интерфейс API WNet, предоставляемый MPR всем Win32 приложениям, желающим использовать сервисы сетевых редиректоров (посредством сетевых провайдеров). Этот интерфейс позволяет сетевым приложениям запрашивать в стандартной форме выполнения редиректором некоторой общей функциональности, без необходимости разработки специфичного кода для этого редиректора. Другое множество - интерфейс сетевого доступа, предоставляемый всеми сетевыми провайдерами маршрутизатору многосетевого доступа.

Многосетевой UNC

Это еще один компонент, который решает, какой редиректор вызвать для обработки запроса на удаленный ввод/вывод, если в систему загружены дополнительные редиректоры для доступа к сетям других типов.
Многосетевой UNC (Multiple UNC Provider, MUP) - драйвер, определяющий, к какой сети следует обратиться, когда приложение использует стандартный Win32 API ввода/вывода для открытия удаленных файлов. Этот сетевой компонент обрабатывает запросы к файлам или устройствам, содержащим имя UNC (это имя, начинающееся с символов \\, которые указывают, что данный ресурс находится в сети). Драйвер mup.sys, подобно MPR, определяет, какой локальный редиректор распознает удаленный ресурс.
Драйвер mup.sys активизируется, когда приложение пытается открыть удаленный файл или устройство, задавая имя UNC. Получив подобный запрос, подсистема Win32 заменяет символы \\ строкой \DosDevices\UNC и передает запрос исполнительной системе. Объект \DosDevices\UNC является символической связью на объект-устройство \Device\mup, создаваемый драйвером mup.sys. Драйвер mup.sys является довольно простым драйвером и реализует процедуры распределения create/ open. После получения запроса на открытие, драйвер mup.sys посылает особые контрольные пакеты каждому редиректору, зарегистрированному драйвером mup.sys. Этим запросом mup.sys спрашивает редиректор, может ли тот распознать оставшуюся часть имени UNC. Если да, то редиректор должен информировать драйвер mup.sys о числе символов в строке имени UNC, которые он распознает как уникальный идентификатор удаленного ресурса. Драйвер mup.sys кэширует эту часть строки имени, и в последствии посылает имена, начинающиеся с данной подстроки сразу этому редиректору.
Для того чтобы редиректор мог взаимодействовать с драйвером mup.sys, редиректор должен зарегистрировать себя для драйвера mup.sys во время инициализации, и в дальнейшем отвечать на запросы о распознавании имени, выдаваемые драйвером mup.sys. Редиректор, который первым зарегистрировал себя для драйвера mup.sys, имеет больший приоритет. Этот приоритет определяет, какой редиректор будет обрабатывать запрос, в том случае, если более одного редиректора распознает имя удаленного ресурса.
После того, как какой-нибудь редиректор распознает имя удаленного ресурса, mup.sys подставляет в начало строки имени удаленного ресурса имя объекта-устройства редиректора и помещает эту строку в файловый объект, соответствующий этому
ресурсу. С этого момента, запросы к этому удаленному ресурсу идут к редиректору напрямую, и mup.sys больше не вовлекается.

Интерфейс TDI

Windows NT предоставляет для взаимосвязи между транспортными драйверами и TDI-клиентами уровня ядра, такими как эмуляторы сетевых интерфейсов, редиректоры, серверы, единый программный интерфейс, называемый интерфейсом транспортных драйверов (Transport Driver Interface, TDI).
Изначально этот интерфейс планировалось использовать в пользовательском режиме работы ОС. В окончательном варианте интерфейс стал работать в режиме ядра, однако все еще может быть использован напрямую из пользовательского уровня. TDI предоставляется верхней частью любого транспортного стека протоколов Windows NT. TDI обеспечивает независимость TDI-клиентов от используемых ими транспортов. TDI поддерживает передачу как с установлением постоянного сеанса (виртуальная цепь), так и без него (датаграммы).
Требование, чтобы все драйверы транспорта предоставляли единый общий интерфейс TDI, облегчает задачу их разработки, а также разработки TDI-клиентов, потому что только этот интерфейс необходимо запрограммировать.
Так как TDI является относительно новым сетевым интерфейсом, и большинство приложений разработаны для использования других существующих стандартных интерфейсов, таких как NetBIOS и WinSockets, то Windows NT включает эмуляторы для этих двух популярных интерфейсов. Части уровня ядра этих эмуляторов, являющиеся драйверами файловых систем, отображают родные функции с соответствующими параметрами в одну или несколько TDI-функций, а затем вызывают соответствующие драйверы транспортов через TDI.
Интерфейс TDI включает следующее:

1. Множество стандартных диспетчерских точек входа, обеспечиваемых транспортным драйвером, к которому TDI-клиент может обратиться с запросом ввода/вывода.
2. Множество процедур обратного вызова, экспортируемых любым TDI-клиентом и регистрируемых транспортным драйвером, для получения TDI-клиентом уведомления о произошедшем сетевом событии.
3. Параметры, структуры, lOCTLs и правила, ассоциированные с процедурами транспорта и его клиента.
4. Множество функций вида TdiXxx, которые транспорт и его клиент могут вызывать для взаимодействия друг с другом.
5. Множество макросов и функций вида TdiBuildXxx, которые TDI-клиент может использовать, чтобы обеспечить принятие запросов нижележащим транспортом.

Программная модель TDI очень похожа на модель Winsocket. TDI-клиенты реализуют следующие шаги для установления соединения с удаленным сервером:

1. TDI-клиент формирует пакет TDIIRP типа address open для размещения адреса. TDI-транспорт возвращает файловый объект, известный как объект-адрес, представляющий адрес. Этот шаг эквивалентен использованию функции bind в Winsocket.
2. TDI-клиент размещает и формирует пакет TDI IRP типа connection open, и TDI-транспорт возвращает файловый объект, известный как объект-соединение, представляющий соединение. Этот шаг эквивалентен использованию функции socket в Winsocket.
3. TDI-клиент ассоциирует объект-соединение с объектом-адресом с помощью пакета TDI IRP типа associate address.
4. TDI-клиент, принимающий удаленное соединение, выпускает TDI IRP пакет типа listen, определяющий число соединений, поддерживаемых для объекта-соединения, и затем выпускает пакет TDI IRP типа accept, который завершается, когда удаленная система установит соединение. Эта операция эквивалентна использованию функций listen и accept в Winsocket.
5. TDI-клиент, который хочет установить соединение с удаленным сервером, выпускает TDI IRP пакет типа connect, определяя объект-соединение, который TDI-транспорт завершает, когда установится соединение. Выпуск TDI IRP пакета типа connect эквивалентно использованию функции connect в Winsocket.

Транспортные протоколы

Microsoft предоставляет следующие транспорты:

1. NetBEUI и NetBEUI Frame (NBF) Транспортный протокол NetBEUI (Network Basic Input/Output System Extended User Interface) - является расширением канального уровня пользовательского интерфейса NetBIOS. Он является основным транспортным протоколом, используемым Windows NT для локальных сетей, и обеспечивающим взаимодействие с LAN Manager, LAN Server и MS-Net.
Протокол NetBEUI обеспечивает наивысшую скорость работы, но из-за ряда присущих ему недостатков, таких как невозможность маршрутизации и сильная зашумленность в большой сети, NetBEUI можно эффективно использовать только в небольших локальных сетях (IBM разработала протокол NetBEUI для локальных сетей, содержащих порядка 20 - 200 рабочих станций). Так как NetBEUI не маршрутизируемый, то он не позволяет создавать глобальные сети, объединяя несколько локальных сетей. Сети, основанные на протоколе NetBEUI, легко реализуются, но их трудно расширять, так как протокол NetBEUI не маршрутизируемый.
Протокол NetBEUI Frame (NBF) был создан на основе NetBEUI для преодоления некоторых его недостатков. В частности, NBF преодолевает предел количества систем - 254, существующий в NetBEUI.
2. Транспорт TCP/IP (Transmission Control Protocol/Internet Protocol, TCP/IP). Он был разработан для поддержки сети Министерства Обороны США - ARPANET (Advanced Research Projects Agency's network), предшествующей Internet, и предназначен для соединения разнородных систем через глобальные сети. Протокол TCP/IP широко распространен в сетях UNIX и позволяет Windows NT взаимодействовать с различными сервисами на UNIX - машинах.
Этот протокол быстро был адаптирован и для локальных сетей. В отличие от NetBEUI, который является запатентованным протоколом IBM и Microsoft, TCP/IP является общедоступным. Internet Engineering Task Force (IETF) координирует улучшения и расширения протокола TCP/IP через механизм, известный как Requests for Comments (RFCs). TCP/IP является надежным транспортом и очень гибким протоколом. TCP/IP можно использовать в локальных сетях небольшого масштаба, которые в дальнейшем можно легко расширить для вовлечения сотен и тысяч пользователей.
Протокол TCP/IP требует больше знаний для его использования, так как каждая машина должна иметь уникальный IP адрес и маску подсети. Такие средства как DHCP, WINS доступны в ОС Windows NT для облегчения задачи администрирования сети. Самое важное преимущество протокола ТСРЛР перед NetBEUI то, что TCP/IP - маршрутизируемый протокол. Структура IP адресов специально разработана для эффективной маршрутизации.
Транспорт ТСРЛР поддерживает множество компонент, реализующих сессионный уровень модели OSI, таких как NetBIOS, Winsock, RPC. ТСРЛР также является наиболее часто используемым протоколом при выполнении удаленного Доступа.
В Windows 2000 существуют встроенные драйверы, интегрированные с драйвером протокола ТСРЛР, которые расширяют базовые сетевые характеристики протокола ТСРЛР, используя с ним закрытый интерфейс.
Например, NAT-компонента (Network Address Translation) состоит из драйвера NAT, взаимодействующего со стеком ТСРЛР, а также редактора, используемого администратором для задания адресов. Другой пример - реализация IPSec (Internet Protocol security), включающая драйвер Ipsec.sys, интегрированный с драйвером протокола TCP/ IP. Агент политики получает информацию о конфигурации IPSec из Active Directory и передает информацию о фильтрации драйверу IPSec, а установки о безопасности модулю Internet Key Exchange. IKE-модуль ожидает запрос от драйвера IPSec и организует переговоры, возвращая результат обратно драйверу IPSec.
3. NWLink (IPX/SPX). Протокол Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) используется в ОС NetWare фирмы Novell. Реализация этого протокола фирмой Microsoft называется NWLink. IPX/SPX базируется на протоколе Xerox Network System (XNS), разработанном Xerox Corp. Протокол XNS, который больше не используется, определял коммуникационные уровни от физического до прикладного. Novell использовала часть этого стека, а именно два компонента: IDP (Internet Datagram Protocol) and SPP (Sequenced Packet Protocol). IPX (nwlnkipx.sys) базируется на IDP, SPX (nwlnkspx.sys) - на SPP.
IPX/SPX - высокопроизводительный протокол для локальных сетей, и легче реализуется и администрируется, чем TCP/IP. Как и TCP/JP IPX/SPX является маршрутизируемым, и, следовательно, может использоваться для реализации глобальных сетей.
В Windows NT существует также встроенный протокол NWLink NetBIOS (nwlnknb.sys), который предоставляет возможность пересылки Novell NetBIOS-пакетов между NetWare-сервером, исполняющим Novell NetBIOS, и Windows NT компьютером, или между двумя Windows NT компьютерами.
4. AppIeTalk. Семейство сетевых протоколов AppleTalk было первоначально разработано для компьютеров Macintosh, однако уже вторая версия этого сетевого продукта позволяет взаимодействовать различным персональным компьютерам. В Windows NT он используется сервисами для Macintosh, которые позволяют пользователям Macintosh совместно использовать файлы формата Мае, хранящиеся в папках Windows NT сервера, и использовать принтеры, присоединенные к Windows NT серверу.
5. Data Link Control (DLC). DLC - протокол фирмы IBM, используется как компонент архитектуры SNA (System Network Architecture) для связи с мейнфреймами. В некоторых локальных сетях DLC используется для связи с принтерами, присоединенными непосредственно к локальной сети, а не к серверу или рабочей станции. Некоторые лазерные принтеры Hewlett-Packard предлагают по выбору интерфейс DLC. Это «сырой» протокол в том смысле, что никакие сетевые API не могут его использовать , приложения, которые захотят его использовать должны взаимодействовать напрямую с драйвером транспорта DLC.

TDI-транспорты обычно реализуют все протоколы, связанные с их основным протоколом. Например, драйвер TCP/IP (tcpip.sys) реализует TCP, UDP, IP, ARP, ICMP, IGMP. TDI-транспорты обычно создают объекты-устройства, реализующие конкретный протокол так, чтобы клиенты могли открыть объект-файл, представляющий протокол, и выдать сетевой запрос ввода/вывода этому протоколу, используя IPR-пакеты. TCP/IP-драйвер создает три объекта-устройства, которые представляют различные протоколы: \Device\Tcp, \Device\Udp, \Device\Ip.

Среда STREAMS

STREAMS, основанная на UNIX STREAMS, является средой для существующих STREAMS-совместимых транспортных драйверов, которая обеспечивает переносимость этим драйверам в ОС Windows NT из других ОС с незначительными модификациями или вовсе без изменений. Один или несколько драйверов, расположенных друг над другом, окружаются сверху и снизу средой Streams и формируют провайдера сетевого транспорта. Среда STREAMS обеспечивает: Интерфейс TPI (Transport Provider Interface) - интерфейс верхней части транспортного стека. STREAMS транслирует этот интерфейс в «родной» интерфейс транспорта Windows NT - TDI. Интерфейс DLPI (Data Link Provider Interface) - интерфейс нижней части транспортного стека. STREAMS транслирует этот интерфейс в «родной» для Windows NT интерфейс канального уровня - NDIS 3.0.

Дополнительные функции для облегчения переноса, включая функции использования таймера ОС UNIX.

Среда NDIS

В 1989 г Microsoft и 3Com совместно разработали спецификацию интерфейса взаимодействия между подуровнем MAC канального уровня модели OSI и драйверами протоколов, располагающихся на вышележащих уровнях. Стандарт получил название Network Driver Interface Specification (NDIS - спецификация интерфейса сетевых драйверов). Он играет ключевую роль в сетевой архитектуре NT и служит для отделения логики работы драйвера сетевой карты от особенностей реализации различных сетевых протоколов.
С тех пор NDIS превратилась в целую семью сетевых стандартов, и сейчас эта семья включает стандарты для драйверов сетевых карт локальных и глобальных сетей (LAN NIC driver и WAN NIC driver), и стандарты для промежуточных драйверов (intermediate driver), располагающихся между драйверами протоколов и драйверами сетевых карт.
Вместо того чтобы писать несколько транспортно-зависимых драйверов, производители сетевого оборудования реализуют интерфейс NDIS на самом верхнем уровне одного драйвера сетевой карты. Это позволяет любому драйверу протокола работать с данной сетевой картой, вызывая функции этого интерфейса. Таким образом, пользователь может работать и по протоколу TCP/IP, и по протоколу NetBEUI, при помощи одной сетевой карты и одного драйвера этой сетевой карты.
Библиотека NDIS является драйвером, реализующим взаимодействие между компонентами, которые обращаются к ней, такими как: драйверы транспортов, NDIS драйверы промежуточного уровня, драйвер ndiswan.sys, драйвер ndistapi.sys, NDIS драйверы сетевых карт локальных и глобальных сетей. Интерфейс, реализуемый NDIS библиотекой, является «call and return» интерфейсом (асинхронным интерфейсом). Драйверы вызывают функции, расположенные в NDIS библиотеке, a NDIS библиотека может в свою очередь вызывать функции из других драйверов, чтобы выполнить операцию. Пакеты запроса ввода/вывода (IRP) не используются в NDIS спецификации.
Так как NDIS драйверы существуют в среде, созданной NDIS библиотекой, то структура и интерфейс, используемые этими драйверами, определяются NDIS библиотекой. Это позволяет NDIS драйверам быть переносимыми между различными операционными системами, поддерживающими данную спецификацию.
Цели NDIS библиотеки следующие:

Изолировать NDIS драйверы сетевых карт и промежуточные драйверы от операционной системы. NDIS библиотека экспортирует множество стандартных функций и макросов, которые скрывают детали операционной системы, и используются всеми NDIS драйверами. NDIS драйверы могут вызывать только те функции, которые обеспечивает NDIS библиотека. Например, создание таймера для целей синхронизации, или создание связанного списка осуществляется через NDIS. Требование к разработчикам применять вызовы NDIS функций позволяет сделать код переносимым между операционными системами фирмы Microsoft, которые поддерживают NDIS. Выполнять как можно больше общих операций. Одной из основных целей NDIS библиотеки является исключение кодов общих функций из NDIS драйверов. Это означает, что большинству NDIS драйверов необходимо реализовать только небольшое число функций, необходимых для выполнения операций, специфических для оборудования. NDIS библиотека поддерживает информацию о статусе операции, указатели на функции интерфейсов верхнего и нижнего уровней, параметры этих функций, и многие другие системные значения для драйверов протоколов и драйверов сетевых карт. Обеспечивать добавление заголовков к данным пользователя без необходимости их перекопирования, во время передачи данных по стеку сетевых драйверов. Во время перемещения сетевого сообщения по стеку драйверов сверху вниз, на каждом уровне к первоначальному сообщению может быть добавлен свой заголовок (реже хвост). NDIS спецификация делает возможным добавление подобных структур спереди или сзади без необходимости перекопирования первоначального сообщения. Эта возможность построения сетевого сообщения без перекопирований данных позволяет достигать высокой производительности при передаче данных.

NDIS-библиотека получает IRP-пакеты от TDI-транспортов и транслирует их в вызовы функций NDIS-драйверов. Для передачи данных между NDIS-драйверами пакеты IRP не используются. Вместо них используются, например, NDIS-пакеты, описанные в разделе «Особенности реализации NDIS-драйверов».

Типы NDIS драйверов

Спецификация NDIS определяет три типа сетевых драйверов:

драйверы протоколов верхнего уровня (upper level protocol drivers); драйверы протоколов промежуточного уровня (intermediate protocol drivers); драйверы сетевых карт (NIC drivers), сюда входят драйверы сетевых карт локальных сетей (NDIS LAN Miniport NIC drivers) и драйверы сетевых карт глобальных сетей (NDIS WAN Miniport NIC drivers).