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


Чтобы посмотреть этот PDF файл с форматированием и разметкой, скачайте его и откройте на своем компьютере.
Московский государственный университет им. М. В. Ломоносова

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










Магистерская диссертация


Модель взаимодействия

с многоресурсными
приложениями

на основе видеопотока







Работу выполнил
:

студент
Астах
ов А
ндрей
Н
иколаевич


Научный руководитель:

доцент, к.ф.
-
м.н.

Абрамов В
ладимир
Г
енна
дьевич






г. МОСКВА

201
3


2

1. Аннотация

________________________________
______________

3

2. Введе
ние

________________________________
________________

4

3. Постановка задачи

________________________________
_______

6

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

_______________________

7

4.1. Существующие аналоги

________________________________

7

4.2. Методы построения кластеров

__________________________

12

4.3. А
рхитектура систем распределенных вычислений

_________

15

4.4. Методы кодирования видеопотока

_______________________

17

4.5. Основные алгоритмы балансировки нагру
зки

_____________

20

4.6. Методы создания клиентских приложений

________________

24

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

______________________

26

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

______________________

30

6
.1
.

Python

________________________________
______________

30

6
.2
.

Twisted

________________________________
______________

31

6
.3
.

HTML5

и
JavaScript

________________________________
___

34

6.4.
Реализация кластера

________________________________
__

37

6.5. Реализация серверного многоресурсного приложения

______

39

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

_____

44

8. Заключение

________________________________
____________

47

9. Список используемой литературы

________________________

48


3

1.

Анно
тация

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

ресурсов, чем имеется у
пользователя.

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

Тако
й подход
непригоден

если

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

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

таком случае является
стабильное высокоскоростное Интернет
-
соединение и компьютер с
характеристиками достаточными для декодирования поступающего
видеопотока[1]
.


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

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


4

2.
Введение

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


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

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

удаленного администрировани
я.

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

В ответ
пользователь получает т
олько видеопоток
.

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

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

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

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

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




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



Файловые устройств
а это файлы,
каталоги

и

вся файловая система.



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


5

Особый вид ресурсов представляют собой сетевые ресурсы.
Это
аппаратные, файловые и программные ресурсы других

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


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


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

(
ко
дировщик
-
дек
одировщик)

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

[
2
]
.

С развитием кодеков уве
личивалась скорость кодирования. На момент
написания работы, существуют аппаратные чипы, позволяющие сжимать видео
с разрешением до 1920х1080

для передачи в реальном времен
и.
Также широко
распространены чипы, работающие с разрешением 1280х720. Обычно они
используются для охранных камер и работают с
частотой 30 кадров в
секунду[
3
]
.

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

кл
иентскому прило
жению

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

видеопотока
.


6

3.
П
остановка задачи

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

и
реализация

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

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

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

производят
операции

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

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

М
одель

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

видеопотока

имеет не
сколько ключевых характеристик:



П
риложения

не
зависят

от ресурсов пользователей.

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



Изменение

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

не затрагива
ет

пользователей. У пользователей не
должно быть

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



Реализована

возможность

балансировк
и

нагрузки на сервер.



Аппаратная часть мод
ели
состоит

из модулей
,

к
аждый
из которых
отвечает за в
ыполнение к
онкретной подзадачи.



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

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



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

и балансировку нагрузки
.


7

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

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

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



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

с приложениями на основе

в
идеопотока



построение

кластера



выбор архитектуры

вычислительной системы



кодир
ование и декодирование

видеопотока



балансировк
а

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


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

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

4.
1
.

Сущ
ествующи
е

аналог
и


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

приложениями.


OnLive

-

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

Весь процесс работы с системой OnLive проходит через веб
-
браузер.
Через Интернет
-
соединение на сервер отправляется информация о действиях
пользователя (нажатие клавиш, движения мышью и

т.

д.). Далее сервер в

8

соответствии с эти
ми данными генерирует видео
-

и аудиопоток. При этом само
приложение исполняется на стороне сервера. Далее с помощью специального
видео кодека видеопоток проходит компрессию в режиме реального времени,
причѐм за сжатие отвечает специальный аппаратный чип со
бственной
разработки OnLive. После сжатия видеопоток отправляется через Интернет
-
соединение пользователю. Вместе с видеопотоком передаются и аудиоданные.
После поступления видеопоток декодируется в реальном времени и
отображается в веб
-
браузере. Центральны
й процессор на локальном
компьютере пользователя должен быть достаточно мощным, чтобы проводить
декодирование в реальном времени.



