Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

4.1.

Именованные сущности 231

Рекурсивное разрешение имен позволяет каждому серверу имен последова-

тельно получать адрес каждого из серверов, ответственных за узлы нижнего

уровня. В результате можно с успехом применить кэширование для повышения

производительности. Так, если корневой сервер требует разрешить путь root:<nl,

vu, cs, ftp>, он может в результате получить адрес сервера имен, реализующего

узел, соответствующий этому пути. Чтобы прийти к этому, сервер имен узла п1

должен найти адрес сервера имен узла vu, а последний, в свою очередь, должен

найти адрес сервера имен, отвечающего за узел cs.

Поскольку изменения в узлах глобального и административного уровней

происходят нечасто, корневой сервер имен может успешно кэшировать получен-

ный адрес. Более того, поскольку в результате рекурсии также будут возвраще-

ны адреса серверов имен, отвечающих за реализацию узлов vu и

п1,

они также мо-

гут быть с успехом кэшированы на этих серверах.

Таким образом, результаты промежуточного поиска имен также могут быть

кэшированы и извлечены из кэша. Например, сервер узла

п1

может найти адрес

сервера узла

vu.

Этот адрес может быть возвращен корневому серверу в ходе воз-

вращения сервером

п1

результатов поиска по исходному имени. Полный обзор

процесса разрешения результатов, которые могут быть кэшированы на каждой

из стадий этого процесса, приведен в табл. 4.2.

Таблица 4.2. Рекурсивное разрешение имени

<п1,

vu, cs, ftp>

Сервер

узла

Объект

разрешения

Поиск Передача

дочернему

узлу

Получение

и кэширование

Возвращение

в ответ

на запрос

п1

root

<ftp>

<cs,ftp>

<vu,cs,ftp>

<nl,vu,cs,ftp>

#<ftp>

#<cs>

#<vu>

#<nl>

—

<ftp>

<cs,ftp>

<vu,cs,ftp>

—

#<ftp>

#<cs>

#<cs,ftp>

#<vu>

#<vu,cs>

#<vu,cs,ftp>

#<ftp>

#<cs>

#<cs,

ftp>

#<vu>

#<vu,cs>

#<vu,cs,ftp>

#<nl>

#<nl,vu>

#<nl,vu,cs>

#<nl,vu,cs,ftp>

Достоинство подобного подхода в том, что операции поиска со временем мо-

гут стать потрясающе эффективными. Так, представим себе, что позже разрешить

путь root:<nl, vu, cs, flits> потребует другой клиент. Это имя поступит в корневой

узел, а оттуда немедленно будет передано серверу имен узла cs, к которому и по-

ступит запрос на разрешение остатка пути cs:<flits>.

При итеративном разрешении имен кэширование по необходимости ограни-

чивается процедурой разрешения имен клиента. Соответственно, если клиент

запрашивает разрешение некоторого имени, а затем клиент В требует разрешить

то же самое имя, разрешение имен потребует повторного прохода через те же са-

мые серверы, через которые мы уже проходили для клиента А. В качестве ком-

промиса многие организации задействуют локальные промежуточные серверы

232

Глава 4. Именование

имен, совместно используемые всеми клиентами. Эти локальные серверы имен

обрабатывают все запросы на имена и кэшируют их результаты. Такие промежу-

точные серверы удобны и с точки зрения управления. Например, только этот

сервер должен знать, где находится корневой сервер имен, другие машины в

этой информации не нуждаются.

Второе достоинство рекурсивного разрешения имен состоит в том, что оно

часто экономней с точки зрения взаимодействия. Рассмотрим вновь разрешение

пути root:<nl,

VU,

cs, ftp> в предположении, что клиент находится в Сан-Франци-

ско.

Предполагая, что клиент знает адрес сервера узла

п1,

при рекурсивном разре-

шении имен образуется связь между хостом клиента в Сан-Франциско и серве-

