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

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

3.1.

Потоки выполнения 171

Использование облегченных процессов в сочетании с пакетами потоков вы-

полнения пользовательского режима дает определенные преимущества. Во-пер-

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

задействовать ядро и поэтому относительно недорого. Во вторых, предоставле-

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

рующий системный вызов не обеспечивает полной остановки процесса. В-третьих,

приложению нет нужды знать об облегченных процессах. Все, что оно видит,

—

это потоки выполнения пользовательского уровня. В-четвертых, облегченные про-

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

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

параллельная обработка может происходить абсолютно незаметно для приложе-

ния. Единственным минусом облегченных процессов в сочетании с потоками вы-

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

уничтожения самих облегченных процессов. Затраты на эти операции не отлича-

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

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

чая к случаю, и нередко эти процессы полностью находятся под управлением

операционной системы.

Альтернативным, но схожим с облегченными процессами подходом [14] яв-

ляются активизации

планировщика {scheduler

activations).

Основная разница ме-

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

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

ков,

который осуществляет вызов процедуры планировщика. Вызванный плани-

ровщик переключает выполнение на следующий поток. Те же самые действия

повторяются и после того, как процесс будет разблокирован. Преимущество по-

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

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

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

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

кущим нижний уровень.

3.1.2. Потоки выполнения

в распределенных системах

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

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

цесса на время выполнения потока. Это свойство потоков выполнения особенно

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

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

го количества логических соединений. Мы проиллюстрируем это утверждение,

рассматривая многопоточных клиентов и серверов.

Многопоточные клиенты

Чтобы добиться высокой степени прозрачности распределения, распределенные

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

172 Глава 3. Процессы

ших задержек сообщений, курсирующих между процессами. Цикл задержки

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

нами и секунд.

Традиционный способ скрыть задержки связи

—

инициировав взаимодейст-

вие,

немедленно перертти к другой работе. Типичным примером применения

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

жащийся в файле формата HTML, содержит, кроме текста, набор изображений,

значков и т. п. Для получения элементов web-докуменга браузер открывает со-

единение TCP/IP, читает поступающие данные и преобразует их в компоненты

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

представляет собой блокирующие операции. При работе с медленными комму-

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

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

Web-браузер обычно сначала получает страницу HTML-кода, а затем пока-

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

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

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

получение остальных файлов, необходимых для правильного отображения стра-

ницы, таких как картинки. По мере поступления они отображаются на экране.

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

даться получения всех ее компонентов.

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

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

упрощает это занятие. Как то.яько мы получаем основной файл HTML, активи-

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

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

с сервером и получает от него данные. Установление соединения и чтение данных