Рис.1

Схема

работы

сервиса
OnLive


Аппаратные средства сервера состоят из стандартных центральных и
графических процессоров
, а также из чипа собственной разработки OnLive,
который предназначен для аппаратного кодирования поставляемого
пользователям видеопотока в реальном времени с помощью

видео кодека
разработки OnLive
[1]
.

Отличительной особенностью

сервиса
OnLive

является то
,

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

9

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

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

Соединение со скоростью 5 мегабит в секунду обеспечивает стабильный
видеопоток с разрешением 1280х720 пикселей, 60 кадров в секунду, с
задержкой 150 миллисекунд. Разрешение 7
20х480 треб
ует всего 1.5 мегабит в
секунду

[1]
[4
]
.

П
рограммы удаленного администрирования, такие как
TeamViewer
и
Radmin
,
так же

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



Рис. 2 Схема
работы программ удаленного администрирования



10

Программы удаленного администрирования имеют менее жесткие
требования к скорости соединения

за счет специфического видеопотока.
Пользователю посылаются только те части изображения, которые изменились
со времени прошлой отправки. В случае с
OnLive
это менее эффективно, но при
пересылке видеопотока с некими действиями с графической оболочкой
опера
ционной системы это позволяет снизить требования к скорости
соединения до 500 килобит в секунду

для разрешения
1920x1080

[5
]
.

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

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

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

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

Сервисы потокового вещания видео

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



Рис. 3 Схема работы сервисов потокового вещания видео



11

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

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

К
лиентские устройства декодируют
видеопоток

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


Тип
видеопотока

р
азрешение

-

кадры в секунду

Требуемая скорость соединения (килобит в секунду)

Низкое
к
ачество

Высокое
качество

Высшее
качество

360
p

-

25

500

800

1200

480
p
-

25

750

1400

1900

480
p
-

30

1000

1500

2250

720
p

-

30

2000

3000

4500

720
p
-

45

2500

3750

5500

720
p
-

60

3000

4500

6500

1080
p
-

30

3200

6000

9000

1080
p
-

45

4200

7000

11000

1080
p

-

60

5500

8000

14000


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

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

[6]
. Это позволяет добиться того, что каждое

12

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

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

по миру

[
7
]
.

Средняя скорость составляет 13 мегабит в се
кунду на март 2013, что более чем
достаточно для стабильной передачи 60 кадров в секунду с разрешением
1280х720 пикселей. Минимальной средней скоростью по странам на март 2013
является 860 килобит в секунду, что достаточно для задач, не требующих
частого о
бновления всего изображения.

4
.
2
.

Методы

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

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

[
8
]
.

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

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

Грид
-
система это
географически распределѐнная инфраструктура, объединяющей множество
ресурсов разных типов (процессоры, долговременная и оперативная память,
хранилища и базы данных, сети), доступ к которым пользователь может
получить из люб
ой точки, независимо от места их расположения
. Главным
и

недостатк
ами

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



13


Рис.
4

Общая схема кластера


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

Есть три основных в
ида отказоустойчивых кластеров: [
8
]



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



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



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


14

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

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

данные со скоростью,
превышающей
1 гигабит в секунду

[
8
][
9
]
.


Одним из решений проблемы построения кластера является кластер типа
Beowulf.
Так называют кластеры, которые состоят из широко
распро
страненного аппаратного обеспечения,
работающие под управлением
операционной системы
с открытыми исходными кодами.

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

Узлами
кластера
Beowulf
могут быть любые серийно выпускаемые автономные
компьютеры под управлением, например,
Linux
или
FreeBSD.

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

технология интерфейса передачи сообщений (
Message
Passing Interface, MPI).

MPI
представляет собой программный интерфейс (
API)
для передачи информации, который позволяет
процессам обмениваться
сообщениями.
В частности,
MPI

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

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

и языков
программирования
[10
]
[
11
]
.


15


Кластеры
Beowul
f
обладают следующими преимуществами:



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



Низкая сложность создания системы.



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



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