ром в Нидерландах, помеченная на рис. 4.9 как R1. После этого вам потребуется

связь между сервером

п1

и сервером имен университета Vrije в университетском

городке в Амстердаме, Нидерланды. Эта связь обозначена как R2. И наконец, не-

обходима связь между сервером vu и сервером имен факультета компьютерных

дисциплин (Computer Science Department), обозначенная как ЯЗ. Ответ пройдет

по тому же пути, но в обратном направлении. Понятно, что затраты на взаимо-

действие будут определяться обменом сообщениями между хостом клиента и

сервером п1.

Рекурсивное

разрешение имен RI

Сервер имен

узла п1

Сервер имен

узла VU

IR2

IR1

разрешение имен

Сервер имен

узла CS

Дальняя связь

Рис. 4.9. Сравнение между рекурсивным и итеративным разрешением имен

с точки зрения затрат на взаимодействие

В противоположность этому, при итеративном разрешении имен хост клиен-

та связывается по отдельности с серверами

п1,

vu и cs, в результате чего общие

затраты будут почти в три раза выше, чем при рекурсивном разрешении. Стрел-

ки на рисунке с метками

11,12

обозначают взаимодействие при итеративном

разрешении имен.

4.1.4. Пример

—

система доменных имен

Одной из самых больших на сегодня распределенных служб именования является

система доменных имен (Domain Name System, DNS) Интернета. DNS использу-

ется в первую очередь для поиска адресов хостов и почтовых серверов. На сле-

дующих страницах мы сосредоточимся на организации пространства имен сис-

темы DNS и информации, хранящейся на ее узлах. Кроме того, мы поближе

4.1.

Именованные сущности 233

ознакомимся с существующей реализацией DNS. Дополнительную информацию

по этой теме можно найти в [8, 301].

Пространство имен DNS

Пространство имен DNS иерархически организовано в виде дерева с корнем.

Метка представляет собой не зависящую от регистра строку алфавитно-циф-

ровых символов. Максимальная длина метки

—

63 символа, полная длина пути

ограничена 255 символами. Строковое представление пути состоит из списка ме-

ток, начиная справа, разделенных точками. Корень также представлен точкой.

Так, например, путь root:<nl,

vu,

cs, flits> представляется строкой flits.cs.vu.nl., вклю-

чая точку справа, которая означает корень. Обычно для удобства чтения мы бу-

дем опускать эту точку.

Поскольку каждый из узлов в пространстве имен DNS имеет ровно одно вхо-

дящее ребро (за исключением корня, который входящих ребер не имеет), метка

входящего в узел ребра используется также и в качестве имени этого узла. Под-

дерево называется

доменом

(domain), а путь к корневому узлу домена

—

домен-

ным

именем

(domain пате). Отметим, что, как и путь, доменное имя может быть

абсолютным или относительным.

Содержимое узла комплектуется из набора записей о ресурсах

(resource

re-

cords).

Существуют различные типы записей о ресурсах, наиболее важные из них

перечислены в табл. 4.3.

Таблица 4.3. Наиболее важные типы записей о ресурсах

Тип записи Сущность записи Описание

Информация о соответствующей зоне

IP-адрес хоста, на котором установлен узел

Почтовый сервер, обрабатывающий почтовые

адреса узла

Сервер, предоставляющий некоторую службу

Сервер имен, отвечающий за определенную зону

Символическая ссылка на первичное имя

соответствующего узла

Каноническое имя хоста

Информация о хосте, на котором установлен узел

Дополнительная информация, зависящая

от сущности

Узел в пространстве имен DNS часто представляет одновременно несколько

сущностей. Так, например, доменное имя vu.nl используется для представления

домена и зоны. В данном случае домен реализован в нескольких зонах.

Запись о ресурсе

SOA

(start of authority

—

начало полномочий) содержит та-

кую информацию, как, например, почтовый адрес системного администратора,