с сервера может быть запрограммировано с использованием стандартных (бло-

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

в состоянии приостановить основной процесс. Как показано в

[438],

код каждого

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

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

не может просматривать документ.

Использование многопоточных web-браузеров, которые в состоянии откры-

вать несколько соединений, дает также и другой выигрыш. В предыдущем при-

мере мы создавали несколько соединений с одним и тем же сервером. Если этот

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

тельного повышения производительности по сравнению с последовательным (од-

ного за другим) получением файлов.

Однако во многих случаях web-серверы могут быть реплицированы на не-

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

бор web-документов. Реплицированные серверы находятся в одном и том же мес-

те и имеют одно и то же имя. При поступлении запроса на web-страницу этот

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

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

[227].

3.1.

Потоки выполнения

173

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

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

эффективно способствовать тому, что web-документ будет показан полностью

значительно быстрее, чем в случае нереплицированного сервера. Этот подход

срабатывает, только если клиент в состоянии обработать истинно параллельные

потоки входящих данных. В этом случае потоки выполнения идеально подходят

для обработки потоков данных.

Многопоточные серверы

Хотя многопоточные клиенты, как мы видели, обладают весомыми достоинства-

ми,

основные достоинства многопоточности в распределенных системах прихо-

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

существенно упрощает код сервера, но и делает гораздо проще разработку тех

серверов, в которых для достижения высокой производительности требуется

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

и мультипроцессорные системы. Даже сейчас, когда мультипроцессорные компь-

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

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

альности.

Чтобы ощутить достоинства потоков выполнения для написания кода серве-

ров,

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

вается блокированным ожиданием дртска. Файловый сервер обычно ожидает

входящего запроса на операции с файлами, после чего обрабатывает полученный

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

ций показана на рис. 3.3. Здесь один из потоков выполнения,

диспетчер,

считы-

вает приходящие запросы на файловые операции. Запросы посылаются клиента-

ми с указанием конечной точки данного сервера. После проверки запроса сервер

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

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

Запрос

перенаправляется

Поток-диспетчер рабочему потоку

V / j^

Запрос,

приходящий

из сети

Сервер

Рабочий поток

Рис. 3.3. Многопоточный сервер, организованный

по схеме диспетчер—рабочий

174 Глава 3. Процессы

Рабочий поток осуществляет блокирующее чтение из локальной файловой

системы, что приводит к приостановке потока выполнения до считывания дан-

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

может быть передано другому потоку выполнения. Например, дополнительную

работу может выполнить поток-диспетчер. Либо он может выбрать другой гото-

вый к запуску рабочий поток.

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

ков выполнения. Одна из возможностей

—

действовать так, как будто имеется

единственный поток выполнения. Основной цикл файлового сервера получает

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

щий. Пока сервер ожидает окончания дисковых операций, он не обрабатывает

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

Кроме того, если файловый сервер работает на выделенной машине (а так обыч-

но и бывает), процессор во время дисковых операций просто ничем не занят.

В результате обрабатывается значительно меньшее количество запросов в секун-

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

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

на выполнение поочередно.

Таким образом, мы наблюдаем две возможные архитектуры

—

многопоточ-

иый файловый сервер и однопоточный файловый сервер. Возможно также, что

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

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

лает ее применение невозможным. Третья возможность заключается в использо-

вании сервера в качестве большого конечного автомата. По приходе запроса его

проверяет единственный поток выполнения. Если он может быть удовлетворен

путем обращения к кэшу, отлично, в противном случае происходит обращение

к дисковой системе.

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

го запроса в таблицу и переходит к ожиданию и получению нового сообщения.

Новое сообщение может быть как запросом на совершение новой операции, так

и ответом на предыдущий запрос от дисковой подсистемы. Если это новый за-

прос,

мы начинаем новую работу. Если это ответ от диска, из таблицы извлекается

соответствующая информация, ответ формируется и передается клиенту. Соглас-

но этой схеме, сервер должен быть в состоянии осуществлять неблокирующие

вызовы send и receive.

В подобной архитектуре модель «последовательных процессов», которую мы

наблюдали в первых двух случаях, отсутствует. Состояние вычислений для каж-

дого принимаемого и отправляемого сообщения должно полностью сохраняться

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

ки выполнения и их стеки. Процесс, протекающий в конечном автомате, состоит

в восприятии событий и зависящей от их типа реакции на эти события.

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

можным одновременное сохранение идеи последовательных процессов, осущест-

вляющих блокирующие системные вызовы (как при вызовах RPC для работы

с диском), и параллельной работы. Блокирующие системные вызовы упрощают

3.2. Клиенты 175

программирование, а параллельность повышает производительность. Однопо-

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

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

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

из-за неблокирующих вызовов тяжело программируется. Эти подходы суммиро-

ваны в табл. 3.1.

Таблица 3.1. Три способа построения сервера

Модель Характеристики

Потоки выполнения Параллельность, блокирующие системные

вызовы

Однопоточный процесс Отсутствие параллелизма, блокирующие системные

вызовы

Конечный автомат Параллелизм, неблокирующие системные

вызовы

3.2. Клиенты

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

вера и способы их взаимодействия. Теперь мы рассматриваем анатомию клиен-

тов и серверов. Начнем с рассмотрения клиентов. Серверы будут рассматривать-

ся в следующем разделе.

3.2.1.

Пользовательские интерфейсы

Основная задача большинства клиентов

—

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

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

са

—

основная функция большинства клиентов. Во многих случаях интерфейс

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

паратуру клиента. Так, например, сотовые телефоны в придачу к традиционному

набору кнопок для набора номера имеют небольшой дисплей. Сколько-нибудь

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

плектации настоящей клавиатурой, электронным планшетом или устройством рас-

познавания речи.

Важный класс интерфейсов составляют графические пользовательские интер-

фейсы. Далее мы сперва рассмотрим в качестве примера традиционного пользо-

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

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

Система X-Windows

Система X-Windows, обычно называемая просто X, используется для управления

растровыми терминалами, в состав которых входят монитор, клавиатура и коор-

динатное устройство, такое как мышь. На самом деле X можно рассматривать как

часть операционной системы, отвечающую за терминалы. Сердце системы ~ это

176 Глава 3. Процессы

то,

что мы называем Х-ядро (X

kernel).

Оно содержит все необходимые для управ-

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

конфигурации.

Х-ядро предоставляет относительно низкоуровневый интерфейс для управ-

ления экраном и перехвата сообщений, поступающрхх от клавиатуры и мыши.

Этот интерфейс доступен для приложений в виде библиотеки ХНЬ. Соответст-

вующая организация показана на рис. 3.4. (В терминологии X-Windows Х-ядро

называется Х-сервером, в то время как программа, использующая его функции,

называется Х-клиентом. Чтобы избежать путаницы со стандартной терминоло-

гией клиент-сервер, мы воздержимся от использования терминов Х-сервер и

Х-клиент.)

Машина сервера

Машина клиента

Интерфейс Xlib

Х-протокол

Терминал (включая дисплей,

клавиатуру, мышь и т. д.)

Х-ядро

Драйверы устройств

Рис. 3.4. Базовая организация системы X-Windows

Система X различает два типа программ

—

обычные приложения и менедже-

ры окон. Нормальные приложения обычно запрашивают (через

ХНЬ)

создание

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

того,

X гарантирует, что если окно приложения активно и указатель мыши нахо-

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

ны в приложерше.

Менеджер

окон {window manager) — это приложение, которому дано особое

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

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

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

всегда выводиться одним и тем же цветом. Соответственно, менеджер окон опре-

деляет «вид и цвет» самой оконной системы.

У Х-системы имеется интересная особенность, заключающаяся в том, что

Х-ядро и приложения, используюш;ие Х-систему, не обязательно должны распо-

лагаться на одной и той же машине. Так, Х-система поддерживает Х-протокол

—

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

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

с Х-ядром. Это приводит к существованию множества различных вариантов ар-

хитектуры клиент-сервер с широкой степенью варьирования уровня интеллекту-

альности клиента. В своей примитивнейшей форме клиент представляет собой

3.2. Клиенты 177

«голое» Х-ядро, в то время как весь код приложения находится на удаленной ма-

шине. Сконфигурированный таким образом терминал часто называют просто

Х-терминалом (X terminal). В наиболее интеллектуальном виде на клиентской

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

окон, и необходимость в сетевой связи отпадает.

Важно понимать, что системы пользовательского интерфейса, такие как Х-сис-

тема, только предоставляют приложениям пользовательский интерфейс. Един-

ственная информация, которую подобные приложения могут получать из систе-

мы,

—

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

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

нажатия клавиш, перемещение мыши и операции с кнопками мыши и т. п.

Составные документы

Как мы уже говорили в главе 1, современные пользовательские интерфейсы мо-

гут делать значительно больше, чем X-Windows. Так, они позволяют приложени-

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

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

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

вают соответственно операциями

перетаскивания

(drag-and-drop) и редактиро-

вания по месту (in-place editing).

Типичным примером функциональности перетаскивания является перемеще-

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

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

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

значок Л переносится на изображение мусорной корзины, он должен передать

имя файла Л приложению, ассоциированному с мусорной корзиной. Немного по-

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

Редактирование по месту может быть с успехом проиллюстрировано на при-

мере документа, содержащего текст и графику. Представьте себе, что документ

просматривается при помощи стандартного текстового редактора. Как только поль-

зователь перемещает мышь на изображение, пользовательский интерфейс пере-

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

пользователю внести в изображение изменения. Так, пользователь может повер-

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

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

и ширину рисунка и передать эту информацию текстовому редактору. Послед-

ний, в свою очередь, сможет автоматически обновить вид страницы.

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

—

это понятие

составном

документе

{compound

document).

Составной документ можно опре-

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

сунки, электронные таблицы и т. д.), которые интегрируются в одно целое на