Широкая распространенность и доступность необходимого
аппаратного обеспечения.

Таким образом,
концепция
Beowulf
позволяет организовывать
кластер с
помощью
широко распространенного аппаратного обеспечения.

Низкая
сложность

организации кластера
Beowulf
делает его
подходящим д
ля

разработки в учебных целях.

4
.
3
.

А
рхитектур
а

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

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

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

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

[8
]
.



16


Рис.
5

Схема архитектуры с распределенной памятью


Такая архитектура имеет несколько недостатков, которые критичны для
эффективной реализации рассматриваемой модели:



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



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



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

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

работает множество процессоров

[
8
]



17


Рис.
6

Схема
архи
тектуры с разделяемой памятью


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

4
.
4
.

Методы

кодирования видео
потока

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

Все кодеки можно разделить на две
категории: программные

и аппаратные.


18

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

для обработки
видеопотока
:



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



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

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



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

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

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

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

[1
2
]
.



19


Рис.
7

Схема работы м
ногоядерных кодеков


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

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

процессорах,

п
онижая их эффективную
мощность.


В случае аппаратных кодеков, кодирование происходит с пом
ощью
специального чипа.
Есть несколько типов аппаратных кодеков:



Кодеки типа
Acceleration
(ускорение)
представляют собой
гибридное решение.
Такие кодеки состоят из двух частей

-

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



Кодеки, основанные на программируемых пользователем матрицах
(
Field
-
P
rogrammable
G
ate
A
rray
, FPGA)

выполняются на отдельном

20

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

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

[13
].



Кодеки, основанные на
интегральных схемах для специфического
применения
(
A
pplication
-
S
pecific
I
ntegrated
C
ircuit
, ASIC
)
так же
выполняются на отдельном устройстве.
Этот подход отличается
тем, что
используемый устройством кодек
невозможно
изменить
[1
4
]
.


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

выбран
ы
программные многопроцессорные кодеки и
аппаратные кодеки на основе
FPGA.
Эти кодеки предоставляют
возможность
кодирования
видеопотока раз
решением 1920х1080 30 кадров в секунду при
простоте разработки и

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

4
.
5
.

Основные алгоритмы

балансировки нагрузки

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

алгоритмов
балансировки нагрузки
ме
жду узлами
системы:



Случайный

алгоритм

-

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

все еще

могут о
казаться
перегруженными.

1.

Появляется задача

2.

Выбирается случайный модуль

3.

Задача отправляется на выбранный модуль

4.

Ожидается новая задача


21

5.

Выполнение продолжается

с пункта 1



Циклический
алгоритм
-

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

1.

Формируется очередь модулей

2.

Появляется задача

3.

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

4.

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

5.

Ожидается новая задача

6.

Выполнение продолжается с пункта 2



Взвешенный циклический

алгоритм

-

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

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

1.

Формируется очередь модулей

2.

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

3.

Появляется задача

4.

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

5.

Если
ресурсоемкость

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

6.

Ожидается н
овая задача

7.

Выполнение продолжается с пункта 3


22



Динамический циклический

алгоритм

-

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

1.

Формируется очередь модулей

2.

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

3.

Появляется задача

4.

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

5.

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

6.

Ожидается новая задача

7.

Выполнение продолжается с пункта 2



Алго
ритм минимального количества задач
-

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

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

1.

Формируется очередь модулей

2.

Появляется задача

3.

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

4.

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

5.

Ожидается новая задача


23

6.

Выполнение пр
одолжается с пункта 2



Алгоритм быстрейшего ответа
-

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

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

быстрейшего ответа

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

в
реальном времени
.

1.

Появляется задача

2.

Опрашиваются все модули

3.

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

4.

Ожидается новая задача

5.

Выполнение продолжается с пункта 1

После изучен
ия

достоинств

и недостатков

основных алгоритмов
балансировки нагрузки

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

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

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

наряду со
старыми узлами.

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

[1
5
]
[1
6
].


24

4.6. Методы создания клиентских приложений

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

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

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

обраб
отки
потока команд пользователя
.

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

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

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

Каждый

из них имеет
свои достоинства и недостатки.

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

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

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

и многоресурсным приложением

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


Недостатком таких

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

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

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

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


25

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

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

веб
-
браузеров и удобств
у

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

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



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



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



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