отвечающего за указанную зону, имя хоста, на котором находятся данные о зоне

и т. д.

SOA

SRV

CNAME

PTR

HINFO

TXT

Зона

Хост

Домен

Зона

Узел

Хост

Любая сущность

234 Глава 4. Именование

Запись

(address

—

адрес) представляет отдельный хост в Интернете. Эта за-

пись содержит IP-адрес хоста, используемый при взаимодействии. Если хост име-

ет несколько IP-адресов, например, в случае машин с множественной адресацией,

узел будет содержать запись

для каждого адреса.

Важный тип записи о ресурсах ~

(mail exchange

—

почтовый обмен). Эта

запись является символической ссылкой на узел, представляющий почтовый сер-

вер.

Например, пусть узел, представляющий домен cs.vu.nl, имеет запись

MX,

со-

держащую имя zephyr.cs.vu.nl, которое относится к почтовому серверу. Этот сер-

вер будет обрабатывать все адреса для входящих почтовых сообщений

пользователей домена cs.vu.nl. Узел может иметь несколько записей

MX.

Записи

SRV

похожи на записи

MX.

Такая запись содержит имя сервера конкрет-

ной службы. Записи

SRV

определены в

[477].

Конкретная служба определяется по

ее имени вместе с именем протокола. Так, web-сервер домена cs.vu.nl может быть

поименован при помощи такой записи

SRV,

как http.tcp.cs.vu.nl. Эта запись может

ссылаться затем и на реальное имя сервера (soHng.cs.vu.nl).

Узлы, представляющие зону, содержат одну или более записей

(name ser-

ver

—

сервер имен). Как и запись

MX,

запись NS содержит имя сервера имен, реа-

лизующего зону, представленную узлом. В принципе каждый узел пространства

имен может иметь запись

NS,

ссылающуюся на сервер имен, который его реализу-

ет. Однако, как мы ранее говорили, реализация пространства имен DNS такова,

что необходимость содержать записи

существует только для узлов, представ-

ляющих зону.

DNS выделяет псевдонимы для того, что называется

капопическьши глменами

{canonical

names).

Предполагается, что каждый хост имеет каноническое, или пер-

вичное, имя. Псевдоним реализуется посредством узла, хранящего запись

CNAME

(canonical name

—

каноническое имя), которая содержит каноническое имя хоста.

Имя узла, на котором хранится эта запись, совпадает с именем символической

ссылки, как показано на рис. 4.3.

DNS поддерживает обратное отображение IP-адресов на имена хостов посред-

ством записей PTR (pointer

—

указатель). Для того чтобы выполнить поиск среди

имен хостов, когда известен только IP-адрес, DNS поддерживает домен in-addr.arpa,

который содержит узлы, представляющие хосты Интернета и перечисленные в

соответствии с IP-адресами этих хостов. Так, например, для хоста www.cs.vu.nl,

имеющего IP-адрес 130.37.24.11, DNS создает узел с именем 11.24.37.130.in-addr.arpa,

который используется для хранения в записи PTR канонического имени этого

хоста (а именно, soling.cs.vu.nl).

Последние два типа записей

— HINFO

ТХТ.

Запись

HINFO

(host info

—

информа-

ция о хосте) используется для хранения дополнительной информации о хосте,

например о типе машины и операционной системе. Также и записи

ТХТ

(text

—

текст) используются для хранения любой дополнительной информации, кото-

рую пожелает сохранить пользователь о представляемых узлом сущностях.

Реализация DNS

Реализация DNS очень похожа на то описание, которое мы привели в предыду-

щем пункте. В частности, пространство имен DNS можно разделить на глобаль-

4.1.

Именованные сущности 235

ный и административный уровни именно так, как это было показано на рис. 4.6.

Управленческий уровень, обычно складывающийся из локальных файловых сис-

тем, формально не является частью системы DNS и не контролируется ею.

