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

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

3.4. Перенос кода 201

Листинг 3.4. Простой пример агента

D'Agent

на языке

Тс1,

пересылающего сценарий на

удаленную машину (адаптация сценария из [179])

ргос factorial п {

if {$п <= 1} {return 1;} #fac(l) = 1

expr $n * [factorial [ expr $n - 1 ]] #fac(n) = n * fac(n-l)

}

set number ...

указать, какой факториал вычислять

set machine ...

идентифицировать целевую машину

agent^submit $machine -procs factorial -vars number -script

{

factorial $number

}

agent_receive ...

получить результат

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

как в форме миграции, так и в форме клонирования процессов. Для переноса ра-

ботающего агента агент вызывает команду agent jump с указанием целевой машины,

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

агента на исходной машине приостанавливается и его сегмент ресурсов, сегмент

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

ние,

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

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

претатор. Этот процесс выполняет демаршалинг пришедшего сообщения и про-

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

jump.

Процесс, в котором агент выполнялся на исходной машине, прекращает

свою работу.

Пример переноса агентов, приведенный в листинге 3.5, иллюстрирует упро-

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

пользователя, выполняя команду

who

UNIX-системы на каждом из хостов. Пове-

дение агента определяется процедурой all_users. Она поддерживает список поль-

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

агентом, определяется параметром mashines. Агент переходит с хоста на хост, по-

мещая результат выполнения команды who в переменную users и добавляя его

списку.

В основной программе на текущей машрп1е создается агент для рассылки

с использованием рассмотренного ранее механизма слабой мобильности. В дан-

ном случае команда agent_submit будет вызвана для выполнения следующего сце-

нария:

dll_users Smachines

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

раметров.

Листинг 3.5. Пример агента

D'Agent

на языке

Тс1,

перемещающегося с машины

на

MaujHHy,

исполняя команду who UNIX-системы (адаптация сценария из [73])