26

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

В модели

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

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

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



Рис.
8

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


Модель

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

Клиентская и серверная части
соединены через сеть.

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



Отправка
потока ком
анд пользователя

на сервер



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



Декодирование видеопотока



Отображение видеопотока

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

Для

27

реализации сообщений можно использовать любой формат
.

Например,

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

Декодирование
видеопотока и отображение

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

вне зависимости от
имеющихся программных ресурсов.

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

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



Управляющи
е модули отвечают

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

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

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

и распределение задач меж
ду
модулями.



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

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



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



28


Рис
.

9

Модульная схема модели
взаимодействия с

многоресурсными

приложениями

на основе видеопотока


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

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

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

[1
7
]
.

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

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

Например, прирост

29

производительности при кодировании видео с использованием графического
процессора составил 360 процентов в сравнении с процессоро
м средней
мощности на 2011 год

[1
8
]
.

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

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

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

Благодаря тому, что все данные находятся на сервере, станут
невозможными различные несанкционированные операции с ними со стороны
пользователей. Это может использоваться как защи
та от использования
недокументированных функций и операций с файлами.

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

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

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

физи
чески
е
,
химические, атмосферные процессы
.

На основе
модели

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

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

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



30

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

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

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

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

выход в интернет и поддерживающих
HTML5.

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

и
JavaScript
.

6
.1
.

Python

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

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

Python
поддерживает неско
лько
парадигм программирования, таких как объектно
-
ориентированное
,
структурное
, императивное и функциональное программирование.

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

Код организовывается в
функции и классы, которые затем могут

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

[
19
].

Несмотря на простоту синтаксиса,
Python
имеет множество библиотек,
расширяющих его
возможности.
Стандартная
библиотека
Python
включает

31

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

Python
также име
ет множество сторонних модулей,

пакетов

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

[
20
]
.

Python
портирован на мн
ожество
платформ.
Существует

Python
для
Windows,
практически всех вариантов
UNIX, Mac OS, Mac OS X, iPhone OS,
Palm OS, OS/2, Amiga, Plan 9, Windows Mobile, Symbian
и
Android.

Для всех
платформ
Python
имеет поддержку характерных для них технологий. Наприме
р,
Python
для
Windows
поддерживает

стандарт

Component Object Model

от
Microsoft
.

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

Существуют проекты, о
беспечивающие интеграцию
Python
с платформой
Microsoft .NET

[
21
].

6
.2
.

Twisted

Twisted
это событийно
-
ориентированный сетевой каркас

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

(
framework)
,
написанный на
Python.
Twisted
работает с

TCP, UDP, SSL,
Также в
Twisted
имеется поддержка множества
протоколов, таких как
HTTP, XMPP, NNTP, IMAP, SSH, IRC, FTP.

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


32

Приложения использующие
Twisted
работают с помощью так называемых
отложенных (
deferred)

вызовов

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

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

[2
2
]
.

Таким образом, механизм отложенным вызовов позволяет
оперировать
результатом
работы функции до того, как
этот результат
ста
новится доступен.
Например, если отложенный экземпляр возвращает
IP
адрес

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

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

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

Таким образом, с помощью обрат
ных вызовов и ошибочных обратных
вызовов

можно описать
работу системы при
появлении асинхронных событий.
Более того, при использовании функций обратного вызова
пропадает
необходимость
останавливать работу системы и ждать события.
По этой
причине
Twisted
яв
ляется
событийно
-
о
риентированным сетевым каркасом

[2
3
]
.


33

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



Гибкость. К
одовая база
Twisted
мала, но
открытый код

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

его
собственны
ми функциями
.



Безопасность
.
Twisted
написан на
Python,
который является языком
программирования высокого уровня.
Это предохраняет приложения
от
некоторых низкоуровневых
ошибок,
например,
переп
олнени
я

буфера.

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



Стабильность.
Twisted
исполь
зует механизмы обработки ошибок,
существующие в
Python.
Это позволяет добиться высокой
ст
абильности
[2
4
].

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

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

Также, используя систему отложенных вызовов можно описать
процесс
общей обработки
команд
как отложенных объектов.




34

6
.
3
.

HTML5

и
JavaScript

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

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

при сохранении

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