Каждая зона реализована в виде сервера имен. Для лучшей доступности эти

серверы постоянно подвергаются виртуальной репликации. Изменения в зонах,

которые обычно обрабатываются первичным сервером имен, вносятся путем мо-

дификации баз данных DNS локально. Вторичные серверы имен не имеют пря-

мого доступа к базам данных, они посылают запросы первичному серверу, кото-

рый в ответ передает им свое содержимое. Этот процесс в терминологии DNS

называется

переносом

зон

{zone

transfer).

База данных DNS реализуется в виде набора (небольшого) файлов, среди ко-

торых наиболее важный содержит все записи о ресурсах со всех узлов соответст-

вующей зоны. Такой подход позволяет легко идентифицировать узлы по их до-

менным именам, в результате понятие идентификатора узла сводится (неявно) к

индексу файла.

Чтобы лучше понять эту особенность реализации, в табл. 4.4 приведена часть

файла, в котором находится основная информация о домене cs.vu.nl (отметим,

что для лучшего понимания материала файл был изменен). Файл демонстрирует

содержимое восьми различных узлов, представляющих собой часть домена

cs.vu.nl, при этом каждый узел идентифицируется собственным доменным име-

нем.

Таблица 4.4. Выдержка из базы данных DNS для зоны cs.vu.nl

Имя Тип записи

Значение записи

cs.vu.nl

star.cs.vu.nl

zephyr.cs.vu.nl

www.cs.vu.nl

SOA

ТХТ

HINFO

CNAME

star(1999121502.7200.3600.2419200.86400)

star.cs.vu.nl

top.cs.vu.nl

solo.cs.vu.nl

"VrijG

Un1vers1te1t

Math.

Сотр.

Sc."

zephyr.cs.vu.nl

2 tornado.cs.vu.nl

star.cs.vu.nl

Sun

Unix

1 star.cs.vu.nl

10 zGphyr.cs.vu.nl

130.37.24.6

192.31.231.42

Sun Unix

1 zephyr.cs.vu.nl

2 tornado.cs.vu.nl

192.31.231.66

sol1ng.cs.vu.nl

продолжение^

236

Глава 4. Именование

Таблица 4,4

(продолжение)

Имя

Тип записи Значение записи

ftp.cs.vu.nl

soling.cs.vu.nl

laser.cs.vu.nl

vucs-das.cs.vu,

,п1

CNAME

HINFO

PTR

soling.cs.vu.nl

Sun Unix

1 sol1ng.cs.vu.nl

10zephyr.cs.vu.nl

130.37.24.11

PC MS-DOS

130.37.30.32

0.26.37.l30.1n-addr.arpa

130.37.26.0

Узел cs.vu.nl представляет как домен, так и зону. Его запись о ресурсах

SOA

со-

держит специальную информацию о подлинности этого файла, которую мы рас-

сматривать не будем. В этой зоне имеется три сервера имен, канонические имена

их хостов содержатся в записях

NS.

Запись

ТХТ

используется для хранения допол-

нительной информации и не может быть обработана серверами имен автоматиче-

ски.

Кроме того, мы видим три почтовых сервера, обрабатывающих приходящую

почту, адресованную пользователям этого домена. Число перед именем почтового

сервера указывает на приоритет выбора. Отправляющий почту сервер сначала пы-

тается установить контакт с принимающим сервером с наименьшим номером,

дан-

ном примере это zephyr.cs.vu.nl.

Хост star.cs.vu.nl выполняет обязанности сервера имен этой зоны. Серверы имен

важны для любой службы имен. Что мы можем сказать об этом сервере имен?

Ему присуща дополнительная устойчивость, создаваемая двумя независимыми

сетевыми интерфейсами, каждый из которых представлен отдельной записью о

ресурсах

А.

Таким образом, обрыв сетевой связи до некоторой степени пройдет

без последствий.