ргос all_users machines {

set list "" # создать изначально пустой список

foreach m Smachines { # для всех хостов из заданных машин

agentjump $m # переместиться на следующий хост

set users [exec who] # выполнить команду who

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

append list $users

добавить результаты

списку

}

return

$11 St

no окончании вернуть список

set machines ...

set this machine

# инициализировать набор машин

# задать хост для старта агента

# Создать агент переноса для переноса сценария

на

ту машину.

которой агент начнет просматривать остальные машины.

# указанные

$mach1nes

agent_subm1t $th1s_mach1ne -procs all^users -vars machines

-script (an_users $mach1nes}

agent_receive

...

получить результат

И, наконец, поддерживается клонирование процессов посредством команды

agent_fork. Эта команда работает почти так же, как и agentjump, за исключением

того,

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

работу с инструкции, следующей за вызовом agent^fork. Подобно операцрш fork

в UNIX-системах, команда agent^fork возвращает значение, по которому вызвав-

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

(в UNIX именуемая «дочерней») или оригинальный процесс («родитель»).

Вопросы реализации

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

санные на

Тс1

агенты. Изнутри система D'Agent состоит из пяти уровней, как по-

казано на рис. 3.11. Самый нижний уровень сравним с сокетами Беркли, в том

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

вой сети. В D'Agent предполагается, что базовая сеть предоставляет механизмы

для работы с сообщениями TCP и электронной почты.

Агенты

Интерпретатор

Тс1Як

Интерпретатор

Scheme

Интерпретатор

Java

Обобщенный агент RTS

Сервер 1

TCP/IP

E-mail

Рис. 3.11. Архитектура системы

D'Agent

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

торой выполняется D'Agent. Сервер отвечает за управление агентами, авториза-

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

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

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

3.4. Перенос кода 203

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

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

Третий уровень

—

сердце системы D'Agent. Он содержит независимое от язы-

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

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

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

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

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

Четвертый уровень содержит интерпретаторы, по одному на каждый поддер-

живаемый в D'Agent язык. Каждый интерпретатор содержит компонент интер-

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

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

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

ниже.

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

живаемых системой языков. Каждый агент D'Agent выполняется в отдельном

процессе. Так, например, когда агент переносится на машину Л, сервер разветв-

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

выполнения этого агента. Новый процесс подхватывает состояние мигрировав-

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

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

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

Более сложная часть реализации D'Agent

—

это получение состояния рабо-

тающего агента и передача его на другую машину. В случае

Тс1

состояние агента

описывается частями, показанными в табл. 3.3. По существу, состояние агента

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

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

Таблица 3,3. Части, описывающие состояние агента в системе

D'Agent

Состояние Описание

Глобальные переменные Переменные, необходимые интерпретатору агентов

интерпретатора

Глобальные системные Коды возврата, коды ошибок, строки сообщений

переменные об ошибках и т. д.

Глобальные переменные Определяемые пользователем глобальные переменные

программы программы

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

Стек команд Стек выполняемых в настоящее время команд

Стек вызовов Стек записей об активизации, по одной на каждую

выполняемую команду

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

менные. Так, обработчик событий может сообщать интерпретатору, какую про-

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

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

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

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

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

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

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

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

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

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

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

—

два сте-

ка, в которых хранится истинное состояние выполнения агента. В основе каждо-

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

как циклы, инструкцрш множественного выбора и т. д. Кроме того, команды мо-

гут быть сгруппрфованы в процедуры. Как это происходит во всех интерпрети-

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

Сначала рассмотрим, что происходит при выполнении базовой команды Тс1,

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

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

ваем

стеком

команд

(command

stack).

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

выполнения команды поля, как

то:

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

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

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

ми,

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

ния агента.

Тс1

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

команд среда исполнения D'Agent отслеживает стек записей активизации, также

называемых фреймами вызова. Фрейм вызова в D'Agent содержит таблицу пере-

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

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

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

команд. Фрейм вызова содержит ссылку на связанную с ним команду.

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

agent_jump, при помощи которой он переносится на другую машину. В этот мо-

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

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

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

Сервер D'Agent на целевой машине создает новый процесс, запуская интерпре-

татор Тс1. Процесс обрабатывает полученные данные, выполняет их демарша-

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

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

снятия с вершины стека команд очередной команды.

3.5. Программные агенты

Теперь мы рассмотрим процессы под несколько другим углом. Сначала мы сосре-

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

3.5. Программные агенты 205

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

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

и процессов. Эти более или менее независимые представления процессов объеди-

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

—

автономные едини-

цы,

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

ми агентами.

Агенты играют в распределенных системах все более важную роль. Однако

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

тивное определение того, что такое процесс

[334].

Определение программных

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

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

темах.

3.5.1.

Программные агенты

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

Существует множество мнений о том, что такое агент. Взяв за основу описание,

данное в

[173],

мы определяем

программный агент {software

agent) как автоном-

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

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

агентами. Свойство, которое делает агента чем-то большим, чем процесс,

—

это

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

димости инициативу.

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

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

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

ные агенты, будет разумнее говорить о разных типах программных агентов. То

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

граммных агентов, но договориться о единой классификации исследователям, по

всей видимости, нелегко.

Помимо автономности важнейшее качество агентов

—

возможность коопери-

роваться с другими агентами. Сочетание автономности и кооперации приводит

нас к классу кооперативных агентов

[320].

Кооперативный

агент

{collaborative

agent) —

это агент, составляющий часть мультиагентной системы, то есть систе-

мы,

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

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

—

это электронная конфе-

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

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

том всех персональных ограничений на время, местоположение, перемещение

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

цию.

В перспективе, таким образом, могут производиться разработки распреде-

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

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

агенты. Мобильный агент

{mobile

agent)

—

это просто агент, у которого имеется

способность перемещаться с машины на машину. В терминах, которые мы ис-

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

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

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

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

факта, что агенты автономны и активно взаимодействуют со своей средой. Пере-

нос агента на другую машину без учета его состояния будет сильно затруднен.

Однако как было показано на примере системы D'Agent, сочетание агентов и сла-

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

—

это об-

щее свойство агентов, наличие которого не приводит к выделению особого их

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

оперативных агентов. Хороший пример практического использования мобиль-

ных агентов приведен в [74], где авторы описывают использование мобильных

агентов для получения информации, распределенной по большой гетерогенной

сети, такой как Интернет.

Способность к кооперации с другими агентами или перемещению между ма-

шинами

—

это системные свойства агентов. Они не говорят нам ничего о назна-

чении агента. Для изучения функциональности агента нам требуется другая клас-

сификация.

Традиционно выделяемый класс

—

это класс интерфейсных агентов. Интер-

фейсный агент {interface agent)

—

это агент, помогающий конечному пользова-

телю работать с одним или несколькими приложениями. Среди традиционно

имеющихся у интерфейсного агента свойств можно считать способность к обуче-

нию [280, 320]. Чаще всего они взаимодействуют с пользователями, обеспечивая

им поддержку. В контексте распределенных систем примером интересного ин-

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

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

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

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

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

Очень близок к интерфейсному агенту

информационный

агент {information

agent).

Основная функция подобных агентов — управление информацией из

множества различных источников. Управление информацией включает в себя

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

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

формацией из физически разных источников. Стационарные информационные

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

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

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

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

им,

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

ти,

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

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

в табл. 3.4

[152].

Дальнейшее разделение агентов можно провести, рассматривая,

как они реально работают с точки зрения искусственного интеллекта. Краткий

обзор этой стороны дела можно найти в [175, 196, 496].

3.5. Программные агенты 207

Таблица 3.4. Некоторые важные свойства агентов

Свойство

Общность

для агентов

Описание

Автономность

Реактивность

Проактивность

Коммуникативность

Продолжительность

Мобильность

Адаптивность

Да

Нет

Способность работать независимо от других

Способность своевременно реагировать

на изменения в своем окружении

Способность инициировать действия,

влияющие на их окружение

Способность обмениваться информацией

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

Относительно долгое время жизни

Способность перемещаться с места на место

Способность к обучению

3.5.2. Технология агентов

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

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

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

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

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

FIPA

(Founda-

tion

for

Intelligent Physical Agents)

разработала обобщенную модель программных

агентов. Согласно этой модели агенты регистрируются и работают под управле-

нием платформы агентов, как показано на рис. 3.12. Платформа агентов предо-

ставляет основные службы, необходимые любой мультиагентной системе. Сюда

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

агентов и механизмы взаимодействия между агентами.

Программа-агент

^ Агент

Платформа

Конечная точка агента

агента

Компоненты

управления

агентами

Служба

каталогов

;г

Межплатформенная

связь

Канал связи

между

агентами

Межплатформенная

связь

Рис. 3.12. Обобщенная модель платформы агента (адаптировано из [143])

Компонент управления агентами отслеживает агентов на соответствующей

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

же для просмотра текущей конечной точки на предмет наличия конкретного

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

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

торой глобально уникальный идентификатор отображается на локальную конеч-

ную точку взаимодействия. Службы именования детально обсуждаются в сле-

дующей главе.

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

щи которой агенты могут узнать, какие еще агенты имеются на этой платформе.

Служба каталогов в модели FIPA основана на использовании атрибутов. Это

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

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

устроен справочник «Желтые страницы». К службе каталогов могут иметь до-

ступ удаленные агенты, то есть агенты, находящиеся на других платформах

агентов.

Важный компонент платформы агента

— ка}1ал