Важными синтаксическими нововведениями являются элементы
videov4i;&#x-3d4;o-4;
и
audio u4d;i-3;&#xo400;.
Они позволяют
легко подключать и обрабатывать
видео и аудио
содержимое

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

[2
5
].

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

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

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

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

без
установки стороннего программного об
еспечения
.
Формат
Ogg Theora
поддерживается
большинством веб
-
браузеров, но
и
Safari

требуют установки
дополнительного набора кодеков

[
2
6
]
.

Несмотря на это,

HTML5
позволяет избежать

проблем с совместимостью.

Э
лемент
videov-3;&#xi4d-;Ϩo;&#x-300;
имеет поддержку

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


35

Ещ
е одним важным элементом, появившемся в
HTML5,
является
элемент
canvasÊn3;&#xv-3a;s-3;.

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

JavaScri
pt
это

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

сценарны
й

язык

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

Включая
JavaScript
в
HTML
веб
-
страницы, его можно использовать для
взаимодействия
с объектной моделью документа (
Document Object Model,
DOM).

JavaScript
выполняется на стороне пользователя с помощью веб
-
браузера. В языке пр
исутствуют обработчики нажатий клавиш
. Это

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

для
д
альнейшего

отп
р
авления его на сервер.

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

[2
7
].

С помощью элемент
а
canvasÊn3;&#xv-3a;s-3;
и
языка
JavaScript
появляется возможность
расширить функции клиентского приложения в веб
-
браузере.

Используя
JavaScript
, в веб
-
приложение

можно
ввести обработчики

клавиатуры и мыши
,
которые формируют
поток
команд

пользователя.

Пример использов
ания элемента
canvas࣊n;v4a;&#xs-40;
и языка
JavaScript
для
считывания координат
указателя мыши:


script&#xs-3c;&#xr8i-;p4t;&#x-300;



var rect = canvas.getBoundingClientRect();





x: evt.clientX
-

rect.left,


36



y: evt.clientY
-

rect.top



};


}

var can
vas = document.getElementById('myCanvas');


canvas.addEventListener('mousemove', function(evt) {


var mousePos = getMousePos(canvas, evt);


var message = mousePos.x + ',' + mousePos.y;


send
Message(
server
, message);


}
, false);

/script&#x/-3s;Lri;p4t;&#x-300;



Таким же образом можно обрабатывать
нажатия клавиш.
При
взаимодействии пользователя с элементом
canvasನn;v-3; s40;
создается
сообщение,
содержащее
код
нажатой клавиши или
координаты

указателя

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

пользователя.

Без поддержки языка
JavaScript

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

последних версий

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

при их использовании

[2
8
].

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

устройств

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


37

6.4.
Реализация кластера

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

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

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

Кластер был организован следующим образо
м

[2
9
]
:

1.

На оба узла
кластера
была установлена операционная система на
основе
Linux (Ubuntu 13.04)
.

2.

Узлы

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

были
объединены в
сеть.

3.

IP
адреса узлов кластера были добавлены в
/etc/hosts
файл на
каждом из узлов
.

4.

На узлы кластера был установлен
SSH
сервер, сгенерирован
SSH
ключ.

5.

На узлы кластеры был установлен
MPICH

-

реализация интерфейса
передачи сообщений
MPI.

6.

Определен путь к
MPICH
для
SSH.

7.

В
файл
machines.LINUX
были добавлены имена узлов из

и
коли
чество узлов
.

8.

Кластер был протестирован с помощью примеров программного
обеспечения,
поставлявшихся с
MPICH.



38


Рис
.

10

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

на основе видеопотока относительно созданного кластера


В итоге

бы
л создан учебный кластер из двух портативных персональных
компьютеров с установленной операционной системой
Ubuntu 13.04
,
объединенных в сеть.

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


39

6.5.
Реализация

серверного многоресурсного приложения

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

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

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

Суть моделирования состоит в следующем.

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

двумерные

геометрические
фигуры
.
Н
а каждую частицу
и объект
действуют
физические силы, такие как
сила тяжести, сил
а Архимеда,
давление других частиц и объектов.

Физическое
взаимодействие частиц воды и объектов обрабатывается с помощью
вычислительны
х модулей системы.
Графические модули используются для
отображени
я

положения

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

их основной задачей

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

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