Следующие четыре строки предоставляют необходимую информацию по поч-

товому серверу. Заметим, что этот почтовый сервер кроме всего прочего архиви-

руется на другой почтовый сервер, путь к которому

—

tornado.cs.vu.nl.

Следующие шесть строк демонстрируют типовую конфигурацию web-сервера фа-

культета, в котором на одной из машин реализован

ftp-сервер

с именем solJng.cs.vu.nl.

При исполнении обоих серверов на одной машине (и использовании этой маши-

ны только для служб Интернета) поддержка системы значительно облегчается.

Так, например, оба сервера могут работать с одним представлением файловой

системы, а для эффективности часть файловой системы можно реализовать на сер-

вере solJng.cs.vu.nl. Подобный подход часто применяется для служб WWW и FTP.

Следующие две строки содержат информацию об одном из лазерных принте-

ров,

соединенных с локальной сетью. Последние две строки демонстрируют об-

ратное отображение адресов в канонические имена. В данном случае имя супер-

компьютера отдела может быть найдено по его адресу в домене in-addr.arpa.

Поскольку домен cs.vu.nl реализован в одной зоне, табл. 4.4 не содержит ссы-

лок на другие зоны. Способ создания ссылок на поддомены, реализованные

4.1.

Именованные сущности 237

в другой зоне, иллюстрирует табл. 4.5. Все, что необходимо,

—

это указать сервер

имен для поддомена, просто задав его доменное имя и IP-адрес. При разрешении

имени узла, который не входит в домен cs.vu.nl, разрешение имени продолжится

в месте, адрес которого будет считан из базы данных DNS для сервера имен до-

мена cs.vu.nl.

Таблица 4.5. Часть описания домена

vu.nl,

содержащая домен cs.vu.nl

Имя Тип записи Значение записи

cs.vu.ni NS

solo.cs.vu.nl

soio.cs.vu.nl А 130.37.24.1

4.1.5. Пример

—

Х.500

Система DNS

—

пример традиционной службы именования. Когда заданы имена

(возможно, иерархически построенные), DNS разрешает имя как узел в графе

именования и возвращает содержимое этого узла в виде записи о ресурсах.

этом смысле разрешение имени в DNS сравнимо с поиском номера телефона

в телефонной книге.

В том, что мы называем службами каталогов, применяется другой подход.

Служба каталогов {directory service)

—

это особый тип службы именования, в ко-

торой клиент может вести поиск суш;ности на основании описания ее свойств,

а не полного Ихмени. Этот подход очень похож на способ, которым люди исполь-

зуют справочник «Желтые страницы», когда им нужно, к примеру, починить

разбитое окно. В этом случае пользователь ищет заголовок «Ремонт окон», а под

ним находит список названий фирм, которые вставляют в окна стекла.

В этом пункте мы кратко рассмотрим службу каталогов OSI Х.500. Несмотря

на то что службы каталогов доступны уже более десятилетия, они стали особен-

но популярными лишь недавно в виде упрощенных версий, реализованных как

службы Интернета. Детальную информацию по Х.500 можно найти в [88, 368].

Практические сведения по различным службам каталогов, включая и Х.500, со-

держатся в

[414].

Пространство имен Х.500

Концептуально служба каталогов Х.500 состоит из множества записей, которые

обычно называются элементами каталога. Элемент каталога в Х.500 похож на за-

пись о ресурсах системы DNS. Каждая запись состоит из набора пар (атрибут,

значение), причем каждый атрибут имеет ассоциированный с ним тип. Различа-

ются атрибуты с одним значением (однозначные) и атрибуты с несколькими зна-

чениями (многозначные). Последние обычно представляют собой массивы или

списки. Так, например, простой элемент каталога, определяющий сетевые адреса

нескольких основных серверов из табл. 4.4, приведен в табл. 4.6.

В этом примере мы использовали соглашение об именовании, описанное в