уровне пользовательского интерфейса. Пользовательский интерфейс, в котором

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

мента работают различные приложения. С точки зрения пользователя, все части

соедрпгены в одно целое. Если изменение одной из частей влечет за собой изме-

178 Глава 3. Процессы

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

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

Аналогично ситуации, описанной для системы X-Windows, приложение, ас-

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

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

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

работы, чем интерфейс, который этого не делает.

3.2.2. Клиентское программное обеспечение,

обеспечивающее прозрачность распределения

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

не только пользовательский интерфейс. Во многих случаях на стороне клиента

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

вер.

На основе встроенного клиентского программного обеспечения функциониру-

ет целый класс специализированных устройств, таких как автоответчики (ATM),

счетчики купюр, считыватели штрих-кодов, телеприставки и

др.

В подобных слу-

чаях пользовательский интерфейс является относительно небольшой частью

клиентского программного обеспечения по сравнению со средствами локальной

обработки и коммуникаций.

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

программного обеспечения, клиентское программное обеспечение содержит ком-

поненты, обеспечивающие прозрачность распределения. В идеале клиент не дол-

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

серверов же, напротив, информация о распределенной работе обычно не скрыва-

ется в целях повышения производительности и корректной работы. Так, в гла-

ве 6 мы увидим, что реплицируемые серверы должны время от времени свя-

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