связи

между агентами

{Agent

Communication

Channel,

АСС). В большинстве моделей мультиагентных систем

агенты связываются друг с другом, пересылая сообщения. Модель FIPA

—

не ис-

ключение, она возлагает на АСС ответственность за все взаимодействие между

различными платформами агентов. В частности, АСС отвечает за надежную

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

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

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

верам или агентам, являющимся частью платформы агентов. Для обеспечения

межплатформенного взаимодействия связь между АСС соответствует Интернет-

протоколу ПОР (Internet Inter-ORB Protocol), который мы будем обсуждать

в главе 9. В архитектуре D'Agent в качестве АСС выступает сервер.

Языки взаимодействия агентов

Итак, у платформ агентов есть своя специфика. Отличие от других подходов

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

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

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

вестного под названием языка взаимодействия агентов {Agent Communication

Language, ACL). В ACL присутствует жесткое разделение между целью сооб-

щения и его

содержанием.

Сообщение может иметь только ограниченный набор

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

чателем определенной службы.

Также целью сообщения может быть ответ на ранее присланное сообщение

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

мающей стороны о произошедшем событии или предложение чего-либо в ходе

согласования. Некоторые из целей сообщений на языке ACL, разработанные

FIPA, перечислены в табл. 3.5.

Идея ACL состоит в том, что агент-отправитель и агент-получатель как мини-

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

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

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

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

