Программирование в сетях Windows. Э. Джонс, Д. Оланд
Скачать 2.88 Mb.
|
Г Л А В А 1 интерфейс I Команда поиска имени {NCBFINDNAME) Эта команда доступна только в Windows NT и Windows 2000, сообщает, кто зарегистрировал данное имя NetBIOS. Чтобы успешно выполнить запрос на поиск имени, процесс должен добавить свое уникальное имя в таблицу имен. Для этого необходимо задать следующие поля: команда, номер LANA, буфер и длина буфера. Запрос вернет структуру FJND_NAME_HEADER и несколько структур FIND_NAME_BUFFER, определенных следующим образом: typedef struct _FIND_NAME_HEADER { WORD node_count; UCHAR reserved; UCHAR unique_group; } FIND_NAME_HEADER, *PFIND_NAME_HEADER; typedef struct _FIND_NAME_BUFFER { UCHAR length; UCHAR access_control; UCHAR frame_control; UCHAR destination_addr[6]; UCHAR source_addr[6]; UCHAR routing_info[18]; } FIND_NAME_BUFFER, *PFIND_NAME_BUFFER; Как и в случае команды проверки состояния адаптера, если команда NCB- FINDNAME выполняется с длиной буфера равной 0, функция Netbios вернет требуемую длину и ошибку NRC_BUFLEN. Структура FIND_NAME_HEADER, которую возвращает успешный опрос, показывает, зарегистрировано ли имя как уникальное или как групповое. Если поле unique_group содержит 0 — это уникальное имя, если 1 — груп- повое. Поле node_count указывает, сколько было возвращено структур FIND_ NAMEJBUFFERS. Структура FIND_NAME_BUFFER возвращает совсем немного информации, большая часть которой полезна на уровне протокола. Одна- ко нас интересуют поля destination_addr и source_addr. Поле source_addr содержит МАС-адрес сетевого адаптера, зарегистрировавшего имя, а поле destination_addr — МАС-адрес адаптера, выполнившего запрос. Запрос на поиск имени может быть отдан на любом номере LANA на ло- кальном компьютере. Возвращенные данные должны быть одинаковы на всех действительных LANA в локальной сети (вы можете выполнить коман- ду поиска имени для RAS-подключения, чтобы определить, зарегистрирова- но ли имя в удаленной сети). Если в Windows NT 4 поиск имени выполняется по протоколу TCP/IP, Netbios возвращает ложную информацию. Убедитесь, что выбран номер LANA, соответствующий транспорту, отличному от TCP/IP. Сопоставление протоколов номерам LANA В зависимости от того, какой транспорт использует ваше приложение, мо- гут возникать разные проблемы, так что неплохо уметь программно опре- 52 ЧАСТЬ I Устаревшие сетевые API делять доступные транспорты. Это невозможно сделать средствами «родно- го» опроса NetBIOS — надо использовать Winsock 2 для Windows NT 4 и Windows 2000. Функция Winsock 2 WSAEnumProtocols возвращает информа- цию о доступных транспортных протоколах (подробнее о ней — в главах 5 и 6). Хотя Winsock 2 доступен в Windows 95 и, по умолчанию, в Windows 98, информация о протоколе, хранимая на этих платформах, не содержит ни- каких сведений о NetBIOS. Мы не будем подробно обсуждать Winsock 2, поскольку этому интерфей- су посвящена часть II этой книги. Основные шаги следующие: загрузка Winsock 2 через функцию WSAStartup, вызов функции WSAEnumProtocols и просмотр возвращенных запросом структур WSAPROTOCOLJNFO. Пример Nbproto.c на прилагаемом компакт-диске содержит код для выполнения та- кого опроса. Функция WSAEnumProtocols принимает в качестве параметров адрес буфе- ра для блока данных и длину буфера. Сначала вызовите эту функцию с ну- левыми адресом и длиной буфера. Вызов будет неудачным, но параметр дли- ны буфера теперь содержит требуемый размер. Вызовите функцию снова — WSAEnumProtocols вернет количество найденных протоколов. Структура WSA- PROTOCOLJNFO велика и содержит множество полей, но нас интересуют только szProtocol, iAddressFamily и iProtocol. Если поле iAddressFamily равно AF_NETBIOS, то абсолютное значение iProtocol — номер LANA для протоко- ла, указанного в строке szProtocol. Кроме того, для сопоставления возвращен- ного протокола предопределенному GUID протокола можно использовать Providerld GUID. Здесь есть один нюанс. В Windows NT и Windows 2000 поле iProtocol для любого протокола, установленного на LANA 0, имеет значение 0x80000000. Дело в том, что протокол 0 зарезервирован для специального использова- ния; любой протокол, назначенный LANA 0, всегда будет иметь значение 0x80000000, так что надо просто проверить это значение. Рекомендации по выбору платформ Реализуя связь средствами NetBIOS на следующих платформах, имейте в виду следующие ограничения. Платформа Windows СЕ Интерфейс NetBIOS в Windows СЕ не доступен. Перенаправитель поддержи- вает имена и разрешения имен NetBIOS, но не программный интерфейс. Платформа Windows 9x В Windows 95 и Windows 98 есть несколько ошибок. На любой из этих плат- форм вы должны сбросить все номера LANA перед добавлением любого име- ни NetBIOS к любому номеру LANA. Так как сброс одного номера LANA раз- рушает таблицы имен других номеров, избегайте кода, подобного следую- щему. Г Л А В А 1 Интерфейс NetBIOS 53 i.ANA_ENUM lenum; // Перечисление номеров LANA for(i = 0; i < lenum.length; < Reset(lenum.lana[i]); AddName(lenum.lana[i], MY_NETBIOS_NAME); } Кроме того, не пытайтесь асинхронно выполнить в Windows 95 команду NCBRESET на соответствующем протоколу TCP/IP номере LANA. Для начала, не следует отдавать эту команду асинхронно, так как прежде, чем вы сможе- те сделать что-нибудь с этим номером LANA, должен завершиться сброс. При асинхронном выполнении команды NCBRESET приложение вызовет фаталь- ную ошибку в драйвере виртуального устройства (virtual device driver, VXD) NetBIOS TCP/IP и придется перезагружать компьютер. Для любых платформ При сеансовой связи одна сторона может посылать сколь угодно много дан- ных, однако отправитель на деле буферизует посылаемые данные, пока по- лучатель не подтвердит их получение, отдав команду приема. NetBIOS-ко- манды NCBSENDNA и NCBCHAINSENDNA — варианты команд отправки, не требующие подтверждения. Вы можете использовать их, если намеренно не хотите, чтобы команда отправки ждала подтверждения от получателя. По- скольку в нижележащем протоколе TCP/IP реализована собственная схема подтверждения, команды отправки, не требующие подтверждения от полу- чателя, ведут себя так же, как и ожиадающие подтверждения. Резюме NetBIOS — мощный, но устаревший прикладной интерфейс. Одна из его сильных сторон — независимость от протокола: приложения могут работать поверх TCP/IP, NetBEUI и SPX/IPX. NetBIOS обеспечивает связь с установле- нием логического соединения и без такового. Значительное преимущество интерфейса NetBIOS перед Winsock — единый способ разрешения имен и регистрации. Приложение NetBIOS нуждается только в имени NetBIOS, a приложение Winsock, использующее разные протоколы, должно знать схе- му адресации каждого (см. часть II). В главе 2 речь пойдет о перенаправителе — составной части почтовых ящиков и именованных каналов (о них — в главах 3 и 4). Г Л А В А Перенаправитель Microsoft Windows позволяет приложениям обмениваться информацией по сети с помощью встроенных служб файловой системы, иногда называемых сетевой операционной системой (network operating system, NOS). В этой гла- ве описываются сетевые возможности, использующие компоненты файло- вой системы Windows, и доступные в Windows 95, Windows 98, Windows NT, Windows 2000 и Windows СЕ. Они основаны на сетевых технологиях почто- вых ящиков (mailslot) и именованных каналов (named pipe), о которых речь пойдет в главах 3 и 4. Для доступа к локальным файлам приложения посылают запросы ввода- вывода операционной системы (обычно это называется локальным вводом- выводом). Например, когда приложение открывает или закрывает файл, ОС определяет устройство, на котором находится данный файл, и передает зап- рос ввода-вывода локальному драйверу этого устройства. Аналогично осу- ществляется доступ к устройствам по сети, только запрос ввода-вывода пе- редается по сети удаленному устройству. Это называется перенаправлением ввода-вывода (I/O redirection). Например, Windows позволяет назначить имя локального диска (скажем, Е:) общей папке на удаленном компьютере. Тог- да при обращении приложений к диску Е: ОС будет перенаправлять запро- сы ввода-вывода на устройство, называемое перенаправителем (redirector), a он — формировать канал связи к удаленному компьютеру для доступа к нуж- ной общей папке. Это позволяет приложениям использовать для доступа к файлам по сети обычные API-функции для работы с файлами (типа ReadFile и WriteFНе). В этой главе подробно рассматривается использование перенаправите- ля для передачи запросов ввода-вывода на удаленные устройства (именно на этом основана связь в технологиях почтовых ящиков и именованных кана- лов). Сначала мы обсудим, как ссылаться на файлы в сети с помощью уни- версальных правил именования (Universal Naming Convention, UNC) и указа- теля ресурса поставщика нескольких UNC (Multiple UNC Provider, MUP). За- тем поясним, как MUP вызывает сетевую службу, которая использует пере- направитель для установления связи между компьютерами по протоколу Server Message Block (SMB). В заключение — вопросы обеспечения безопас- ности при доступе к файлам по сети с помощью базовых операций файло- вого ввода-вывода. Г Л А В А 2 Перенаправитель 55 Универсальные правила именования Имена UNC — это стандартный способ доступа к файлам и устройствам без назначения этим объектам буквы локального диска, спроецированного на удаленную файловую систему. Это позволяет приложениям не зависеть от имен дисков и прозрачно работать с сетью. В частности, не надо беспокоить- ся, что не хватит букв для подключаемых общих ресурсов. К тому же структу- ра подключенных дисков своя у каждого пользователя, и процессы, запущен- ные в другом контексте, не смогут обратиться к вашим сетевым дискам. Имена UNC имеют вид \\сервер\ресурс\путь Первая часть — \\сервер, начинается с двух обратных косых черт и име- ни удаленного сервера, на котором находится нужный файл. Вторая — ре- сурс, это имя общего ресурса, то есть папки в файловой системе, к которой открыт общий доступ пользователям сети. Третья часть — \путъ, обознача- ет путь к нужному файлу. Предположим, на сервере с именем Myserver нахо- дится папка D:\Myfiles\CoolMusic, предоставленная для общего доступа под сетевым именем Myshare, а в этой папке — файл Sample.mp3. Тогда для дос- тупа к этому файлу с другой машины надо указать следующее UNC-имя-. \\Myse rve r\Hysha re\Sample.mp3 Как видите, это способ гораздо проще, чем подключение общей папки Myshare в качестве сетевого диска. Обращение к файлам по сети с помощью UNC-имен скрывает от прило- жения детали формирования сетевого соединения, так что система легко находит нужные файлы даже при подключении по модему. Все детали сете- вого соединения организуются перенаправителем компонента доступа. На рис. 2-1 изображены основные компоненты, формирующие UNC-co- единение в NOS в рамках Windows, а также показано, как перемещаются дан- ные между компонентами клиента и сервера NOS. Поставщик нескольких UNC MUP — указатель ресурса, ответственный за выбор компонента доступа для обслуживания соединений по UNC-именам. Компонент сетевого доступа, или сетевой поставщик (network provider) — это служба, способная исполь- зовать сетевые устройства для доступа к ресурсам, расположенным на уда- ленном компьютере, например, к файлам и принтерам. MUP использует ком- понент сетевого доступа для организации связи в ответ на все запросы вво- Да-вывода к файлам и принтерам по UNC-именам. В Windows NT, Windows 2000, Windows 95 и Windows 98 может быть не- сколько компонентов доступа одновременно. Так, в платформы Windows встроен клиент для сетей Microsoft (Client for Microsoft Networks), но мож- но также установить сторонние компоненты доступа, например, клиент для сетей Novell (Novell Client v3.01 for Windows 95/98). Таким образом, обслу- жить UNC-запрос могут несколько компонентов одновременно. С другой 56 ЧАСТЬ I Устаревшие сетевые API стороны, в Windows СЕ имеется только один поставщик — клиент для сетей Microsoft. клиент Приложение ; MUP t j Перенаправитель | Компонент доступа > > Транспортные драйверы > Сетевой адаптер Сервер Локальный ввод-вывод Серверная служба перенаправителя Транспортные драйверы > Сетевой адаптер Рис. 2-1. Компоненты перенаправителя Главная функция MUP — выбор сетевого компонента, который должен обслужить UNC-запрос. MUP делает это, параллельно посылая UNC-имена из запроса всем установленным компонентам доступа. Если какой-либо компо- нент отвечает, что способен обслужить запрос с данными именами, то ему направляется весь запрос. Если это могут сделать несколько компонентов, то MUP выбирает тот, у которого наивысший приоритет. Приоритет компонен- тов определяется порядком, в котором они были установлены в системе. В Windows NT, Windows 2000, Windows 95 и Windows 98 этот приоритет оп- ределяет параметр ProviderOrder в реестре Windows в разделе \HKEY_LO- CAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order. Установленные компоненты перечислены в порядке приоритета. По- скольку в Windows СЕ только один компонент доступа, MUP не использует- ся, и UNC-запросы передаются сразу этому компоненту. Компоненты сетевого доступа Напомним, что компонент сетевого доступа — это служба, использующая се- тевые устройства для доступа к файлам и принтерам на удаленном компью- тере, сердцевина NOS. Компонент доступа может, например, перенаправить идентификатор локального диска (например, Е:) на общую папку на удален- ном компьютере. Компоненты доступа должны также обслуживать запросы Г Л А В А 2 Перенаправитель 57 на соединение по UNC-именам. В Windows они используют для этого пере- направитель. В комплект Windows входит клиент для сетей Microsoft (Client for Mic- rosoft Networks), ранее называвшийся Microsoft Networking Provider (MSNP), который обеспечивает связь между Windows NT 4, Windows 2000, Windows 95, Windows 98 и Windows СЕ. Последняя, однако, не поддерживает установку нескольких клиентов сети одновременно и имеет встроенную поддержку лишь для клиента MSNP. Перенаправитель Этот компонент ОС использует для приема и обработки запросов ввода-вы- вода: перенаправитель формирует запросы и отправляет их серверной служ- бе на удаленном компьютере, которая генерирует локальные запросы вво- да-вывода. Поскольку перенаправитель предоставляет средства ввода-выво- да службам верхнего уровня (типа MUP), он скрывает детали сетевого уров- ня от приложений. Поэтому приложения не должны предавать перенапра- вителю параметры, связанные с протоколами. В итоге компонент сетевого доступа не зависит от протокола: приложения могут работать практически в любой сетевой конфигурации. MNSP содержит перенаправитель, напрямую взаимодействующий с уров- нем сетевого транспорта, и NetBIOS для обеспечения связи между клиентом и сервером. NetBIOS API (см. главу 1), предоставляет интерфейс программи- рования этих транспортов. Перенаправитель MNSP часто называют перенап- равителем диспетчера ЛВС (LAN Manager), поскольку он разрабатывался на основе старого диспетчера ЛВС Microsoft, обеспечивавшего работу в сети приложениям MS-DOS. Интерфейс NetBIOS позволяет установить связь по самым разным протоколам, что делает перенаправитель MNSP протоколо- независимым. Приложениям, которые его используют, не нужно знать дета- ли работы сетевых протоколов: они выполняются поверх TCP/IP, NetBEUI или даже IPX/SPX. Это замечательная возможность позволяет приложениям обмениваться информацией, независимо от физической организации сети. Впрочем, есть один нюанс: чтобы два приложения могли связаться по сети, их рабочие станции должны иметь хотя бы один общий протокол. Так, если на компьютере А установлен только TCP/IP, а на компьютере В — только IPX, перенаправитель MSNP не сможет обеспечить связь между ними. Перенаправитель MSNP связывается с другими рабочими станциями, по- сылая сообщения серверной службе перенаправителя на этих станциях. Эти сообщения задают строго в определенной структуре, называемой Server Message Block (SMB). Протокол, по которому перенаправитель фактически отправляет и получает сообщения с удаленных компьютеров, называется Server Message Block File Sharing Protocol (протокол совместного использо- вания файлов на основе блоков сообщений сервера) или просто SMB. Протокол SMB Этот протокол был разработан Microsoft и Intel в конце 80-х гг. для упроще- ния доступа приложений MS-DOS к удаленным файловым системам. Теперь 58 ЧАСТЬ I Устаревшие сетевые API он просто позволяет перенаправителю MSNP в Windows использовать струк- туру данных SMB при связи со службой сервера MSNP на удаленной рабочей станции. Структура данных SMB содержит три основных компонента: код команды, параметры команды и пользовательские данные. Протокол SMB основан на простой модели запросов клиента и ответов сервера. Клиент перенаправителя MSNP создает структуру SMB с указанием типа запроса в поле кода команды. Если команда требует отправки данных (например, SMB-команда Write), то они прилагаются к запросу. Затем струк- тура SMB отправляется по транспортному протоколу (например, TCP/IP) серверной службе на удаленной рабочей станции. Эта служба обрабатывает запрос клиента и возвращает ему ответную структуру SMB. Теперь рассмотрим пример: открытие файла \\Myserver\Myshare\Sample.mp3 по сети. При этом происходит следующее. 1. Приложение направляет запрос на открытие этого файла локальной ОС с помощью API-функции CreateFile. 2. Локальная ОС определяет по UNC-имени, что этот запрос ввода-вывода адресован удаленной машине с именем \\Myserver, и передает его MUP. 3. MUP определяет, что запрос предназначен компоненту доступа MSNP, по- скольку именно этот компонент обнаруживает \\Myserver путем разреше- ния NetBIOS-имени. 4. Запрос ввода-вывода передается перенаправителю MSNP. 5. Перенаправитель форматирует запрос на открытие файла Sample.mp3 в удаленной папке \Myshare как сообщение SMB. 6. Форматированное сообщение SMB передается по сетевому транспортно- му протоколу. 7. Сервер с именем \\Myserver получает SMB-запрос по сети и передает его серверной службе своего перенаправителя MSNP. 8. Серверная служба выполняет локальный запрос ввода-вывода на откры- тие файла Sample.mp3 в общей папке \Myshare. 9- Перенаправитель сервера форматирует ответное SMB-сообщение с ин- формацией об успехе или неудаче локального запроса ввода-вывода на открытие файла. 10. Ответ сервера посылается по сетевому транспортному протоколу обрат- но клиенту. 11. Перенаправитель MSNP получает ответ SMB и передает код возврата ло- кальной ОС. 12. Локальная ОС передает код возврата вызвавшему функцию CreateFile при- ложению. Как видите, перенаправителю MSNP требуется всего несколько шагов, чтобы предоставить приложению доступ к удаленным ресурсам. Перенапра- витель также управляет доступом к ресурсам, что является одной из форм сетевой безопасности. |