операций в каждой из реплик.

Прозрачность доступа обычно обеспечивается путем генерации (в виде за-

глушки клиента) из определения интерфейса того, что должен делать сервер. За-

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

ницу архитектур и реальное взаимодействие.

Существуют различные способы реализации прозрачности размещения, пере-

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

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

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

ент уже привязан к серверу, он может напрямую извещаться об изменении ме-

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

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

сти незаметно повторить привязку к этому серверу. Самое большее, что может

заметить приложение клиента,

—

это временное падение производительности.

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

зрачность репликации на стороне клиента. Представим себе, например, распре-

3.3. Серверы 179

деленную систему с удаленными объектами. Репликацию удаленного объекта

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

рис.

3.5. Заместитель клиента в состоянии прозрачно собрать все ответы и пере-

дать приложению клиента одно возвращаемое значение.

Заместитель размножает

запросы

Реплика 1

Реплика 2

Реплика 3

Все реплики получают ^т'

одно и то же обращение

Рис. 3.5. Возможный подход к прозрачной репликации удаленных объектов

с использованием клиентского программного обеспечения

И, наконец, обсудим прозрачность к сбоям. Маскирование сбоев во взаимо-

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

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

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

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

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

ние клиента, в случае если web-браузер не в состоянии связаться с сервером, воз-

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

Прозрачность параллельного исполнения может обеспечиваться специальны-

ми промежуточными серверами, так называемыми мониторами транзакций, и тре-

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

Прозрачность сохранности также реализуется серверами.

3.3. Серверы

Давайте теперь подробнее рассмотрим организацию серверов. На следующих

страницах мы сосредоточимся на некоторых общих вопросах строения серверов,

а затем поговорим о серверах объектов. Серверы объектов имеют большое значе-

ние

—

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

ектов.

3.3.1.

Общие вопросы разработки

Сервер

—

это процесс, реализующий некоторую службу, требующуюся группе

клиентов. Все серверы работают схожим образом: они ожидают входящего сооб-

180 Глава 3. Процессы

идения, посылаемого клиентом, затем проверяют это сообщение на правильность,

после чего ожидают следующего сообщения.

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

тивного сервера {iterative server)

сервер сам обрабатывает запрос и при необходи-

мости возвращает клиенту ответное сообщение.

Параллельный сервер

(concwrent

server)

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

нения или другой процесс, после чего сразу же переходит в состояние ожидания

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

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

пришедший запрос может выделяться новый процесс. Подобный подход приме-

няется во многих UNIX-системах. Поток или процесс, обрабатывающий запрос,

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

Другой момент

—

каким образом клиент обращается к серверу. Клиент всегда

посылает запросы в

конечную

точку

{endpoint),

также именуемую

портом

{port),

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

ную ему конечную точку. Как клиент узнает конечную точку конкретной службы?

Одно из решений

—

глобальное назначение конечных точек широко распростра-

ненным службам. Так, серверы, обслуживающие запросы к FTP в Интернете,

всегда работают с портом

21.

HTTP-серверам World Wide Web всегда назначает-

ся TCP-порт 80. Эти конечные точки назначены организацией назначения номе-

ров Интернета (Internet Assigned Numbers Authority, I ANA) и документированы

[379].

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

адрес той машины, на которой запущена служба. Как мы увидим в следующей

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

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

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

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

мой. В этом случае клиент должен сначала определить конечную точку. Одно из

решений, которое обсуждалось нами для среды DCE,

—

это создание специаль-

ного демона, запускаемого на каждой машине, на которой работают серверы. Де-

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

данной машине. Демон сам просматривает общедоступные конечные точки. При

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

зывается с нужным ему сервером, как показано на рис. 3.6, а.

Обычно конечная точка ассоциируется с конкретной службой. Однако на са-

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

тельно щедрым расходованием ресурсов. Так, например, в типичных UNIX-сис-

темах нередко имеется множество одновременно работающих серверов, при этом

большая их часть пассивно ожидает запросов от клиента. Вместо ведения такого

множества пассивных процессов нередко эффективнее иметь один суперсервер

{superserver),

просматривающий все конечные точки, относящиеся к конкретным

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

мон inetd в UNIX. Этот демон просматривает множество стандартных портов

служб Интернета. В случае прихода запроса он разветвляет процесс и передает