Серверное приложение было создано с помощью языка
программирования
Python
и библиотеки
PyGame
, позволяющей со
здавать
нестандартные графические интерфейсы

и мультимедиа
-
приложения
.

PyGame
также
поддерживает отображение
объектов в реальном времени с
определенной


40

частотой кадров

[30
]
.
Результатом этого отображения и является
видеопоток,
посылаемый пользователю после

кодирования.



Рис.
11

Общий вид серверного многоресурсного приложения


Взаимодействие с программой происходит путем
выбора геометрической
фигуры

с помощью цифровых клавиш

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

пользователя состоит из
сообщений
о
смене вида геометрической фигуры и
координат
X
и
Y
расположения объекта.

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

JSON

(
JavaScript

Object

Notation
)

представляет собой

текс
товый формат
обмена данными, который основан на
JavaScript

и чаще всего используемый

41

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

готовы
е
библиотеки
для создания и обработки
данных в формате JSON. В целом этот язык крайне похож на
XML

(
eXtensible

Markup

Language
, расширяемый язык разметки), но структура
JSON

является
более лаконичной

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

структуры, которые будут просты

для разбора и анализа. Основными

элемент
ами

JSON

являются

пары имя
-
значение или имя
-
массив (набор
значений)

[
3
1
]
.

Сообщение с командой пользователя
имеет следующий вид:

{




"coordinates
"
:
{



"x":
20
0
,



"y": 500


}

}

Поля
и
coordinates
JSON
сообщения заполняются
с помощью

JavaScript

обработчиков клавиатуры и мыши
, встроенных

в страницу веб
-
приложения
, и элемента
HTML5 canvas쨐&#xn4v-;Ψs;&#x-300;
.

Обработка
JSON
сообщений серверным приложением происходит с
по
мощью модуля
json
стандартной библиотк
и
Python.
Этот модуль позволяет
преобразовывать текстовые файлы сообщений в типы данных
, такие как
словари и списки.

П
ри уменьшении радиуса частиц воды,
увеличивается количество
необходимых вычислений.
Однако,
даже при

увеличении количества частиц
,

модель

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

42

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

В случае

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

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

распределение

задач
обработки частиц
меж
ду узлами
происходит один раз

непосредственно

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

Распределение задач
обработки
объектов
-
геометрических фигур
между
узлами сервера
происходит по

взвешенному циклическому

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



Рис.
12

Распределение
выч
ислений между узлами кластера



43

В процессе моделирования
вызывается метод библиотеки
PyGame
((
x,y))
,
который
возвращает
цвет
пикселя

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

Этот видео файл кодируется и передается на клиентские устройства
в
потоковом режиме.

Одной из особенностей реализации является отсутствие
звука

в
многоресурсном приложении

и, соответственно, отс
утствие звукового потока
.
При необходимости передачи звука, можно воспользоваться модулем
mixer
библиотеки
PyGame.
Звуковой поток можно передавать
в клиентское
приложение отдельно от видеопотока с помощью
тега
HTML5 audioਐu;&#x-3d4;&#xi-3o;䀀.
Это
позволяет
изменять

требован
ия

к
интернет соединению

в реальном времени

путем отключения
и включения передачи звукового потока.


44

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

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

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

моделирования
физических,
химических
, атмосферных

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

Задача

для реализации
должна
характери
зоваться:



Наличием графического вывода
.



Н
еобходимостью
создания многоресурсного приложения.



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

между
узлами
системы
.



Необходимостью модел
ирования в реальном времени
.

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



Затем на платформе
-
кластере создается многоресурсное приложение,
решающее выбранную задачу.
Приложение может создаваться н
а любом языке
программирования, имеющем
библиотеку для работы с графикой.
Библиотека
должна
поддерж
ивать
работу с пикселями.
И
з графического вывода
приложения создается видео

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

45

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

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


Рис. 13
Общий вид клиентского приложения


46

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

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

Общий вид
клиентского приложения в процессе работы представлен на рисунке 13.

Пользователь
переключается между видами геометрических объектов с
помощью ц
ифровых клавиш.

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

Клиентское приложение отображает

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

с одним и тем
же экземпляром

модели

и совместно вносят
изменения в состояние модели
.

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

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

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

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

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

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




47

