Модель разрешения имен

Пространство имен ссылается на некоторые возможности связывания (как минимум) протокола и адресации атрибутов сетевой службы с одним или несколькими понятными именами. Многие пространства имен в настоящее время широко используются, в том числе системы доменных имен Интернета (DNS), доменных служб Active Directory, привязок, служб каталогов NetWare (NDS) из Novell и X.500. Эти пространства имен сильно различаются в том, как они упорядочены и реализованы. Некоторые из их свойств особенно важны для понимания с точки зрения разрешения имен Winsock.

Типы пространств имен

Существует три различных типа пространств имен, в которых можно зарегистрировать службу:

• Динамический
• Статический
• Упорный

Динамические пространства имен позволяют службам регистрироваться в пространстве имен во время выполнения и обнаруживать доступные службы во время выполнения. Динамические пространства имен часто используют широковещательные трансляции, чтобы указать постоянную доступность сетевой службы. Более старые примеры динамических пространств имен включают пространство имен SAP, используемое в среде NetWare, а также пространство имен Протокола привязки имен (NBP), используемое AppleTalk. Пространство имен однорангового разрешения имен (PNRP), используемое в Windows, является более последним примером динамического пространства имен.

Статические пространства имен требуют, чтобы все службы регистрировались заранее, то есть при создании пространства имен. Примером статического пространства имен являются узлы , протоколи службы, используемые большинством реализаций TCP/IP. В Windows эти файлы обычно находятся в папке C:\windows\system32\drivers\etc.

Постоянные пространства имен позволяют службам регистрироваться в пространстве имен на лету. В отличие от динамических пространств имен, постоянные пространства имен сохраняют сведения о регистрации в неразрешемом хранилище, где оно остается до тех пор, пока не будет удалена служба. Постоянные пространства имен типифицируются службами каталогов, такими как X.500 и NDS (служба каталогов NetWare). Эти среды позволяют добавлять, удалять и изменять свойства службы. Кроме того, объект службы, представляющий службу в службе каталогов, может иметь различные атрибуты, связанные со службой. Наиболее важным атрибутом для клиентских приложений является адресация службы. DNS является еще одним примером постоянного пространства имен. Хотя существует программный способ разрешения DNS-имен с помощью сокетов Windows, поставщик пространства имен DNS в Windows не поддерживает регистрацию новых DNS-имен с помощью Winsock. Для регистрации DNS-имен необходимо использовать функции DNS напрямую. Дополнительные сведения см. в справочнике по DNS.

Организация пространства имен

Многие пространства имен упорядочивается иерархически. Некоторые, такие как X.500 и NDS, допускают неограниченное вложение. Другие позволяют службам объединяться в один уровень иерархии или группы. Обычно это называется рабочей группой. При создании запроса часто необходимо установить точку контекста в иерархии пространства имен, с которой начнется поиск.

Архитектура поставщика пространства имен

Естественно, программные интерфейсы, используемые для запроса различных типов пространств имен и регистрации сведений в пространстве имен (если поддерживаются), отличаются широко. Поставщик пространства имен — это локальный фрагмент программного обеспечения, который знает, как сопоставляться между пространством имен Winsock и некоторыми существующими пространствами имен (которые могут быть реализованы локально или доступны через сеть). Архитектура поставщика пространств имен иллюстрируется следующим образом:

архитектура поставщика пространств имен

Обратите внимание, что для данного пространства имен, например DNS, может быть установлено несколько поставщиков пространств имен на определенном компьютере.

Как упоминалось выше, универсальный термин службы относится к половине сервера клиентского или серверного приложения. В Winsock служба связана с классом службы, а каждый экземпляр конкретной службы имеет имя службы, которое должно быть уникальным в классе службы. Примеры классов служб включают FTP Server, SQL Server, XYZ Corp. Info Server и т. д. Как иллюстрирует пример, некоторые классы служб хорошо известны, а другие являются уникальными и характерными для конкретного вертикального приложения. В любом случае каждый класс службы представлен как именем класса, так и идентификатором класса. Имя класса не обязательно должно быть уникальным, но идентификатор класса должен быть уникальным. Глобальные уникальные идентификаторы (GUID) используются для представления идентификаторов классов службы. Для хорошо известных служб имена классов и идентификаторы классов (GUID) были предварительно размещены, а макросы доступны для преобразования между номерами TCP-портов (в порядке байтов узла) и соответствующими идентификаторами GUID идентификаторов классов. Для других служб разработчик выбирает имя класса и использует служебную программу Uuidgen.exe для создания GUID для идентификатора класса.

Понятие класса службы существует, чтобы разрешить установить набор атрибутов, хранящиеся во всех экземплярах определенной службы. Этот набор атрибутов предоставляется во время определения класса службы Winsock и называется сведениями о схеме класса службы. Когда служба установлена и доступна на хост-компьютере, эта служба считается экземплярами, а ее имя службы используется для различения конкретного экземпляра службы от других экземпляров, которые могут быть известны пространству имен.

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

Как отмечалось выше, Интернет принял то, что можно назвать моделью службы, ориентированной на узел. Приложения, которые должны находить адрес транспорта службы, обычно должны сначала разрешать адрес определенного узла, известного для размещения службы. К этому адресу они добавляются в известный номер порта и таким образом создают полный адрес транспорта. Для упрощения разрешения имен узлов специальный идентификатор класса службы был предварительно развернут (SVCID_HOSTNAME). Запрос, указывающий SVCID_HOSTNAME в качестве класса службы и указывающий имя узла для имени экземпляра службы, вернет сведения об адресе узла, если запрос выполнен успешно.

В сокетах Windows 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. Может быть назван "XYZ Corp. Info Server версии 3.5".

В первых двух случаях сочетание GUID класса службы для FTP и имени компьютера (предоставленное в качестве имени экземпляра службы) однозначно идентифицирует нужную службу. В третьем случае имя узла, в котором находится служба, можно обнаружить во время запроса службы, поэтому имя экземпляра службы не должно включать имя узла.

Связанные разделы

Справочник по DNS

структуры данных разрешения имен

разрешения именProtocol-Independent

регистрации и разрешения имен

SOCKADDR

Сводка функций разрешения имен