ОБОБЩЕНИЯ


13.1. ВВЕДЕНИЕ

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


13.2. КРАТКОЕ ОПИСАНИЕ УЖЕ ПРЕДСТАВЛЕННЫХ УТИЛИТ

13.2.1. Напоминание

Различают утилиты, предназначенные для распределения данных
и утилиты ,предназначенные для распределения обработки:

- распределение данных:
- NFS (Network File System - Сетевая Файловая Система)
или RFS (Remote File Sharing - Дистанционное Разделе-
ние Файлов);
- XDR (eXternal Data Representation - Внешнее Представ-
ление информации);
- продукция SQL;
- распределение обработки:
- библиотека ПЗУ или TLI (интерфейс транспортного уровня);
- RPC (Remote Procidure Call - Дистанционный Вызов Про-
цедуры) Sun или NCS (Network Computing System - Сете-
вая Вычислительная Система;
- X Window и его дополнение 3D PEX (PHIGS расширение для
X Window).
В таблице 13.1 содержится краткое описание утилит UNIX.
Третья колонка показывает - возможно ли расширение данных ме-
ханизмов на другие операционные системы.

+
Таблица 13.1 Краткое описание утилит.

-----------T--------------------------T-------------------------¬
¦ ¦ Системы ¦ Другие ¦
¦ ¦ UNIX ¦ системы ¦
+----------+--------------------------+-------------------------+
¦ На одной ¦ программный канал ¦ ¦
¦ машине ¦ именованный канал ¦ ¦
¦ ¦ очередность сообщений ¦ ¦
¦ ¦ семафор ¦ ¦
¦ ¦ распределенная память ¦ ¦
¦ ¦ сокеты ¦ ¦
¦ ¦ TLI ¦ ¦
¦ ¦ RPC ¦ ¦
¦ ¦ X Window ¦ ¦
+----------+--------------------------+-------------------------+
¦ Между ¦ именованный канал ¦ ¦
¦ машинами ¦ сокеты ¦ сокеты ¦
¦ ¦ TLI ¦ ¦
¦ ¦ RPC ¦ RPC ¦
¦ ¦ XDR ¦ XDR ¦
¦ ¦ X Window ¦ X Window ¦
¦ ¦ NFS ¦ NFS ¦
¦ ¦ продукты SQL ¦ продукты SQL ¦
L----------+--------------------------+--------------------------

Напомним, что возможно использование TLI и RPC на одной ма-
шине, но это неоптимальное решение, т.к. драйвер использует
уровни TCP/IP.

13.2.2. Выбор по предлагаемым возможностям

В таблице 13.2 утилиты расклассифицированы в зависимости от
функций, которые они выполняют:
* означает, что утилиту можно использовать, но это не луч-
ший вариант;
** означает, что утилита полностью отвечает потребностям.

Таблица 13.2 Выбор утилит по функциональным критериям.
---------------------------T------T-----T-----T-----T-----T-----¬
¦ ¦сокеты¦ RPC ¦ X11 ¦ XDR ¦ NPS ¦ SQL ¦
¦ ¦ TLI ¦ ¦ PEX ¦ ¦ RPS ¦ ¦
+--------------------------+------+-----+-----+-----+-----+-----+
¦ синхронизация ¦ ** ¦ * ¦ ¦ ¦ ¦ ¦
¦ между процессами ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------------------+------+-----+-----+-----+-----+-----+
¦ передача данных ¦ ** ¦ * ¦ ¦ ¦ ¦ ¦
¦ ASCII ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------------------+------+-----+-----+-----+-----+-----+
¦ передача двоичных ¦ * ¦ ** ¦ ¦ * ¦ ¦ ¦
¦ данных ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------------------+------+-----+-----+-----+-----+-----+
¦ доступ к базе ¦ ¦ ¦ ¦ ¦ * ¦ ** ¦
¦ данных ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------------------+------+-----+-----+-----+-----+-----+
¦ распределение ¦ ¦ ¦ ¦ ¦ ** ¦ ¦
¦ данных ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------------------+------+-----+-----+-----+-----+-----+
¦ представление двоичных ¦ ¦ ¦ ¦ ** ¦ ¦ ¦
¦ данных ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------------------+------+-----+-----+-----+-----+-----+
¦ распределение ¦ * ¦ ** ¦ ¦ ¦ ¦ ¦
¦ сложной обработки ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------------------+------+-----+-----+-----+-----+-----+
¦ распределение ¦ * ¦ * ¦ ** ¦ ¦ ¦ ¦
¦ интерфейса ¦ ¦ ¦ ¦ ¦ ¦ ¦
+--------------------------+------+-----+-----+-----+-----+-----+
¦ распределение ¦ * ¦ * ¦ ** ¦ ¦ ¦ ¦
¦ графики ¦ ¦ ¦ ¦ ¦ ¦ ¦
L--------------------------+------+-----+-----+-----+-----+------


13.2.3. Технические характеристики.

После краткого обзора области применения утилит мы переходим
к рассмотрению их технических характеристик.
Примеры эхофункции символьной строки, приведенные в настоя-
щей книге, использовались для осуществления измерений. Прог-
раммный код, выполняющий эхо, был в этих тестах удален для то-
го, чтобы осуществить измерения на использовании функции типа
производитель-потребитель между процессом клиента и процессом
сервера. Клиент пишет данные, которые считываются сервером.
Такой принцип действия нагляднее представляет реальные прик-
ладные программы, чем принцип эхо.
Время, необходимое для передачи буферов, измеряется с по-
мощью двух обращений к функции times (Смотри Приложение А.1.).
С точки зрения пользователя, оставшееся время - это общее ис-
текшее время (время "elapsed").
Измерения произведены на следующих системах:
- Sun 4/65 под SunOS 4.1, используемой как клиент;
- Sun 4/330 под SunOS 4.1, используемой как сервер;
- HP 9000/375 под HP-UX 7.0, используемой как сервер.

В главе 3, параграф 3.1, мы оговаривали разницу между терми-
нами "buffer" и "tampon".

Произведенные измерения
-----------------------

На рисунках 13.1 и 13.2 показаны:
- по оси ординат: скорость обмена информацией в килобайтах
/сек.
- по оси абсцисс: следующая используемая связь:
- FIFR: именованный канал, используемый с RFS (тестировался
только на Sun);
- STD: сокет UDP в режиме дейтаграммы;
- STC: сокет TCP в режиме виртуального канала;
- STDX: сокет UDP в режиме дейтаграммы с XDR;
- STCX: сокет TCP в режиме виртуального канала с XDR;
- TLI: Transport Level Interface
(тестировался только на Sun);
- RPCD: RPC с UDP;
- RPCC: RPC c TCP.

Рисунок 13.1 Технические характеристики для буфера размером
1024 байт.

+ Sun клиент и Sun сервер - Sun клиент и HP сервер

Кбайт/сек.

500 +
450 +
400 +
350 +
300 +
250 +
200 +
150 +
100 +
50 +
0 +
L-------+------+-------+-------+------+-------+-------+
FIFR STD STC STDX STCX TLI RPCD RPCC


13.2 Технические характеристики для буфера размером 2000
байт.

+ Sun клиент и Sun сервер - Sun клиент и Sun сервер

Кбайт/сек.

700 +
600 +
500 +
400 +
300 +
200 +
100 +
0 +
L-------+------+------+-------+-------+------+--------+
FIFR STD STC STDX STCX TLI RPCD RPCC

Влияние размера буфера (buffer) на производительность
-----------------------------------------------------

На рисунке 13.3 показано влияние размера буфера обмена на
технические характеристики (измерения произведены для двух ма-
шин Sun).
Расшифровка аббревиатур показана в предыдущем параграфе.

+
Рисунок 13.3 Технические характеристики IPC в зависимости от
размера буфера обмена.

STD STC TLI RPCD RPCC

Кбайт/сек.

2000 +
1800 +
1600 +
1400 +
1200 +
1000 +
800 +
600 +
400 +
200 +
0 +
L-----+------+------+-------+-------+-------+-------+
1 128 512 1024 2000 3000 4000 8000


Влияние размера буфера (tampon) TCP
-----------------------------------

По умолчанию объем буферов TCP составляет обычно 4 Кбайта.
Возможно изменение объема программными средствами. Так, для
сокетов, можно использовать примитив setsockopt ().
На рисунке 13.4 показаны технические характеристики, полу-
ченные в зависимости от объема буфера обмена (ось абсцисс) и
объема буферов (tampon) TCP (ось ординат). Этот тест был вы-
полнен для двух машин Sun в сети Ethernet.

Рисунок 13.4 Технические характеристики сокетов в зависимос-
ти от объема буферов TCP.

Объем буферов TCP 2048 4096 8192 16384

Кбайт/сек.

1200 +
1000 +
800 +
600 +
400 +
200 +
0 +
L-----+------+------+-------+-------+-------+--------+
1 128 512 1024 2000 3000 4000 8000


Заключение
----------

Сокет-интерфейс, даже комбинированный с XDR, несколько эф-
фективнее, чем RPC, особенно для буферов с малым объемом,
которые более чувствительны к дополнительной обработке RPC.
Полезно использовать механизмы , обеспечивающие буферизацию
(tampon).
Что касается буферов TCP, то улучшение технических характе-
ристик при объеме свыше восьми килобайт является второстепен-
ным (между двумя машинами Sun, в сети Ethernet).


13.3. ВЫБОР АРХИТЕКТУРЫ

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

13.3.1. Архитектура 1: прикладная программа на рабочей стан-
ции

Прохождение программы управляется с рабочей станции
(рис.13.5).
Сложная обработка осуществляется на сервере обработки с ис-
пользованием RPC.
Диалог с пользователем опирается на X Window и такие утили-
ты, как Motif. Изображения создаются с помощью GKS (2D), PHIGS
(3D) или другой графической библиотеки. Данные либо локальные,
либо доступ к ним осуществляется с помощью NFS или SQL.
Целью этого типа архитектуры являются прикладные программы,
располагающие пользовательским вычисленным интерфейсом и выра-
батывающие многочисленные графические изображения, использую-
щие сложную обработку.


г===========================¬
¦ сервер обработки ¦
¦ -----------------------¬ ¦
¦ ¦ подпрограмма ¦ ¦ г=================¬
¦ ¦ обработки ¦ ¦ ¦ --------------¬ ¦
¦ L----------------------- ¦ ¦ ¦ данные ¦ ¦
L==============¦============- -> ¦ L-------------- ¦
^ ¦ ¦ L=================-
¦ ¦ --------
RPC ¦ ¦ RPC ¦ локальные данные, вызов ¦ ¦ возврат v NFS
или утилиты SQL
г=========¦====¦============¬
¦ -------------v----------¬ ¦
¦ ¦ прикладная программа ¦ ¦
¦ +-----------------------+ ¦
¦ ¦ X11 ¦ ¦
¦ ¦ (сервер и клиент) ¦ ¦<-----------> КОМПЬЮТЕР
¦ L------------------------ ¦
¦ рабочее место ¦
L===========================-
Рисунок 13.5 Архитектура 1: прикладная программа на рабочем
станции.


13.3.2. Архитектура 2: прикладная программа на сервере обрабо-
тки.

Программа управляется сервером обработки (рис. 13.6). Как и
в предыдущем случае, диалог с пользователем осуществляется
через X Window и такие утилиты как Motif. Графические изобра-
жения создаются с помощью PEX или с помощью распределенной
графической библиотеки, такой как библиотека DGL.
Доступ к локальным данным осуществляется или через NFS или
через продукт SQL.
Целью такой архитектуры являются прикладные вычислительные
программы с интерактивным контролем выполнения.


г============================¬
¦ сервер обработки ¦ локальные данные г============¬
¦ ¦ или NFS или ¦-----------¬¦
¦ -------------------------¬ ¦ утилиты SQL ¦¦ данные ¦¦
¦ ¦ прикладная программа ¦ ¦ <----------------> ¦L-----------¦
¦ +-----------T------------+ ¦ L============-
¦ ¦ PHIGS ¦ Motif ¦ ¦
¦ +-----------+------------+ ¦
¦ ¦ X11/PEX (клиент) ¦ ¦
¦ L------------------------- ¦
L============================-
^
¦
v
г============================¬
¦ -------------------------¬ ¦
¦ ¦ ¦ ¦
¦ ¦ X11/PEX ¦ ¦
¦ ¦ (сервер) ¦ ¦
¦ ¦ ¦ ¦ <-----------------> КОМПЬЮТЕР
¦ L------------------------- ¦
¦ ¦
¦ рабочее место ¦
L============================-
Рисунок 13.6 Архитектура 2: прикладная программа на серве-
ре обработки.


13.4. СОВЕТЫ

13.4.1 Выбор архитектуры.

Выбор архитектуры в основном зависит от типа прикладной
программы:
- если программа осуществляет большой об'ем интенсивной об-
работки, применяется второй тип архитектуры;
- если программа в основном графическая, больше подходит
первый тип архитектуры (графические построения осуществля-
ются более эффективно на рабочей станции).

В настоящее время второй тип архитектуры страдает, во всяком
случае по отношению к трехмерным графическим средствам,отсутс-
твием продуктов PEX. Альтернативные решения могут привести к
проблемам в совместимости и даже в обслуживании. В любом слу-
чае эта архитектура привлекательна для некоторых графических
прикладных программ, которые могут быть распределены без моди-
фикации кода прикладной программы. Распределение осуществляет-
ся графической библиотекой.
Кроме этих функциональных критериев, выбор архитектуры может
зависеть и от других факторов:
- возможность продолжения выполнения прикладной программы на
рабочем месте в случае,если сервер или сеть неисправны;
- скорость передачи информации, если сервер находится на
удалении;
- стоимость использования прикладной программы, если время
CPU (Central Processing Unit - Центральный Процессор) сер-
вера обработок или занятость диска сервера данных включены
в расчеты.
Эти перечисленные критерии делают первый тип архитектуры бо-
лее привлекательным. Ее мы и рассмотрим в первую очередь.


13.4.2. Внедрение прикладной программы.

Концепция
---------

Необходимо уделить особое внимание обработке данных: мы рас-
полагаем двумя раздельными адресными пространствами, прост-
ранством сервера и пространством клиента. Это приводит к
следующему:
- использование указателей неэффективно: при передаче указа-
теля на удаленную процедуру, данные, к которым обращен
указатель, также передаются;
- глобальные данные передаются через сеть. Это касается ста-
тических данных, которые можно передать один раз в процесс
выполнения фоновой задачи. Это касается и динамических
данных, которые следует передавать при каждом изменении.

Управление ошибками может быть затруднено. В распределенной
прикладной программе появляются новые источники ошибок:
- сеть может выйти из строя или переполниться на короткое
время;
- сервер может остановиться или переполниться на короткое
или долгое время;
- уровни программного обеспечения являются дополнительным
источником ошибок.

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

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

Без изложения критериев, рассмотренных в параграфе 13.2,
можно сказать, что RPC представляют собой наиболее предпочти-
тельное средство при внедрении распределенной прикладной прог-
раммы, если только не говорить об механизмах более высокого
уровня. Действительно, RPC обеспечивает более высокий уровень
абстрагирования, по отношению к сети, чем интерфейс сокет или
TLI.
RPC Sun более распространены, во всяком случае сейчас, чем
NCS, за развитием и распространением которых нужно внимательно
следить.


13.5. ЗАКЛЮЧЕНИЕ

В настоящее время возможно конструирование распределенных
прикладных программ . Можно опираться на утилиты и услуги TCP/
IP (в ожидании утилит и услуг OSI).
При использовании утилит возможны две архитектуры:
- прикладная программа на рабочей станции и использование
RPC для распределения сложных обработок на удаленных уста-
новках;
- прикладная программа на сервере обработок и интерфейс
пользователя и графических изображений на рабочей станции.
В обоих случаях, пользователь видит только рабочее место и
одну прикладную программу; доступы к сети прозрачны.

Необходимо принимать во внимание существование утилит и воз-
можность их интегрирования при разработке прикладной программы
так, чтобы оптимизировать использование ресурсов в окружении
сети. Все более быстрое развитие средств связи, таких как FDDI
(Fiber Distributed Data Interface ) способствует этому процес-
су. Напомним, что поставленная цель проста: сделать использо-
вание более удобным, улучшить технические характеристики и
функциональные возможности прикладных программ выбором наибо-
лее подходящего для данных и обработок процессора.

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

Обновлено: 12.03.2015