стандартах на Х.500, которое применили к первым пяти атрибутам. Атрибуты

Organization и OrganizationUnit описывают соответственно организацию и отдел,

238 Глава 4. Именование

ассоциирующиеся

данными, хранящимися

записи. Атрибуты Locality

Coun-

try предоставляют дополнительную информацию

том,

где

хранится элемент.

Атрибут CommonName часто используется

качестве имени (не слишком точно-

го) для идентификации элемента

ограниченной части каталога. Так, например,

имени «Main server» может быть достаточно

для

того, чтобы найти элемент

из

нашего примера, имеющий соответствующие значения остальных четырех атри-

бутов

—

Country, Locality, Organization

OrganizationalUnit. В нашем примере толь-

ко атрибут Mail_Servers имеет несколько значений. Все остальные атрибуты

од-

нозначны.

Таблица 4.6. Простой пример элемента каталога Х.500

Атрибут

Country

Locality

Organization

OrganizationalUnit

CommonName

Mall_Servers

FTP_Server

WWW_Server

Аббревиатура

Значение

Amsterdam

Vrije Un1vers1te1t

Math.

Сотр.

Sc.

Main server

130.37.24.6. 192.31.231.42. 192.31.231.66

130.37.24.11

Набор всех элементов каталога службы каталогов Х.500 называется

информа-

ционной базой каталога

{Directory

Information

Base,

DIB), Важный момент

—

ка-

ждая запись

DIB имеет уникальное имя, чтобы ее можно было найти. Глобаль-

но уникальное

имя

получается

из

последовательности атрибутов именования

каждой записи. Каждый атрибут именования называется

относительно

различи-

мым именем {Relative

Distinguished

Name, RDN).

нашем примере

из

табл.

4.6

первые пять атрибутов

—

это и

есть

все

атрибуты именования. Если использо-

вать стандартные сокращения

для

представления атрибутов именования Х.500,

приведенные

табл. 4.6, атрибуты Country, Organization

OrganizationalUnit можно

использовать для формирования глобально уникального имени:

/C=NL/0=Vrije Univers1te1t/OU=Math.

Comp.Sc.

Это имя аналогично имени nl.vu.cs

системе DNS.

Как

и в

DNS, использование глобально уникальных имен, образуемых после-

довательным перечислением имен RDN, приведет

нас к

иерархии наборов эле-

ментов каталога, которую мы будем называть

информационным деревом

катало-

гов

{Directory

Information

Tree,

DIT). DIT,

сущности, образует граф именования

службы каталогов Х.500,

котором каждый узел представляет собой элемент ка-

талога. Кроме того, узел может также работать каталогом

традиционном смыс-

ле,

него может быть несколько дочерних узлов,

для

которых

он

будет роди-

телем.

Для

пояснения рассмотрим граф именования, частично показанный

на

рис.

4.10.

4.1.

Именованные сущности 239

/\£:

