Программирование в сетях Windows. Э. Джонс, Д. Оланд
 Скачать 2.88 Mb.
|
|
ГЛАВА 14 Интерфейс Winsock 2 SPI 459 Функция NSPSetService Функция NSPSetService соответствует WSASetService и также регистрирует или удаляет службы в пространстве имен: int NSPSetService ( LPGUID lpProviderld, LPWSASERVICECLASSINFOW lpServiceClassInfo, LPWSAQUERYSETW lpqsReglnfo, WSAESETSERVICEOP essOperation, DWORD dwControlFlags ); Первый параметр — GUID поставщика. Параметр lpServiceClassInfo — структура WSASERVICECLASSINFOW, к которой относится эта служба. Пара- метр lpqsReglnfo — служба, регистрируемая или удаляемая в зависимости от операции, указанной в четвертом параметре — essOperation. В последнем параметре — dwControlFlags, может быть определен флаг SERVICE_MULTIPLE, изменяющий указанную операцию. Поставщик пространства имен сначала проверяет, существует ли соответ- ствующий класс служб. Далее, в зависимости от того, какая операция опре- делена, предпринимается соответствующее действие (полное описание до- пустимых значений essOperation и эффекта dwControlFlags см. в разделе «Ре- гистрация служб» главы 10). Функция NSPSetService поставщика соответствен- но обрабатывает эти флаги. Если поставщик службы пытается обновить или удалить службу, которая не может быть найдена, вернется ошибка WSASERVICE_NOT_FOUND. Если поставщик регистрирует службу, а структура WSAQUERYSETW неверна или неполна, поставщик генерирует ошибку WSAEINVAL. Эта функция, как и NSPLookupServiceNext, — одна из наиболее сложных для реализации поставщика пространства имен. Поставщик должен поддер- живать схему сохранения служб, которые могут быть зарегистрированы и позволяют функции NSPSetService обновлять данные. Функция NSPLookupServiceBegin Функция NSPLookupServiceBegin связана с функциями NSPLookupServiceNext и NSPLookupServiceEnd и соответствует WSALookupServiceBegin. Она исполь- зуется для инициализации запроса пространства имен и задает условия по- иска. Прототип функции выглядит так: int NSPLookupServiceBegin ( LPGUID lpProviderld, LPWSAQUERYSE™ lpqsRestrictions, LPWSASERVICECLASSINFOW lpServiceClassInfo, DWORD dwControlFlags, LPHANDLE lphLookup ); Первый параметр — GUID поставщика. Параметр lpqsRestrictions — струк- тура WSAQUERYSETW, которая определяет параметры запроса. Третий пара- 4 6 0 ЧАСТЬ II Интерфейс прикладного программирования Wmsock метр — ipServiceClassInfo, является структурой WSASERVICECLASSINFOW, содер- жащей информацию о схеме запроса для класса служб Параметр dwCont- rolFlags может содержать флаги, влияющие на способ выполнения запроса (информацию по WSALookupServiceBegin и другим флагам см в главе 10) Заметьте не все флаги имеют смысл для каждого поставщика Например, если ваше пространство имен не поддерживает понятие контейнерных объек- тов, вас не должны беспокоить флаги, связанные с контейнерами (контей- нер — это способ концептуальной организации служб, все, что составляет контейнер, открыто для интерпретации) Наконец, iphLookup — выходной параметр, который является описателем, определяющим этот запрос Опи- сатель используется в последующих запросах к WSALookupServiceNext и WSA- LookupServiceEnd При реализации NSPLookupServiceBegin имейте в виду, что эта операция не может быть отменена и должна завершиться так быстро, как возможно Поэтому если вам нужно инициализировать сетевой запрос, для успешного возврата не требуйте ответа Сам поставщик должен сохранить параметры запроса и связать уникаль- ный описатель с запросом, чтобы ссылаться на него позже Кроме того, по- ставщик обязан поддерживать информацию о состоянии Функция NSPLookupServiceNext Когда запрос инициализирован с помощью WSALookupServiceBegin, приложе- ние вызывает WSALookupServiceNext, а она, в свою очередь, функцию NSP- LookupServiceNext поставщика пространства имен Этот вызов ищет резуль- таты, соответствующие условиям поиска для данного запроса Функция оп- ределена так int NSPAPI WSALookupServiceNext ( HANDLE hLookup, Sb DWORD dwControlFlags, LPDWORD lpdwBuffertength, LPWSAQUERYSET lpqsResults " ). Первый параметр — hLookup, является описателем запроса, возвращен- ным функцией WSALookupServiceBegin Параметр dwControlFlags может быть флагом LUP_FLUSHPREV1OUS, указывающим, что поставщик должен отказать- ся от последнего набора результатов и перейти к следующему Обычно при- ложение делает это, когда не может предоставить достаточно большой бу- фер для результатов Следующий параметр — ipdwBufferLength, указывает размер б> фера, переданного в последнем параметре — lpqsResults Когда вызвана функция NSPLookupServiceNext, поставщик должен найти параметры запроса, определенного описателем hLookup Как только эти па- раметры найдены, инициализируется поиск всех зарегистрированных и со- ответствующих предоставленным условиям служб в пределах класса, указан- ного запросом Как мы уже говорили, состояние запроса должно быть сохра- нено Если найдено несколько соответствующих записей, процесс запроса Г Л А В А 14 Интерфейс Wmsock 2 SPI 461 вызывает WSALookupServiceNext многократно, и с каждым вызовом постав- щик должен вернуть набор данных Когда соответствующих записей больше нет, поставщик возвращает ошиб- ку WSA_E_NO_MORE Можно отменить запрос в процессе выполнения, если приложение обращается к WSALookupServiceEnd из другого потока, в то вре- мя как происходит вызов WSALookupServiceNext В этом случае выполнение NSPLookupServiceNext не будет успешным и функция вернет ошибку WSA Е CANCELLED Функция NSPLookupServiceEnd По завершении запроса вызывается функция NSPLookupServiceEnd, чтобы закончить запрос и освободить все базовые ресурсы int NSPLookupServiceEnd ( HANDLE hLookup ), Единственный параметр функции — hLookup, является описателем закры- ваемого запроса Если данный описатель не может быть найден (например, он недействителен), возвращается ошибка WSAJNVALID_HANDLE Пример Мы шаг за шагом рассмотрели процесс создания собственного пространства имен и коснулись некоторых связанных с этим проблем, например, методов постоянного сохранения данных Однако, разработка поставщика простран- ства имен может быть сложной, поэтому проиллюстрируем свой рассказ примером Приведенный в примере поставщик не самый быстрый, и его код далеко не оптимален Тем не менее, он иллюстрирует моменты, требующие пристального внимания и понять его довольно просто Пример расположен на прилагаемом к книге компакт-диске в каталоге Examples\Chapterl4\NSP в файлах Mynsph, Mynspcpp и Mynspdef Эти три файла составляют DLL пространства имени Кроме того, вы найдете на ком- пакт-диске службу пространства имен — сервер Winsock, ответственный за обработку запросов от DLL Этот сервер, обслуживающий регистрационные данные службы, находится в файле Mynspsvc cpp Два дополнительных фай- ла — Nspsvc cpp и Pnntob) cpp, используются и DLL, и службой, и содержат процедуры поддержки маршалинга и демаршалинга данных, пересылаемых через сокет между службой и DLL Там же вы найдете их заголовочные фай- лы — Nspsvc h и Pnntob] h, содержащие прототипы функций для процедур поддержки Наконец, файл Rnrcs с — измененный пример из главы 10, реги- стрирует и ищет службы в нашем пространстве имен В следующих разделах мы обсудим реализацию пространства имен Сна- чала рассмотрим метод, выбранный для постоянного сохранения данных Этот обзор будет сопровождаться изучением структуры DLL пространства имен, а также установки пространства имен Далее рассмотрим реализацию службы пространства имен Наконец, мы покажем, как приложение выпол- няет регистрацию и запросы к пользовательскому пространству имен 4 6 2 ЧАСТЬ II Интерфейс прикладного программирования Winsock Сохранение данных Для нашего пространства имен мы выбрали отдельную службу Winsock, об- служивающую информацию пространства имен. В каждой реализованной в DLL функции пространства имен осуществляется соединение с этой служ- бой и передаются данные для завершения операции. Для простоты, эта служ- ба выполняется локально (слушает на адресе обратной петли 127.0.0.1). В фактической реализации IP-адрес службы пространства имен будет досту- пен через системный реестр или некоторые другие средства. Так что если приложение вызовет пространство имен, оно сможет соединиться со служ- бой везде, где бы ни выполнялось. Например, в случае DNS, IP-адрес DNS-cep- вера будет назначен статически либо получен в ходе запроса DHCP. Конечно, написать службу не единственный выход: вы можете обслужи- вать файл, который сохраняет необходимую информацию, в сети. Но мы не советуем выбирать последний вариант, поскольку тогда производительность пространства имен будет ограничена дисковыми операциями. В нашем при- мере производительность ограничивает и то, что пространство имен уста- навливает соединение со службой через TCP. Промышленная реализация, вероятно, будет использовать дейтаграммный протокол без установления соединения, такой как UDP. Конечно, это повлечет дополнительные про- граммные требования (в частности, чтобы отброшенные пакеты передава- лись повторно), но производительность будет увеличена значительно. DLL пространства имен Прежде чем говорить о том, как реализована служба пространства имен, да- вайте рассмотрим его DLL. Каждый поставщик пространства имен требует уникальный GUID; эти GUID определены в файле Mynsp.h. Кроме уникаль- ного идентификатора, нам нужен простой целочисленный идентификатор, который может использоваться в поле dwNameSpace структуры WSAQUE- RYSET. GUID и идентификатор пространства имен выглядят так: GUID MY_NAMESPACE_GUIO = {Ox55a2bd9e,ОхЬЬЗО,0x11d2, {0x91,0x66,0x00,ОхаО,0хс9,0ха7,0x86, 0хе8} }; «define NS_MYNSP66 Эти значения важны, так как приложения, которые хотят использовать данное пространство имен, должны указывать их в своих запросах Winsock. Конечно, разработчик приложения может определить эти значения явно или извлечь их, вызвав WSAEnumNameSpaceProviders (см. главу 10). Если приложение выполняет операцию, указывая поставщика имен NS_ALL, операция происходит на всех имеющихся поставщиках имен. Некоторые приложения Windows, например, Microsoft Internet Explorer, выполняют зап- росы на всех поставщиках имен. Поэтому будьте предельно осторожны, те- стируя поставщик имен: если он плохо написан, то может вызвать общеси- стемные проблемы. Кроме того, значения GUID и идентификатора про- странства имен важны, так как требуются для установки поставщика имен. Теперь давайте посмотрим на NSP-функции, реализованные в Mynsp.cpp. Почти все они очень похожи, кроме функций запуска и очистки — NSPStartup Г Л А В А 14 Интерфейс Winsock 2 SPI 463 и NSPCleanup. Функция запуска просто инициализирует структуру NSP_ROU- TINE пользовательскими функциями пространства имен. Процедура очист- ки не делает ничего, потому что никакая очистка не требуется. Остальные функции требуют взаимодействия с нашей службой, чтобы сделать запрос или зарегистрировать данные. Чтобы установить связь со службой, выполните следующие шаги. 1. Соединитесь со службой (через функцию MyNspConnect). 2. Запишите однобайтный код действия. Он укажет службе, какое действие будет произведено (регистрация, удаление, запрос и т. п.). 3- Маршализируйте параметры и отправьте их службе. Тип параметров за- висит от операции. Например, NSPLookupServiceNext отправляет описа- тель запроса службе, чтобы та могла возобновить запрос, a NSPSetService — всю структуру WSAQUERYSET. 4. Прочитайте код возврата. Когда служба обладает необходимыми для вы- полнения требуемой операции параметрами, возвращается код возврата операции (успех или неудача). Файл Mynsp.h определяет для этой цели две константы — MYNSP_SUCCESS и MYNSP_ERROR. 5. Если требуемая операция была запросом, а код возврата свидетельствует об успешном выполнении, прочтите и демаршализируйте результаты. Например, NSPLookupServiceNext возвращает структуру WSAQUERYSET, ког- да найдена соответствующая служба. Как видите, реализация DLL не слишком сложна. NSP-функции должны принимать параметры и обрабатывать их, что в нашем случае означает — передать эту информацию службе пространства имен. После этого'выпол- нение запрошенной операции — дело службы. Однако мы пропустили одну трудную операцию, которая должна быть выполнена: отправка данных че- рез сокет. Обычно для нее нет никаких особых требований, но при отправ- ке целых структур данных они есть. Большинство функций пространства имен принимают структуру WSA- QUERYSET или WSASERV1CECLASSINFO в качестве параметра. Объект должен быть отправлен или получен через сокетное соединение со службой. Это представляет некоторую трудность, так как данные структуры не являются непрерывные блоками памяти. Они содержат указатели на строки и другие структуры, которые могут быть расположены где-нибудь в памяти (рис. 14-4). Вы должны взять все эти части памяти — везде, где они есть — и скопиро- вать в один буфер, одну за другой. Данный метод известен как маршалинг данных (marshaling data). На приемнике процесс должен быть повторен в об- ратном порядке: данные, которые нужно прочитать, будут вновь собраны в первоначальную структуру, а указатели — заданы так, чтобы ссылались на действительное расположение памяти на компьютере получателя. Функции маршалинга и демаршалинга структур WSANAMESPACEINFO и WSAQUERYSET нашего поставщика пространства имен расположены в фай- ле Nspsvc.cpp и используются как DLL пространства имен, так и службой пространства имен (так как обе стороны нуждаются в маршалинге и демар- шалинге этих структур). Все четыре функции не требуют пояснений. 464 ЧАСТЬ II Интерфейс прикладного Программирования Winsock WSASERVICECLASSINFO DW0R0 800L DWORD i I f 0 о Ь а г \0 Г" iSTR 1 Marshaled ШЛО OWORD ВООЦ Рис. 14-4. Маршалинг данных Установка и удаление поставщика пространства имен Это самый простой шаг во всем процессе Файл Nspinstall.c — простая про- грамма установки. Следующий код устанавливает наш поставщик: ret = WSCInstallNameSpace(L"Custom Name Space Provider", rXSystemRootX\\System32\\Mynsp.dll", NS_MYNSP, 1, &MY_NAMESPACE_GUID); if (ret == SOCKET_ERROR) { pnntfC'Failed to install name space provider: Xd\n", *WSAGetLastError()); > Параметры вызова имя поставщика, расположение DLL, целочисленный идентификатор, версия и GUID После установки нужно только удостове- риться, что DLL пространства имен на самом деле расположена там, где вы указали Единственная возможная ошибка — попытка установить поставщик имен с GUID, который уже используется другим поставщиком. Удалить поставщик пространства имен еще проще ret = WSCUnInstallNameSpace(m_NAMESPACE_GUID); if (ret == SOCKET_ERROR) { prmtf("Failed to remove provider: Xd\n", WSAGetLastErrorO); Служба пространства имен Служба пространства имен — реальное содержание поставщика имен Эта служба следит за всеми зарегистрированными классами и экземплярами служб Когда DLL пространства имен вызвана приложением пользователя, она соединяется со службой пространства имен для выполнения операции Служба проста В функции тат назначается прослушивающий сокет. Далее ГЛАВА 14 Интерфейс Winsock 2 SPI 465 в цикле принимаются соединения от экземпляров DLL пространства имен Для простоты, в каждый момент обрабатывается только одно соединение. Это также избавляет от необходимости синхронизировать доступ к струк- турам данных, которые обслуживают информацию пространства имен. (Опять же, настоящий поставщик работал бы иначе, чтобы не снижать про- изводительность.) Как только соединение принято, служба читает один байт из DLL пространства имен, идентифицирующий следующее действие. В цикле действие декодируется, параметры передаются службе от DLL пространства имен. Затем выполняются требуемые действия. Они не слож- ны и исследуя их пошагово, вы сможете увидеть, как работает служба. Здесь мы не будем вдаваться в детали, исследуем лишь структуры, обслуживающие информацию. Есть только два типа данных, к которым имеют отношение поставщики пространства имен: структуры WSASERVICECLASSINFO и WSAQUERYSET. Как вы видели, большинство RNR-функций ссылаются в своих параметрах на одну из этих структур. В результате, мы обслуживаем два глобальных массива — по одному для каждого типа структуры, а также счетчик для каждого из них Когда DLL запрашивает установку класса служб, функция main поставщи- ка службы имен сначала вызывает LookupServiceClass — процедуру поддерж- ки, определенную в Mynspsvc cpp. Эта функция просматривает массив Ser- viceClasses из структур WSASERVICECLASSINFO Если найден класс служб с тем же самым GUID, служба возвращает ошибку (которую DLL транслирует, как WSAEALREADY). Иначе в конец массива добавляется новый класс служб, а счет- чик dwNumServiceClasses увеличивается на 1. При удалении класса служб (как и при установке) функция main вызыва- ет LookupServiceClass. Если класс служб найден, код перемещает его на мес- то удаленного класса и уменьшает счетчик на 1. В спецификации Winsock 2 для поставщиков пространства имен не указано, что происходит, когда класс служб должен быть удален, но есть ссылающиеся на него зарегистрирован- ные службы. Как вы будете обрабатывать этот случай — ваше дело. Наше про- странство имен в такой ситуации не допустит удаления класса службы. Принцип, используемый для поддержания структур WSASERVICECLASSINFO, применяется и для отслеживания структур WSAQUERYSET Существует массив этих структур с именем Services и счетчик с именем dwNumServices. Добавление и удаление служб выполняется так же, как и добавление и удаление классов Служба должна отвечать на запросы. Когда приложение инициализиру- ет запрос, параметры запроса должны поддерживаться в течение его срока жизни и для них следует назначить уникальный описатель Это необходи- мо, так как WSALookupServiceNext обращается к запросу только по описате- лю. Другая часть информации, которая должна сохраняться, — состояние запроса. Каждый запрос к WSALookupServiceNext возвращает уникальный набор информации Код должен помнить последнюю позицию в массиве Services, для которой были возвращены данные, чтобы последующие запросы к WSALoo- kupServiceNext начинали с того места, где остановился предыдущий. 4 6 6 ЧАСТЬ II Интерфейс прикладного программирования Winsock Запрос пространства имен Последняя часть нашего пространства имен — файл Rnrcs.c. Это измененная версия примера регистрации и разрешения имен из главы 10. Мы внесли только несколько изменений, чтобы предельно упростить пример. Первое изменение заставляет код перечислять установленные поставщики про- странства имен, но возвращать только поставщик NSJMYNSP. Во-вторых, при регистрации службы Rnrcs.c перечисляет только локальные интерфейсы IP для использования в качестве адреса службы. Наш поставщик службы под- держивает регистрацию любого типа SOCKADDR. Наконец, для регистра- ции службы этот пример не создает экземпляр службы, а только регистри- рует имя. Выполнение примера После компиляции всех примеров установка и использование поставщика просты. Следующая команда устанавливает поставщик: Nspinstall.exe install Конечно, не забудьте скопировать Mynsp.dll в %SystemRoot%\System32. Когда пространство имен установлено, должен быть запущен экземпляр службы, чтобы делать запросы и регистрировать службы. Это делается ко- мандой Mynspsvc.exe. Теперь вы можете делать запросы и регистрировать службы, используя Rnrcs.exe. Перечислим некоторые команды, которые вы должны выполнить: • Rnrcs.exe -s:ASERVICE — регистрация службы ASERVICE; И Rnrcs.exe -s:BSERVICE — регистрация службы BSERVICE; • Rnrcs.exe -с:* — запрос всех зарегистрированных служб; • Rnrcs.exe -c:BSERVICE — запрос только служб с именем BSERVICE; • Rnrcs.exe -c:ASERVICE -d — запрос и удаление только служб с именем ASERVICE; • Rnrcs.exe -c:BSERVICE -d — запрос и удаление только служб с именем BSERVICE; • Rnrcs.exe -с:* — запрос всех зарегистрированных служб. Эта последовательность команд регистрирует две службы и выполняет па- раметризованный и конкретный запрос. Затем последовательность команды делает запрос для каждых из этих двух служб и удаляет их. Наконец, мы вы- полняем параметризованный запрос, чтобы показать, что службы удалены. Отладочные функции отслеживания Winsock 2 SPI Winsock 2 может отслеживать запросы API и SPI, вызванные из Ws2_32.dll. Это чрезвычайно полезно при разработке поставщика служб пространства имен или транспорта. В MSDN SDK два примера — Dt_dll и Dt_dll2, созданы для отслеживания вызовов SPI, когда они обрабатываются системой. Пре- Г Л А В А 14 Интерфейс Winsock 2 SPI 467 лесть этих примеров в том, что вы можете изменить их, чтобы отслеживать любые вызовы API и SPI, которые вас интересуют. Чтобы использовать эту особенность отладки, получите сначала прове- ренную сборку Winsock 2 Ws2_32.dll для целевой платформы. Она содержит- ся в MSDN SDK в папке Mssdk\Bin\Debug\Winsock. Вы можете скопировать эту сборку поверх системной библиотеки Ws2_32.dll в %SystemRoot%\Sys- tem32 или поместить ее в рабочий каталог своего приложения Winsock. Пос- леднее лучше всего, так как вам не придется менять систему в целях отлад- ки. После того как проверенная сборка установлена, скомпилируйте и собе- рите один из примеров MSDN Dt_dll. Теперь вы получили DLL поддержки с именем Dt_dll.dll. Скопируйте Dt_dll.dll в рабочий каталог своего приложе- ния Winsock и можете отслеживать функции Winsock 2 API и SPI, которые косвенно вызываются из вашего приложения. Резюме Winsock 2 SPI предлагает разработчикам метод расширения возможностей Winsock 2 с помощью разработки поставщика службы. В этой главе мы из- ложили подробности разработки поставщика транспорта и поставщика про- странства имен. Данная глава завершает обсуждение сетевой технологии Winsock. В сле- дующей главе рассматривается элемент управления Microsoft Visual Basic Winsock, который использует Winsock. Мы не будем вводить никакие новые концепции, а просто дадим рекомендации по работе с этим элементом. Если вас не интересует Visual Basic, вы можете перейти к третьему, заключитель- ному разделу книги, в котором рассматривается служба RAS — технология, которая позволяет повысить гибкость приложений Winsock. Г Л А В А 1 5 Элемент управления Winsock Поставляемый с Microsoft Visual Basic элемент управления Winsock — отно- сительно новый элемент управления, он превращает Winsock в удобный ес- тественный интерфейс, доступный из Visual Basic До его появления для се- тевого программирования на Visual Basic с использованием Winsock прихо- дилось импортировать все функции Winsock из DLL-библиотеки и переоп- ределять множество необходимых структур Этот процесс был длительным и чреват ошибками, например, из-за несоответствия объявлений типов Тем не менее, если вам требуется дополнительная гибкость, обеспечиваемая не- посредственным импортом Winsock в Visual Basic, изучите примеры про- грамм на Visual Basic из второй части книги Каждый пример включает файл Winsock bas, импортирующий необходимые константы и ограничения В этой главе рассматривается только элемент управления Winsock из Visual Basic Сначала мы обсудим свойства и методы Winsock, а затем приве- дем несколько примеров, в которых используется этот элемент управления Впервые Winsock появился в Visual Basic 5 0 Во второй и третий пакеты обновлений Visual Studio включена усовершенствованная версия данного элемента управления С Visual Basic б О поставляется новейшая версия Win- sock Мы обсудим различия этих версий Элемент управления Winsock реализует лишь базовый интерфейс досту- па к API-функциям Winsock В отличие от интерфейса Winsock, независимо- го от протокола, элемент управления может использовать лишь IP Кроме того, он основан на спецификации Winsock 1 1 и ограниченно поддерживает протоколы TCP и UDP Сам по себе Winsock не может обратиться к каким-либо параметрам со- кетов, что означает недоступность таких функций как многоадресная и ши- роковещательная рассылка Обычно элемент управления Winsock полезен, когда необходимы лишь базовые функции работы с сетью — он не обеспе- чивает оптимальную производительность, поскольку кэширует данные пе- ред их передачей системе и тем самым создает дополнительную нагрузку и неопределенность Свойства В табл 15-1 перечислены свойства элемента управления Winsock, которые позволяют управлять поведением и получать информацию о его состоянии |