CreateMailslotтакже принимает необязательный дескриптор защиты, контролирующий доступ клиента к почтовому ящику. Описатели, возвращаемые
CreateMailslot,являются
перекрытыми.
Это означает, что операции с использованием таких описателей (например, рассылка и получение сообщений) выполняются асинхронно.
Поскольку почтовые ящики поддерживают одностороннюю ненадежную передачу, число параметров CreateMailslotменьше, чем у CreateNamedPipe.После создания почтового ящика сервер просто отслеживает поступающие клиентские сообщения, вызывая функцию ReadFileи указывая описатель, представляющий почтовый ящик.
Клиенты почтового ящика используют формат именования, аналогичный применяемому клиентами именованных каналов, за исключением вариаций, необходимых для широковещательной передачи сообщений всем почтовым ящикам с данным именем в домене клиента или в другом указанном домене. Чтобы послать сообщение в определенный экземпляр почтового ящика, клиент вызывает функцию CreateFile,указывая имя, специфичное для компьютера, например «\\Сервер\Mailslot\ИмяПочтовогоЯщика». (Для представления локального компьютера клиент задает «\\.\».) Если клиент хочет получить описатель, представляющий все почтовые ящики с заданным именем в домене, членом которого он является, он указывает имя в формате «\\*\Mailslot\ ИмяПочтовогоЯщика». Для широковещательной передачи во все почтовые ящики с заданным именем в другом домене используется имя в формате «\\ИмяДомена\Mailslot\ИмяПочтовогоЯщика».
Получив описатель, представляющий клиентскую сторону почтового ящика, клиент посылает сообщения через функцию WriteFile.Реализация почтовых ящиков допускает широковещательную передачу сообщений длиной не более 425 байтов. Если длина сообщения превышает 425 байтов, почтовый ящик использует механизм надежной коммуникационной связи, требующий соединения клиента с сервером по типу «один к одному», что исключает возможность широковещательной передачи. Другая (довольно странная) особенность почтовых ящиков – урезание сообщений с исходной длиной в 425 или 426 байтов до 424 байтов. Таким образом, почтовые ящики непригодны для рассылки сообщений, длина которых превышает 424 байта. Ha рис. 13-10 показан пример широковещательной передачи клиентского сообщения на несколько серверов почтовых ящиков в пределах домена.
Позже мы обсудим, как драйвер файловой системы участвует в поиске удаленной системы по имени, которое задает удаленный именованный канал или почтовый ящик. Однако, когда именованный канал либо почтовый ящик создается сервером или открывается клиентом, в конечном счете вызывается соответствующий драйвер файловой системы (FSD) на той машине, где находится именованный канал или почтовый ящик. Именованные каналы и почтовые ящики реализованы в виде FSD режима ядра по нескольким причинам. Основной из них является интеграция с пространством имен диспетчера объектов, что позволяет использовать объекты «файл» для представления открытых именованных каналов и почтовых ящиков. Подобная интеграция дает следующие преимущества.
(o)Используя функции защиты режима ядра, FSD реализуют для именованных каналов и почтовых ящиков стандартную защиту Windows.
(o)Поскольку FSD интегрированы с пространством имен диспетчера объектов, приложения могут открывать именованный канал или почтовый ящик вызовом функции CreateFile.
(o)Приложения могут взаимодействовать с именованными каналами и почтовыми ящиками через Windows-функции вроде ReadFileи WriteFile.
(o)FSD полагаются на диспетчер объектов в поддержке счетчиков описателей и ссылок для объектов «файл», представляющих именованные каналы и почтовые ящики.
(o)FSD могут реализовать собственные пространства имен каналов и почтовых ящиков, допускающие указание подкаталогов.
Так как взаимодействие через сеть при разрешении имен именованных каналов и почтовых ящиков осуществляется через редиректор, FSD при этом неявно используют протокол CIFS (Common Internet File System). Поскольку CIFS способен работать с TCP/IP, TCP/IP с IPv6 и IPX, именованные каналы и почтовые ящики доступны приложениям, выполняемым в системах, где установлен хотя бы один общий такой протокол. (Сведения о CIFS см. в главе 12.)
ЭКСПЕРИМЕНТ: просмотр пространства имен именованных каналов и наблюдение за активностью таких каналов
Открыть корневой каталог FSD именованных каналов и перечислить его содержимое с помощью Windows API нельзя – для этого нужно воспользоваться сервисами встроенного API. Утилита PipeList ( www.sys- internals.com )перечисляет именованные каналы, определенные на компьютере, число созданных экземпляров канала с данным именем и максимальное число каналов, заданное сервером при вызове Create-NamedPipe.Вот пример вывода PipeList.
Из этого листинга ясно, что некоторые системные компоненты используют именованные каналы как механизм связи. Например, канал
InitShutdownсоздан Winlogon для приема удаленных команд на завершение работы, а канал
SecLogon –сервисом SecLogon для выполнения операций входа в интересах утилиты Runas. Определить, каким из процессов открыт каждый из этих каналов, можно с помощью утилиты Process Explorer
(
wwsysinternals.com
).Заметьте, что значение Max Instances, равное -1, означает, что на число экземпляров канала с данным именем не накладывается никаких ограничений.
Драйвер фильтра файловой системы Filemon ( wwwsysinternals.com )способен подключаться к драйверу файловой системы Npfs.sys или Msfs.sys, что позволяет ему наблюдать за активностью всех именованных каналов или почтовых ящиков в системе. Для подключения Filemon к соответствующему драйверу выберите из меню Drives команду Named Pipes или Mail Slots. Ha иллюстрации ниже показано окно Filemon, в котором сообщается об активности именованных каналов, вызываемой двойным щелчком значка My Network Places (Мое сетевое окружение) на рабочем столе. Заметьте, что сообщения передаются через именованные каналы LSASS и службы рабочей станции.
Windows – для поддержки взаимодействия с системами под управлением Windows NT 4 и потребительских версий Windows – автоматически определяет NetBIOS-имя для домена как первые 15 байтов DNS-имени (Domain Name System), назначенного домену администратором. Например, домен mspress.microsoft.com получает NetBIOS-имя mspress.Аналогичным образом Windows требует, чтобы во время установки администратор назначил каждому компьютеру NetBIOS-имя.
Еще одна концепция, используемая в NetBIOS, – номера адаптеров LAN (LANA). Номер LANA присваивается каждому NetBIOS-совместимому протоколу, расположенному на более высоком уровне, чем сетевой адаптер. Так, если в компьютере установлено два сетевых адаптера, доступных для TCP/ IP и NWLink, то в результате будет назначено четыре номера LANA. Номера LANA важны, поскольку приложения NetBIOS должны явно закреплять имена своих сервисов за каждым LANA, через который они готовы принимать клиентские соединения. Если приложение ждет соединений с клиентами по определенному имени, клиенты получат доступ к приложению только через протоколы, для которых зарегистрировано это имя.
Разрешение NetBIOS-имен в IP-адреса описывается в разделе «Windows Internet Name Service» далее в этой главе.
* Здесь авторы допускают неточность. 16-й байт NetBIOS-имени прежде всего является идентификатором типа ресурса. Он указывает сетевой компонент или службу, которая назначила это NetBIOS-имя компьютеру, пользователю или домену. Hy и, кроме того, NetBIOS-имя может быть зарегистрировано как уникальное (принадлежащее одному владельцу) или как групповое (принадлежащее нескольким владельцам). – Прим. перев.
Клиент, ориентированный на логические соединения, устанавливает соединение с сервером NetBIOS, а затем с помощью функций NetBIOS передает и принимает данные. Установленное NetBIOS-соединение также называется сеансом(session). Если клиент хочет посылать сообщения без установления логического соединения, он просто указывает NetBIOS-имя сервера при вызове функции передачи данных.
NetBIOS состоит из набора функций, но все они действуют через один и тот же интерфейс – Netbios.Это наследие тех времен, когда NetBIOS реализовали в виде прерывания MS-DOS. Приложение NetBIOS выполняло прерывание MS-DOS и передавало NetBIOS структуру данных, где задавались все параметры нужной команды. B итоге функция Netbiosв Windows принимает единственный параметр, который представляет собой структуру данных с параметрами, специфичными для запрошенного приложением сервиса.
ЭКСПЕРИМЕНТ: просмотр NetBIOS-имен через Nbtstat
Для вывода списка активных сеансов в системе, кэшируемых сопоставлений NetBIOS-имен и IP-адресов, а также NetBIOS-имен, определенных на компьютере, можно использовать встроенную в Windows команду Nbtstat…Ниже приведен пример вывода этой команды с параметром -n,при указании которого выводится список NetBIOS-имен, определенных на компьютере.
Если приложение требует использовать NetBIOS поверх TCP/IP, то эмулятору NetBIOS нужен драйвер NetBT (\Windows\System32\Drivers\Netbt.sys). NetBT отвечает за поддержку семантики NetBIOS, присущей не TCP/IP, а NetBEUI (NetBIOS Extended User Interface), который включался в предыдущие версии Windows. Например, NetBIOS полагается на NetBEUI-поддержку режима передачи данных в виде сообщений и на средства разрешения имен, поэтому драйвер NetBT реализует их поверх протокола TCP/IP. Аналогичным образом драйвер NwLinkNB реализует семантику NetBIOS поверх IPX/SPX.
RTC Client API, доступный в Windows XP и Windows Server 2003, позволяет разработчикам создавать приложения, способные устанавливать многорежимные коммуникационные соединения и превращать персональный компьютер (ПК) в центр домашних или деловых коммуникаций. Голосовая и видеосвязь, мгновенный обмен сообщениями (Instant Messaging, IM), поддержка совместной работы – все это становится доступным в одном сеансе коммуникационной связи. Помимо сеансов связи между ПК, этот API позволяет устанавливать сеансы связи «ПК-телефон», «телефон-телефон» или только текстового IM. B сеансах связи между ПК также доступны совместное использование приложений (application sharing) и общая электронная доска (whiteboard).
RTC поддерживает информацию о присутствии (presence information), на основе которой клиенты могут связываться с контактами через сервер-регистратор (registrar server), хранящий информацию о текущих адресах контактов. Адресом контакта может быть ПК или телефон, а в будущем и мобильный телефон, пейджер или другое карманное устройство. Например, если приложение пытается связаться с контактом по его рабочему адресу и информация о присутствии указывает на то, что данный контакт доступен через домашний ПК, RTC автоматически перенаправит соединение на этот адрес. RTC API также обеспечивает невмешательство в частную жизнь, позволяя блокировать определенные вызовы.
DCOM – это расширение СОМ, которое дает возможность размещать компоненты приложения на разных компьютерах, при этом приложению безразлично, что один СОМ-объект находится на локальном компьютере, а другой – на каком-то компьютере в локальной сети. Таким образом, DCOM упрощает разработку распределенных приложений. DCOM не является автономным API – в своей работе он опирается на RPC.
Примечательная особенность Message Queuing – его интеграция с MTS (Microsoft Transaction Server) и SQL Server, что дает возможность Message Queuing участвовать в транзакциях, координируемых MS DTC (Microsoft Distributed Transaction Coordinator). Используя MS DTC c Message Queuing, можно разрабатывать для трехуровневых приложений надежные компоненты, отвечающие за обработку транзакций.
Windows собственные редиректоры. B этом разделе мы расскажем о программном обеспечении, которое решает, какой редиректор следует вызвать для обработки запроса на удаленный ввод-вывод. За это отвечают следующие компоненты.
(o) Маршрутизатор многосетевого доступа (multiple provider router, MPR)Это DLL ( \Windows\System32\Mpr.dll), определяющая, к какой сети следует обратиться, когда приложение использует Windows WNet API для просмотра удаленной файловой системы.
(o) Многосетевой UNC-провайдер (multiple UNC provider, MUP)Драйвер (\Windows\System32\Drivers\Mup.sys), определяющий, к какой сети следует обратиться, когда приложение использует Windows API ввода-вывода для открытия удаленных файлов.
Провайдер(provider) – это программный компонент, позволяющий Windows выступать в качестве клиента какого-либо удаленного сервера. B число операций, выполняемых провайдером WNet, входят установление и разрыв сетевых соединений, удаленная печать и передача данных. Встроенный провайдер WNet включает DLL, службу рабочей станции и редиректор. Поставщики других сетей должны предоставлять только DLL и редиректор.
Когда приложение вызывает некую функцию WNet, этот вызов передается непосредственно MPR DLL. MPR принимает вызов и определяет, какой из провайдеров WNet распознает запрошенный ресурс. Все DLL провайдеров, расположенные ниже MPR, предоставляют набор стандартных функций, в совокупности называемых интерфейсом сетевого доступа(network provider interface). Этот интерфейс позволяет MPR определить, к какой сети пытается обратиться приложение, и направить вызов соответствующему провайдеру WNet. Провайдером службы рабочей станции является \Windows\System32\Ntlanman.dll, что указывается в параметре ProviderPath в разделе реестра HKLM\SYSTEM\CurrentControlSet\Services\LanManWorkstation\NetworkProvider.
Рис. 13-14.
Редактор порядка провайдеров (служб доступа к сети)
Когда MPR вызывается для подключения к удаленному сетевому ресурсу API-функцией WNetAddConnection,он просматривает в реестре параметр HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder\ProviderOrder, чтобы определить, какие провайдеры сетей загружены. Далее он опрашивает их в том порядке, в каком они перечислены в реестре, и делает это до тех пор, пока один из них не распознает сетевой ресурс или пока все они не будут опрошены. Параметр ProviderOrder можно изменить через диалоговое окно Advanced Settings (Дополнительные параметры), показанное на рис. 13-14. (B системе, в которой был сделан этот экранный снимок, установлен только один провайдер.) B Windows 2000 или при настройке меню Start (Пуск) в традиционном стиле это диалоговое окно вызывается из меню Advanced (Дополнительно) апплета Network Connections (Сетевые подключения), который запускается несколькими способами. Вы можете, например, щелкнуть правой кнопкой мыши значок My Network Places (Мое сетевое окружение) на рабочем столе и выбрать из контекстного меню команду Properties (Свойства), либо открыть меню Start (Пуск), затем подменю Settings (Настройка) и выбрать команду Network Connections (Сетевые подключения).
Функция WNetAddConnectionможет также назначить удаленному ресурсу букву диска или имя устройства. B этом случае она направляет вызов соответствующему компоненту сетевого доступа. Тот в свою очередь создает объект «символьная ссылка» в пространстве имен диспетчера объектов, и этот объект увязывает данную букву диска с редиректором нужной сети (т. е. с удаленным FSD).
Ha рис. 13-15 показан каталог \?? в системе Windows 2000, в котором вы заметите несколько букв диска, представляющих соединения с удаленными файловыми ресурсами. Как видите, редиректор создает объект «устройство» с именем \Device\LanmanRedirector, а дополнительный текст, который входит в значение символьной ссылки, сообщает редиректору, какому удаленному ресурсу соответствует буква диска. Когда пользователь открывает X:\ Book\Chapl3.doc, редиректору передается неразобранная часть пути, которая разрешается через символьную ссылку как «;X:0\dual\e\Book\ Chapl3doc». Редиректор отмечает, что данный ресурс расположен на общем диске E сервера dual
Как и встроенный редиректор, другие редиректоры тоже создают объект «устройство» в пространстве имен диспетчера объектов в процессе своей загрузки и инициализации. После этого, когда WNet или другой API обращается к диспетчеру объектов для открытия ресурса, расположенного в другой сети, диспетчер использует данный объект «устройство» как точку входа в удаленную файловую систему Он вызывает метод разбора, принадлежащий диспетчеру ввода-вывода и сопоставленный с объектом, для поиска FSD редиректора, способного обработать данный запрос (о драйверах файловых систем см. главу 12).
При загрузке MUP создает объект «устройство» с именем \Device\Mup. Когда сетевой редиректор вроде CIFS загружает редиректор, тот создает именованный объект «устройство» (скажем, \Device\LanmanRedirector) и регистрируется в MUP как UNC-провайдер вызовом функции
FsRtlRegister.
UncProvider.Если этот редиректор – первый из зарегистрированных и если поддержка DFS-клиента в MUP отключена, то FsRtlRegisterUncProviderсоздает символьную ссылку \??\UNC, которая указывает на объект «устройство» редиректора; в ином случае MUP настраивает символьную ссылку \Global??\ UNC (\??\UNC в Windows 2000) так, чтобы она указывала на его объект «устройство», \Device\MUP
Драйвер MUP активизируется, когда приложение впервые пытается открыть удаленный файл или устройство по UNC-имени (а не по букве сетевого диска). Получив запрос на ввод-вывод с UNC-путем, Kernel32.dll (экспортирующая API-функции файлового ввода-вывода) на клиентской стороне добавляет переданный в запросе UNC-путь к строке \Global??\UNC после чего вызывает системный сервис
Это означает, что операции с использованием таких описателей (например, рассылка и получение сообщений) выполняются асинхронно.
Поскольку почтовые ящики поддерживают одностороннюю ненадежную передачу, число параметров CreateMailslotменьше, чем у CreateNamedPipe.После создания почтового ящика сервер просто отслеживает поступающие клиентские сообщения, вызывая функцию ReadFileи указывая описатель, представляющий почтовый ящик.
Клиенты почтового ящика используют формат именования, аналогичный применяемому клиентами именованных каналов, за исключением вариаций, необходимых для широковещательной передачи сообщений всем почтовым ящикам с данным именем в домене клиента или в другом указанном домене. Чтобы послать сообщение в определенный экземпляр почтового ящика, клиент вызывает функцию CreateFile,указывая имя, специфичное для компьютера, например «\\Сервер\Mailslot\ИмяПочтовогоЯщика». (Для представления локального компьютера клиент задает «\\.\».) Если клиент хочет получить описатель, представляющий все почтовые ящики с заданным именем в домене, членом которого он является, он указывает имя в формате «\\*\Mailslot\ ИмяПочтовогоЯщика». Для широковещательной передачи во все почтовые ящики с заданным именем в другом домене используется имя в формате «\\ИмяДомена\Mailslot\ИмяПочтовогоЯщика».
Получив описатель, представляющий клиентскую сторону почтового ящика, клиент посылает сообщения через функцию WriteFile.Реализация почтовых ящиков допускает широковещательную передачу сообщений длиной не более 425 байтов. Если длина сообщения превышает 425 байтов, почтовый ящик использует механизм надежной коммуникационной связи, требующий соединения клиента с сервером по типу «один к одному», что исключает возможность широковещательной передачи. Другая (довольно странная) особенность почтовых ящиков – урезание сообщений с исходной длиной в 425 или 426 байтов до 424 байтов. Таким образом, почтовые ящики непригодны для рассылки сообщений, длина которых превышает 424 байта. Ha рис. 13-10 показан пример широковещательной передачи клиентского сообщения на несколько серверов почтовых ящиков в пределах домена.
Реализация именованных каналов и почтовых ящиков
O тесной интеграции функций именованных каналов и почтовых ящиков с Windows свидетельствует тот факт, что все они реализованы в Kernel32.dll. ReadFileи WriteFile,используемые приложениями для обмена сообщениями через именованные каналы и почтовые ящики, являются основными Windows-функциями ввода-вывода. CreateFile,с помощью которой клиент открывает именованный канал или почтовый ящик, также является стандартной Windows-функцией ввода-вывода. Однако имена, указываемые приложениями при использовании именованных каналов и почтовых ящиков, относятся к пространству имен под управлением драйверов файловых систем именованных каналов (\Windows\System32\Drivers\Npfs.sys) и почтовых ящиков (\Windows\System32\Drivers\Msfs.sys), как показано на рис. 13-11. Драйвер файловой системы именованных каналов создает объект «устройство» \Device\NamedPipe и символьную ссылку на этот объект с именем \Global??\Pipe (\??\Pipe в Windows 2000), а драйвер файловой системы почтовых ящиков создает объект «устройство» \Device\Mailslot и символьную ссылку \Global??\Mailslot (\??\Mailslot в Windows 2000), которая указывает на этот объект. (O каталоге \Global?? диспетчера объектов см. главу 3.) Префикс «\\.\» в именах «\\.\Pipe\…» и «\\.\Mailslot\…», передаваемых CreateFile,транслируется в «\Global??\», чтобы эти имена разрешались через символьную ссылку на объект «устройство». Специальные функции CreateNamedPipeи CreateMailslotиспользуют соответствующие функции ядра NtCreateNamed-PipeFileи NtCreateMailslotFile.(o)Используя функции защиты режима ядра, FSD реализуют для именованных каналов и почтовых ящиков стандартную защиту Windows.
(o)Поскольку FSD интегрированы с пространством имен диспетчера объектов, приложения могут открывать именованный канал или почтовый ящик вызовом функции CreateFile.
(o)Приложения могут взаимодействовать с именованными каналами и почтовыми ящиками через Windows-функции вроде ReadFileи WriteFile.
(o)FSD полагаются на диспетчер объектов в поддержке счетчиков описателей и ссылок для объектов «файл», представляющих именованные каналы и почтовые ящики.
(o)FSD могут реализовать собственные пространства имен каналов и почтовых ящиков, допускающие указание подкаталогов.
Так как взаимодействие через сеть при разрешении имен именованных каналов и почтовых ящиков осуществляется через редиректор, FSD при этом неявно используют протокол CIFS (Common Internet File System). Поскольку CIFS способен работать с TCP/IP, TCP/IP с IPv6 и IPX, именованные каналы и почтовые ящики доступны приложениям, выполняемым в системах, где установлен хотя бы один общий такой протокол. (Сведения о CIFS см. в главе 12.)
ЭКСПЕРИМЕНТ: просмотр пространства имен именованных каналов и наблюдение за активностью таких каналов
Открыть корневой каталог FSD именованных каналов и перечислить его содержимое с помощью Windows API нельзя – для этого нужно воспользоваться сервисами встроенного API. Утилита PipeList ( www.sys- internals.com )перечисляет именованные каналы, определенные на компьютере, число созданных экземпляров канала с данным именем и максимальное число каналов, заданное сервером при вызове Create-NamedPipe.Вот пример вывода PipeList.
Драйвер фильтра файловой системы Filemon ( wwwsysinternals.com )способен подключаться к драйверу файловой системы Npfs.sys или Msfs.sys, что позволяет ему наблюдать за активностью всех именованных каналов или почтовых ящиков в системе. Для подключения Filemon к соответствующему драйверу выберите из меню Drives команду Named Pipes или Mail Slots. Ha иллюстрации ниже показано окно Filemon, в котором сообщается об активности именованных каналов, вызываемой двойным щелчком значка My Network Places (Мое сетевое окружение) на рабочем столе. Заметьте, что сообщения передаются через именованные каналы LSASS и службы рабочей станции.
NetBIOS
До начала 90-х годов NetBIOS (Network Basic Input/Output System) API был самым популярным интерфейсом программирования для персональных компьютеров. NetBIOS поддерживал связь как надежную, ориентированную на логические соединения, так и ненадежную, не требующую логических соединений. Windows поддерживает NetBIOS для совместимости с унаследованными приложениями. Microsoft не рекомендует разработчикам приложений использовать NetBIOS, поскольку существуют куда более гибкие и переносимые API, например именованные каналы и Winsock. NetBIOS в Windows поддерживается протоколами TCP/IP и IPX/SPX.NetBIOS-имена
NetBIOS использует правила именования, согласно которым компьютерам и сетевым службам назначаются 16-байтовые имена, называемые NetBIOS-именами; 16-й байт в NetBIOS-имени интерпретируется как модификатор, который указывает, является ли имя уникальным или групповым.* Уникальное NetBIOS-имя может быть назначено только одному компьютеру или службе в сети, а групповое имя ~ нескольким компьютерам или службам. Адресуя сообщение на групповое имя, клиент может вести широковещательную рассылку.Windows – для поддержки взаимодействия с системами под управлением Windows NT 4 и потребительских версий Windows – автоматически определяет NetBIOS-имя для домена как первые 15 байтов DNS-имени (Domain Name System), назначенного домену администратором. Например, домен mspress.microsoft.com получает NetBIOS-имя mspress.Аналогичным образом Windows требует, чтобы во время установки администратор назначил каждому компьютеру NetBIOS-имя.
Еще одна концепция, используемая в NetBIOS, – номера адаптеров LAN (LANA). Номер LANA присваивается каждому NetBIOS-совместимому протоколу, расположенному на более высоком уровне, чем сетевой адаптер. Так, если в компьютере установлено два сетевых адаптера, доступных для TCP/ IP и NWLink, то в результате будет назначено четыре номера LANA. Номера LANA важны, поскольку приложения NetBIOS должны явно закреплять имена своих сервисов за каждым LANA, через который они готовы принимать клиентские соединения. Если приложение ждет соединений с клиентами по определенному имени, клиенты получат доступ к приложению только через протоколы, для которых зарегистрировано это имя.
Разрешение NetBIOS-имен в IP-адреса описывается в разделе «Windows Internet Name Service» далее в этой главе.
* Здесь авторы допускают неточность. 16-й байт NetBIOS-имени прежде всего является идентификатором типа ресурса. Он указывает сетевой компонент или службу, которая назначила это NetBIOS-имя компьютеру, пользователю или домену. Hy и, кроме того, NetBIOS-имя может быть зарегистрировано как уникальное (принадлежащее одному владельцу) или как групповое (принадлежащее нескольким владельцам). – Прим. перев.
Функционирование NetBIOS
Серверное приложение NetBIOS использует NetBIOS API для перечисления LANA, имеющихся в системе, и назначения каждому из них NetBIOS-имени, представляющего сервис приложения. Если сервер требует логических соединений, он выполняет NetBIOS-команду listenдля ожидания попыток подключения клиентов. После того как соединение с клиентом установлено, сервер выполняет функции NetBIOS для передачи и приема данных. Аналогичным образом осуществляется и связь, не требующая логических соединений, но сервер просто принимает сообщения, не устанавливая соединение.Клиент, ориентированный на логические соединения, устанавливает соединение с сервером NetBIOS, а затем с помощью функций NetBIOS передает и принимает данные. Установленное NetBIOS-соединение также называется сеансом(session). Если клиент хочет посылать сообщения без установления логического соединения, он просто указывает NetBIOS-имя сервера при вызове функции передачи данных.
NetBIOS состоит из набора функций, но все они действуют через один и тот же интерфейс – Netbios.Это наследие тех времен, когда NetBIOS реализовали в виде прерывания MS-DOS. Приложение NetBIOS выполняло прерывание MS-DOS и передавало NetBIOS структуру данных, где задавались все параметры нужной команды. B итоге функция Netbiosв Windows принимает единственный параметр, который представляет собой структуру данных с параметрами, специфичными для запрошенного приложением сервиса.
ЭКСПЕРИМЕНТ: просмотр NetBIOS-имен через Nbtstat
Для вывода списка активных сеансов в системе, кэшируемых сопоставлений NetBIOS-имен и IP-адресов, а также NetBIOS-имен, определенных на компьютере, можно использовать встроенную в Windows команду Nbtstat…Ниже приведен пример вывода этой команды с параметром -n,при указании которого выводится список NetBIOS-имен, определенных на компьютере.
Реализация NetBIOS API
Компоненты, реализующие NetBIOS API, показаны на рис. 13-12. Функция Netbiosэкспортируется приложениям из \Windows\System32\Netapi32.dll. Netapi32.dll открывает описатель драйвера режима ядра под названием эму-nnmopNetBlOS(\Windows\System32\Drivers\Netbios.sys) и выдает Windows-команды DeviceIoControlFileот имени приложения. Эмулятор NetBIOS транслирует команды NetBIOS в команды TDI, посылаемые драйверам протоколов.Другие сетевые API
B Windows входит еще несколько сетевых API, которые используются реже и расположены на более высоком уровне, чем уже рассмотренные API. Изучение всех этих API выходит за рамки книги, но четыре из них – RTC (Real-Time Communications), DCOM (Distributed Component Object Model), Message Queuing и UPnP (Universal Plug and Play) – достаточно важны для функционирования Windows и многих приложений и поэтому заслуживают краткого описания.
RTC
RTC Client API, доступный в Windows XP и Windows Server 2003, позволяет разработчикам создавать приложения, способные устанавливать многорежимные коммуникационные соединения и превращать персональный компьютер (ПК) в центр домашних или деловых коммуникаций. Голосовая и видеосвязь, мгновенный обмен сообщениями (Instant Messaging, IM), поддержка совместной работы – все это становится доступным в одном сеансе коммуникационной связи. Помимо сеансов связи между ПК, этот API позволяет устанавливать сеансы связи «ПК-телефон», «телефон-телефон» или только текстового IM. B сеансах связи между ПК также доступны совместное использование приложений (application sharing) и общая электронная доска (whiteboard).RTC поддерживает информацию о присутствии (presence information), на основе которой клиенты могут связываться с контактами через сервер-регистратор (registrar server), хранящий информацию о текущих адресах контактов. Адресом контакта может быть ПК или телефон, а в будущем и мобильный телефон, пейджер или другое карманное устройство. Например, если приложение пытается связаться с контактом по его рабочему адресу и информация о присутствии указывает на то, что данный контакт доступен через домашний ПК, RTC автоматически перенаправит соединение на этот адрес. RTC API также обеспечивает невмешательство в частную жизнь, позволяя блокировать определенные вызовы.
DCOM
Microsoft COM API позволяет составлять приложения из компонентов, и каждый компонент представляет собой заменяемый самодостаточный модуль. Любой СОМ-объект экспортирует объектно-ориентированный интерфейс для манипулирования своими данными. Поскольку СОМ-объекты предоставляют четко определенные интерфейсы, разработчики могут реализовать новые объекты для расширения существующих интерфейсов и динамического добавления новой функциональности в приложения.DCOM – это расширение СОМ, которое дает возможность размещать компоненты приложения на разных компьютерах, при этом приложению безразлично, что один СОМ-объект находится на локальном компьютере, а другой – на каком-то компьютере в локальной сети. Таким образом, DCOM упрощает разработку распределенных приложений. DCOM не является автономным API – в своей работе он опирается на RPC.
Message Queuing
Message Queuing представляет собой универсальную платформу для разработки распределенных приложений, использующих преимущества свободно связанного обмена сообщениями (loosely coupled messaging). Поэтому Message Queuing является также API-интерфейсом и инфраструктурой передачи сообщений. Гибкость Message Queuing определяется тем, что его очереди служат репозитариями сообщений, в которые отправители помещают сообщения для посылки получателям и из которых получатели извлекают адресованные им сообщения. Отправителям и получателям не требуется ни устанавливать соединения, ни работать в одно и то же время. A это позволяет асинхронно обмениваться сообщениями, не устанавливая прямых соединений.Примечательная особенность Message Queuing – его интеграция с MTS (Microsoft Transaction Server) и SQL Server, что дает возможность Message Queuing участвовать в транзакциях, координируемых MS DTC (Microsoft Distributed Transaction Coordinator). Используя MS DTC c Message Queuing, можно разрабатывать для трехуровневых приложений надежные компоненты, отвечающие за обработку транзакций.
UPnP
Universal Plug and Play (UPnP) – это распределенная, открытая сетевая архитектура для поддержки соединений с интеллектуальными устройствами и точками управления (control points), подключенными к домашним сетям, интрасетям или напрямую к Интернету. Она построена на принятых стандартах и опирается на существующие технологии TCP/IP и Web. UPnP не требует конфигурирования и поддерживает автоматическое распознавание широкого спектра устройств. Она позволяет устройству динамически подключаться к сети, получать IP-адрес и сообщать о своих возможностях, когда поступает соответствующий запрос. Точки управления могут применять Control Point API в сочетании с технологией UPnP для определения присутствия и возможностей остальных устройств в сети. Устройство может автоматически выходить из сети, если оно больше не используется.Поддержка нескольких редиректоров
У приложений есть два способа просмотра удаленных ресурсов или доступа к ним. Один из них заключается в использовании стандарта UNC и прямой адресации к удаленным ресурсам через Windows-функции, а второй – в применении Windows Networking (WNet) API для перечисления компьютеров и экспортируемых ими ресурсов. Оба подхода опираются на возможности редиректора. Для доступа клиентов к CIFS-серверам Microsoft поставляет редиректор CIFS, у которого есть компонент режима ядра (FSD редиректора) и компонент пользовательского режима (служба рабочей станции). Microsoft также предоставляет редиректор, способный обращаться к ресурсам серверов Novell NetWare, а сторонние разработчики могут добавлять вWindows собственные редиректоры. B этом разделе мы расскажем о программном обеспечении, которое решает, какой редиректор следует вызвать для обработки запроса на удаленный ввод-вывод. За это отвечают следующие компоненты.
(o) Маршрутизатор многосетевого доступа (multiple provider router, MPR)Это DLL ( \Windows\System32\Mpr.dll), определяющая, к какой сети следует обратиться, когда приложение использует Windows WNet API для просмотра удаленной файловой системы.
(o) Многосетевой UNC-провайдер (multiple UNC provider, MUP)Драйвер (\Windows\System32\Drivers\Mup.sys), определяющий, к какой сети следует обратиться, когда приложение использует Windows API ввода-вывода для открытия удаленных файлов.
Маршрутизатор многосетевого доступа
Windows-функции WNet позволяют приложениям (включая Windows Explorer и My Network Places) подключаться к сетевым ресурсам (файлам и принтерам), а также просматривать содержимое удаленных файловых систем любого типа. Так как этот API предназначен для работы с различными сетями и по разным протоколам, необходимо специальное программное обеспечение, способное посылать запросы по сети и правильно интерпретировать результаты, получаемые от удаленных серверов. Это программное обеспечение показано на рис. 13-13.Когда приложение вызывает некую функцию WNet, этот вызов передается непосредственно MPR DLL. MPR принимает вызов и определяет, какой из провайдеров WNet распознает запрошенный ресурс. Все DLL провайдеров, расположенные ниже MPR, предоставляют набор стандартных функций, в совокупности называемых интерфейсом сетевого доступа(network provider interface). Этот интерфейс позволяет MPR определить, к какой сети пытается обратиться приложение, и направить вызов соответствующему провайдеру WNet. Провайдером службы рабочей станции является \Windows\System32\Ntlanman.dll, что указывается в параметре ProviderPath в разделе реестра HKLM\SYSTEM\CurrentControlSet\Services\LanManWorkstation\NetworkProvider.
Когда MPR вызывается для подключения к удаленному сетевому ресурсу API-функцией WNetAddConnection,он просматривает в реестре параметр HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder\ProviderOrder, чтобы определить, какие провайдеры сетей загружены. Далее он опрашивает их в том порядке, в каком они перечислены в реестре, и делает это до тех пор, пока один из них не распознает сетевой ресурс или пока все они не будут опрошены. Параметр ProviderOrder можно изменить через диалоговое окно Advanced Settings (Дополнительные параметры), показанное на рис. 13-14. (B системе, в которой был сделан этот экранный снимок, установлен только один провайдер.) B Windows 2000 или при настройке меню Start (Пуск) в традиционном стиле это диалоговое окно вызывается из меню Advanced (Дополнительно) апплета Network Connections (Сетевые подключения), который запускается несколькими способами. Вы можете, например, щелкнуть правой кнопкой мыши значок My Network Places (Мое сетевое окружение) на рабочем столе и выбрать из контекстного меню команду Properties (Свойства), либо открыть меню Start (Пуск), затем подменю Settings (Настройка) и выбрать команду Network Connections (Сетевые подключения).
Функция WNetAddConnectionможет также назначить удаленному ресурсу букву диска или имя устройства. B этом случае она направляет вызов соответствующему компоненту сетевого доступа. Тот в свою очередь создает объект «символьная ссылка» в пространстве имен диспетчера объектов, и этот объект увязывает данную букву диска с редиректором нужной сети (т. е. с удаленным FSD).
Ha рис. 13-15 показан каталог \?? в системе Windows 2000, в котором вы заметите несколько букв диска, представляющих соединения с удаленными файловыми ресурсами. Как видите, редиректор создает объект «устройство» с именем \Device\LanmanRedirector, а дополнительный текст, который входит в значение символьной ссылки, сообщает редиректору, какому удаленному ресурсу соответствует буква диска. Когда пользователь открывает X:\ Book\Chapl3.doc, редиректору передается неразобранная часть пути, которая разрешается через символьную ссылку как «;X:0\dual\e\Book\ Chapl3doc». Редиректор отмечает, что данный ресурс расположен на общем диске E сервера dual
Многосетевой UNC-провайдер
Многосетевой UNC-провайдер (Multiple UNC Provider, MUP) – сетевой компонент, сходный с MPR. Он обрабатывает запросы ввода-вывода (адресованные к файлам или устройствам) с UNC-именами (именами, которые начинаются с символов \\, указывающих, что данный ресурс находится в сети). MUP, как и MPR, определяет; какой локальный редиректор распознает удаленный ресурс. Ho MUP в отличие от MPR является драйвером устройства (загружаемым при загрузке системы), который выдает запросы на ввод-вывод драйверам более низкого уровня, в данном случае – редиректорам, как показано на рис. 13-16. Mup.sys также содержит клиентскую реализацию Distributed File System (DFS). Клиент DFS включен по умолчанию, и его можно отключить, присвоив DWORD-параметру реестра HKLM\System\CurrentCont-rolSet\Services\Mup\DisableDfs значение 1.UncProvider.Если этот редиректор – первый из зарегистрированных и если поддержка DFS-клиента в MUP отключена, то FsRtlRegisterUncProviderсоздает символьную ссылку \??\UNC, которая указывает на объект «устройство» редиректора; в ином случае MUP настраивает символьную ссылку \Global??\ UNC (\??\UNC в Windows 2000) так, чтобы она указывала на его объект «устройство», \Device\MUP
Драйвер MUP активизируется, когда приложение впервые пытается открыть удаленный файл или устройство по UNC-имени (а не по букве сетевого диска). Получив запрос на ввод-вывод с UNC-путем, Kernel32.dll (экспортирующая API-функции файлового ввода-вывода) на клиентской стороне добавляет переданный в запросе UNC-путь к строке \Global??\UNC после чего вызывает системный сервис