1—( О = Vrije Unlversiteit

уГ-^ои = Math.&Comp.Sc.

CN = Main server

Host Name = star

Host_Name

zephyr

Рис. 4.10. Часть информационного дерева каталогов

Узел

Л^

соответствует элементу каталога, приведенному

табл. 4.6.

В то же

время этот узел выступает

качестве родителя нескольких других элементов ка-

талога, которые имеют дополнительный атрибут именования Host_Name, исполь-

зуемый

качестве RDN.

Эти

сущности могут, например, задействоваться

для

представления хостов, как показано

табл. 4.7.

Таблица 4,7. Два элемента каталога, использующие в качестве

RDN имя Host Name

Атрибут

Country

Locality

Organization

Первый хост

OrganizationalUnit

CommonName

Host_Name

Host_Ad dress

Значение

Amsterdam

Vrije Un1vers1te1t

Math.

Сотр.

Sc.

Main server

star

192.31.231.42

Атрибут

Country

Locality

Organization

Второй хост

OrganizationalUnit

CommonNanne

Host_Name

Host_Address

Значение

Amsterdam

Vrije UniversUeit

Math.

Сотр.

Sc.

Main server

zephyr

192.31.231.66

Узел

графе именования Х.500 может, таким образом, быть представлен

в ви-

де каталога

традиционном смысле,

как мы

обсуждали выше,

и в

виде записи

Х.500.

Это

разница поддерживается двумя различными операциями поиска.

Операция read, предназначенная для чтения одиночной записи, дает ее путь в де-

реве DIT. С другой стороны, операция list используется для построения списка

имен всех ребер, исходящих из данного узла дерева DIT. Каждое имя соответст-

вует узлу, дочернему для данного. Отметим, что операция 11st не возвращает за-

писей, она возвращает только имена. Рассмотрим, например, вызов операции read

со следующим именем

качестве исходных данных:

/C=NL/0=Vr1je Un1versite1t/0U=Math. & Сотр. Sc./CN=Ma1n server

240 Глава 4. Именование

Этот вызов вернет запись, приведенную в табл. 4.6, в то время как вызов опе-

рации read с теми же исходными данными вернет имена star и zephyr из сущно-

стей, представленных в табл. 4.7, а также имена других хостов, зарегистрирован-

ных подобным образом.

Реализация Х.500

Реализация службы каталогов Х.500 выполняется в основном таким же обра-

зом, как и реализация службы имен, такой как DNS, за исключением того, что

Х.500 поддерживает больше операций поиска. Мы это кратко обсудили. При

операциях с большим каталогом дерево DIT обычно разбивается и разносится

по нескольким серверам, которые в терминологии Х.500 называются агентами

службы

каталогов

{Directory Service

Agents,

DSA). Каждая часть разбитого дере-

ва DIT соответствует зоне в DNS. Точно так же каждый агент DSA ведет себя

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

несколько стандартных для службы каталогов служб, таких как расширенные

операции поиска.

Клиенты представлены тем, что называется агенты

пользователей

каталога

{Directory

User

Agents,

DUA). Агент DUA подобен процедуре разрешения имен из

традиционной службы именования. DUA обмениваются информацией с DSA

в соответствии со стандартным протоколом доступа.

Что делает реализацию Х.500 отличной от реализации DNS

—

так это меха-

низмы поиска в базе DIE. В частности, имеются механизмы для поиска элемента

каталога по заданному набору критериев, в который могут входить атрибуты ис-

комых элементов. Например, предположим, что мы хотим получить список всех

главных серверов университета Vrije. Если использовать запись, определенную

[206],

этот список можно вернуть, используя следующую операцию поиска:

answer = search("&(C=NL)(0=Vr1je Univers1te1t)(0U=*)(CN=Main server)")

В этом примере мы определили, что местом, где мы будем искать главные

серверы, является организация под названием Vrije Universiteit в стране

NL,

при

этом нас не интересует конкретный отдел этой организации, однако каждый воз-

враидаемый результат должен иметь значение атрибута CN, равное Main server.

Важно заметить, что подобный поиск в службе каталогов

—

обычно доста-

точно дорогостоящая операция. Так, например, чтобы найти все главные серве-

ры университета Vrije, необходимо найти все сущности в каждом отделе и со-

брать результаты поиска в единый ответ. Другими словами, для получения

ответа мы обычно должны перебрать множество листовых узлов дерева DIT.

На практике это еще означает, что следует перебрать также и множество аген-

тов DSA. В противоположность этому, службы имен часто могут быть реализо-

ваны при помощи операции поиска, нуждающейся в доступе только к одному

листовому узлу.

Система Х.500 находится в одном ряду с множеством других протоколов OSI.

Доступ к каталогу Х.500 в соответствии с официальными правилами

—

дело не

простое. Чтобы приспособить службу каталогов Х.500 к Интернету, был создан