Модель разрешения имен
Пространство имен относится к некоторой возможности связать (как минимум) протокол и атрибуты адресации сетевой службы с одним или несколькими понятными именами. В настоящее время широко используются многие пространства имен, включая систему доменных имен Интернета (DNS), доменные службы Active Directory, bindery, службы каталогов NetWare (NDS) от Novell и X.500. Эти пространства имен сильно различаются по способу их упорядочения и реализации. Некоторые из их свойств особенно важно понимать с точки зрения разрешения имен Winsock.
Типы пространств имен
Существует три разных типа пространств имен, в которых можно зарегистрировать службу:
- Динамический
- Статические
- Постоянный
Динамические пространства имен позволяют службам регистрироваться в пространстве имен на лету, а клиентам — обнаруживать доступные службы во время выполнения. Динамические пространства имен часто используют широковещательные трансляции, чтобы указать на постоянную доступность сетевой службы. К более старым примерам динамических пространств имен относятся пространство имен SAP, используемое в среде NetWare, и пространство имен NBP, используемое AppleTalk. Пространство имен PNRP, используемое в Windows, является более последним примером динамического пространства имен.
Статические пространства имен требуют, чтобы все службы были зарегистрированы заранее, то есть при создании пространства имен. Примером статического пространства имен являются узлы, протоколы и файлы служб , используемые в большинстве реализаций TCP/IP. В Windows эти файлы обычно находятся в папке C:\windows\system32\drivers\etc .
Постоянные пространства имен позволяют службам регистрироваться в пространстве имен на лету. Однако в отличие от динамических пространств имен, постоянные пространства имен сохраняют сведения о регистрации в неизменяемом хранилище, где они остаются до тех пор, пока служба не запросит их удалить. Постоянные пространства имен типизовываются службами каталогов, такими как X.500 и NDS (NetWare Directory Service). Эти среды позволяют добавлять, удалять и изменять свойства службы. Кроме того, объект службы, представляющий службу в службе каталогов, может иметь различные атрибуты, связанные со службой. Наиболее важным атрибутом для клиентских приложений является адресная информация службы. DNS — еще один пример постоянного пространства имен. Хотя существует программный способ разрешения DNS-имен с помощью сокетов Windows, поставщик пространства имен DNS в Windows не поддерживает регистрацию новых DNS-имен с помощью Winsock. Для регистрации DNS-имен необходимо напрямую использовать функции DNS. Дополнительные сведения см. в справочнике по DNS.
Организация пространства имен
Многие пространства имен упорядочены иерархически. Некоторые, например X.500 и NDS, допускают неограниченное вложение. Другие позволяют объединять службы в один уровень иерархии или группы. Обычно это называется рабочей группой. При создании запроса часто требуется установить точку контекста в иерархии пространства имен, с которой начинается поиск.
Архитектура поставщика пространства имен
Естественно, программные интерфейсы, используемые для запроса различных типов пространств имен и для регистрации информации в пространстве имен (если они поддерживаются), сильно различаются. Поставщик пространства имен — это локально резидентное программное обеспечение, которое знает, как сопоставлять пространство имен Winsock SPI и некоторое существующее пространство имен (которое может быть реализовано локально или доступно по сети). Архитектура поставщика пространства имен показана ниже.
Обратите внимание, что для данного пространства имен, например DNS, на данном компьютере может быть установлено несколько поставщиков пространств имен.
Как упоминалось выше, универсальный термин "служба " относится к серверной половине клиентского или серверного приложения. В Winsock служба связана с классом службы, и каждый экземпляр конкретной службы имеет имя службы , которое должно быть уникальным в пределах класса службы. Примеры классов служб включают FTP Server, SQL Server, XYZ Corp. Employee Info Server и т. д. Как показывает пример, некоторые классы служб хорошо известны, а другие являются уникальными и характерными для конкретного вертикального приложения. В любом случае каждый класс службы представлен как именем класса, так и идентификатором класса. Имя класса необязательно должно быть уникальным, но идентификатор класса должен иметь значение . Глобальные уникальные идентификаторы (GUID) используются для представления идентификаторов класса службы. Для хорошо известных служб имена классов и идентификаторы классов (GUID) были предварительно определены, а макросы доступны для преобразования, например, номеров TCP-портов (в порядке байтов узла) и соответствующих идентификаторов идентификаторов класса. Для других служб разработчик выбирает имя класса и использует служебную программу Uuidgen.exe для создания GUID для идентификатора класса.
Понятие класса службы позволяет установить набор атрибутов, общих для всех экземпляров конкретной службы. Этот набор атрибутов предоставляется во время определения класса службы в Winsock и называется сведениями о схеме класса службы. Когда служба устанавливается и становится доступной на хост-компьютере, эта служба считается экземпляром, а ее имя службы используется для отличия конкретного экземпляра службы от других экземпляров, которые могут быть известны пространству имен.
Обратите внимание, что установка класса службы должна выполняться только на компьютерах, где выполняется служба, а не на всех клиентах, которые могут использовать службу. По возможности Ws2_32.dll предоставляет сведения о схеме класса службы поставщику пространства имен во время регистрации экземпляра службы или запуска запроса службы. Конечно, Ws2_32.dll не хранит эти сведения, но пытается получить их от поставщика пространства имен, который указал на возможность предоставления этих данных. Так как нет никакой гарантии, что Ws2_32.dll может предоставить схему класса службы, поставщики пространств имен, которым требуются эти сведения, должны иметь резервный механизм для ее получения с помощью средств, зависящих от пространства имен.
Как отмечалось выше, в Интернете используется то, что можно назвать моделью службы, ориентированной на узел. Приложения, которые должны найти адрес транспорта службы, обычно должны сначала разрешить адрес определенного узла, известного для размещения службы. К этому адресу они добавляют известный номер порта и таким образом создают полный транспортный адрес. Для упрощения разрешения имен узлов предварительно назначен специальный идентификатор класса службы (SVCID_HOSTNAME). Запрос, указывающий SVCID_HOSTNAME в качестве класса службы и имя узла для имени экземпляра службы, вернет сведения об адресе узла в случае успешного выполнения запроса.
В Windows Sockets 2 приложения, независимые от протокола, не должны понимать внутренние детали транспортного адреса. Таким образом, необходимо сначала получить адрес узла, а затем добавить порт является проблематичным. Чтобы избежать этого, запросы также могут включать известное имя конкретной службы и протокол, по которому работает служба, например FTP через TCP. В этом случае успешный запрос возвращает полный адрес транспорта для указанной службы на указанном узле, и приложению не требуется проверять внутренние компоненты структуры sockaddr .
Система доменных имен Интернета не имеет четко определенных средств для хранения сведений о схеме класса службы. В результате поставщики пространств имен DNS для Winsock могут вмещать только известные службы TCP/IP, для которых был предварительно назначен GUID класса службы.
На практике это не является серьезным ограничением, так как идентификаторы GUID класса служб были предварительно определены для всего набора портов TCP и UDP, а макросы доступны для получения GUID, связанного с любым портом TCP или UDP, с портом, выраженным в порядке байтов узла. Таким образом, все знакомые службы, такие как HTTP, FTP, Telnet, Whois и т. д. хорошо поддерживаются.
Продолжая работу с нашим примером класса служб, имена экземпляров службы FTP могут быть "alder.intel.com" или "ftp.microsoft.com", а экземпляр XYZ Corp. Employee Info Server может называться "XYZ Corp. Employee Info Server версии 3.5".
В первых двух случаях сочетание GUID класса службы для FTP и имени компьютера (указанного в качестве имени экземпляра службы) однозначно определяет нужную службу. В третьем случае имя узла, на котором находится служба, можно обнаружить во время запроса службы, поэтому имя экземпляра службы не должно включать имя узла.
Связанные темы