8.
Заключение

В
магистерской диссертации

получены следующие основные результаты:



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

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



На
основании

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

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



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

для
разработчиков и пользователей
.



48

9.
Список ис
пользуемой л
итератур
ы

[1] OnLive Technical FAQ
,

http://www.onlive.com/support/performance

[
2
] Codecs: Frequently Asked Questions

http://windows.microsoft.com/en
-
us/windows7/codecs
-
frequently
-
asked
-
questions

[
3
]

H.264 Video Codec System
-
on
-
Chip specificati
on

http://www.maxim
-
ic.com/products/video/h.264
-
codecs/

[
4
]
R.
Leadbetter
,

OnLive Latency

-
onlive
-
lag
-
analysis

[
5
] How is TeamViewer so fast?

http://stackoverflow.com/questions/9498877/how
-
is
-
teamviewer
-
so
-
fa
st

[
6
]
Guide to Picking Max Resolution/FPS/Bitrate

http://www.xsplit.com/forum/viewtopic.php?t=13243

[
7

http://www.netindex.com/

[
8
]
Богданов А. Станкова Е. Архитектуры и топологии многопроцессорных
вычислительных систем
, 2004

[
9
] Top 500 Superc
omputers Press Release

http://www.top500.org/static/lists/2011/11/PressRelease201111.pdf

[
10
] FAQ: General information about the Open MPI Project

http://www.open
-
mpi.org/faq/?category=general

[
11
] OpenMP Specifications

http://www.openmp.org/mp
-
documents/Op
enMP3.1.pdf

[
12
] M.
Ghanbari, Standard Codecs: Image Compression to Advanced Video Coding,
The Institution of Engineering and Technology, 2003

[1
3
] H.264 FPGA HD Encoder Comparison

http://hdfpga.blogspot.ru/2009/06/h264
-
fpga
-
encoder
-
comparison.html


49

[
14
]
T
. Levent
-
Levi
,

How to Select the Best Chip for Your Video Coding?

http://blog.radvision.com/voipsurvivor/2009/11/02/how
-
to
-
select
-
the
-
best
-
chip
-
for
-
your
-
video
-
coding/

[
15
]
D. MacVittie,
Intro to Load Balancing for Developers
-

The Algorithms

https://devce
ntral.f5.com/blogs/us/intro
-
to
-
load
-
balancing
-
for
-
developers
-
ndash
-
the
-
algorithms

[
16
] T. Bourke, Server Load Balancing, O'Reilly Media, Inc., 2001

[
1
7] NVIDIA CUDA FAQ

https://developer.nvidia.com/cuda
-
faq

[
1
8] Смирнов М.
Неграфические вычисления на видео
карте (NVIDIA CUDA и
AMD Stream)

http://poisk
-
videokart.ru/article/articles/negraficheskie
-
vychisleniya
-
na
-
videokarte
-
nvidia
-
cuda
-
i
-
amd
-
stream/19.html

[
19
]
David M. Beazley, Python Essential Reference, Addison
-
Wesley Professional,
2009

[
20

[
21
] PyPI
-

the Python Package Index

https://pypi.python.org/pypi

[
22
]
General
Python FAQ

http://docs.python.org/2/faq/general.html

[
23
]
Twisted FAQ

http://twistedmatrix.com/trac/wiki/FrequentlyAsked
Questions

[
24
]

The Twisted Advantage

http://twistedmatrix.com/trac/wiki/TwistedAdvantage

[
2
5
] M. Pilgrim, HTML5: Up and Running, O'Reilly Media, 2010

[
26
] W3C HTML5 Video

http://www.w3schools.com/html/html5_video.asp

[
27
] M. Lassoff, Javascript for Beginne
rs, LearnToProgram Incorporated, 2013


50

[
28
] JavaScript t
ests & Compatibility tables

http://robertnyman.com/javascript/

[
29
]
T. Sterling,

Beowulf Cluster Computing with Linux
,
MIT Press, 2001

[
30
]
W. McGugan, Beginning Game Development with Python and Pygame
: From
Novice to Professional, Apress, 2007

[
31
] Документация JSON

http://json.org/json
-
ru.html



Приложенные файлы

  • pdf 4366607
    Размер файла: 814 kB Загрузок: 0

Добавить комментарий