PROPOSE.

В этом

3.5. Программные агенты 209

смысле

ACL

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

протокол для набора агентов.

Таблица 3.5. Примеры целей сообщения и описание содержания сообщений

Цель сообщения Описание Содержание

сообщения

INFORM Информировать, что данное

предположение истинно

QUERY

-1F Запросить, истинно ли данное

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

QUERY-REF Запрос данного объекта

СЕР

Запросить предложение

PROPOSE

Предоставить предложение

ACCEPT-

PROPOSAL

Сообщить, что данное предложение

принято

REJECT-

PROPOSAL

Сообщить, что данное предложение

отвергнуто

REQUEST

Запросить осуществления действия

SUBSCRIBE Подписаться

на

источник информации

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

Выражение

Зависит

от предложения

Предложение

Идентификатор

предложения

Идентификатор

предложения

Спецификация действия

Ссылка на источник

Как

большинство коммуникационных протоколов, сообщения ACL состоят

из заголовка

реального содержания. Заголовок содержит поле цели сообще-

ния, а также поля отправителя

получателя. Кроме того, как и во многих других

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

независимо

от

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

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

держания сообщения.

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

обходимая информация

для

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

Для

этого

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

вания содержания. Этот подход хорошо работает

до тех

пор, пока отправитель

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

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

поля, идентифицирующие стандартное отображение символов

их смысл. Такое

отображение обычно называется

онтологией

(ontology).

Приведем простой пример. В табл. 3.6 показано сообщение на языке ACL, ис-

пользуемое

для

информирования агента

генеалогических связях

королев-

ском семействе Нидерландов. Для определения агента, отправившего сообщение,

и агента, которому оно предназначено, каждый

из

агентов имеет имя, состоящее

из нескольких компонентов. Так, например, значение max@http://fanclub-beatrix.

royalty-spotters.п1:7239 может использоваться для ссылки на агента с именем max,

находящегося

на

агентской платформе

DNS-именем fanclub-beatrix.royalty-

spotters.nl. Для связи

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

вано из DNS

IP-адрес. Кроме того, доступ

имени, указанному для связи, дол-

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

по

протоколу HTTP

на

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

его хост. Ожидает их прихода сервер на порту под номером 7239. В нашем при-

мере агент max посылает информационное сообщение агенту eike, расположен-

ному на платформе под именем royalty-watcher.uk. Сообщения должны посылать-

ся по протоколу ПОР (мы обсудим его в главе 9) на порт под номером

5623.

Таблица 3.6. Простой пример сообщения ACL, пересылаемого

одним агентом другому

Поле Значение

Цель

INFORM

Отправитель max@http://fanclub-beatrlx.royalty-spotters.nl:7239

Получатель elke@iiop.7/royalty-watcher.uk:5623

Язык Prolog

Онтология Genealogy

Содержимое

femal eCbeatri

х),

parent (beatri

х.

jul

ana.

bernhard)

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

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

языке Prolog, а поле онтологии определяет, что эти конструкции Prolog интер-

претируются как генеалогическая информация. В результате получающий сооб-

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

х —

это имя женщины:

female(beatrix)

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

beatriх зовут именем Juliana, а отца

—

именем Bernhard:

parent(beatrix.Juliana,bernhard)

3.6. Итоги

Процессы играют фундаментальную роль в распределенных системах, поскольку

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

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

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

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

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

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

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

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

да-вывода или операций сетевого взаимодействия.

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

и серверов. Клиентский процесс обычно реализует пользовательский интерфейс,

который может варьироваться от простого вывода информации до расширенных

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

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