А. И. Савельев, Оптимизация алгоритмов распреде- в е

3. Описание функций взаимодействия клиентской и сервер-ной частей приложения видеоконференцсвязи. Обработка и вывод аудио- и видеоданных – один из самых ресурсоемких процессов для любого устройства. В случае с приложениями видеоконференцсвязи процесс обработки и вывода усложняется тем, что аудио- и видеопото-ки не хранятся на устройстве, а постоянно поступают с сервера, тем самым, увеличивая нагрузку на устройство, которое их принимает. Так как мобильные устройства располагают весьма ограниченными ресур-сами для обработки и вывода данных, а стационарные компьютеры и ноутбуки обычно выполняют одновременно несколько приложений, то для уменьшения нагрузки на клиентскую часть приложения, комплекс функций, отвечающих за распределение и фильтрацию мультимедий-ных потоков, был перенесен на серверную часть приложения. Далее рассмотрим классы, необходимые для фильтрации и распределения аудио- и видеопотоков.
Для серверной части приложения был создан класс, отвечающий за распределение и фильтрацию потоков – «ControlConnections», кото-рый применяет два вспомогательных класса: «User» и «ClientStream». Класс «User» отвечает за создание пользователя, который является прототипом клиентской части приложения на сервере. Данный класс хранит внутри себя информацию: о пользователях, которые подключе-ны к нему, информацию о потоках, которые поступают от других пользователей и информацию о собственных потоках, которые исхо-дят из клиентского приложения. Экземпляр класса «ClientStream» со-здается при поступлении нового аудио- и видеопотока данных от кли-ента на сервер и содержит: имя пользователя, которому принадлежит данный поток, собственное имя и массив, в котором содержатся имена пользователей подключенных к данному потоку.
Созданием и удалением экземпляров классов «User» и «Client-Stream» занимается класс «ControlConnections». Также класс «Control-Connections» содержит ряд функций, с помощью которых осуществля-ется: выбор нужных потоков, фильтрация потоков, рассылка потоков, удаление потоков, поиск пользователя, подключение к пользователю, удаление пользователя. Это далеко не весь ряд функций, которые со-держатся в классе, но эти функции играют основную роль в оптимиза-ции архитектуры клиент-серверного приложения.
В клиентской части приложения всего три класса используются для взаимодействия с сервером: «Registration», «ConnectionVide-oStreams», «CameraStreams». Класс «Registration» служит для проверки логина и пароля пользователя, а также для создания новой учетной

^{Труды СПИИРАН. 2013. Вып. 8(31). ISSN 2078-9181 (печ.), ISSN 2078-9599 (онлайн)} 67 SPIIRAS Proceedings. 2013. Issue 8(31). ISSN 2078-9181 (print), ISSN 2078-9599 (online)
www.proceedings.spiiras.nw.ru
записи пользователя в базе данных сервера. Класс «ConnectionVide-oStreams», отвечает за прием новых потоков аудио- и видеоданных и их вывод на дисплей устройства. Последний класс взаимодействия с серверной частью приложения «CameraStreams» формирует и отправ-ляет аудио- и видеопотоки данных с камер и микрофонов устройства на сервер.
В таблице 3 представлены основные этапы взаимодействия сер-верной и клиентской частей приложения видеоконференцсвязи с ис-пользованием функций вышеперечисленных классов. Нужно отметить, что каждый этап может повторяться при условии, что приложение вы-полнило предыдущий этап успешно и связь между сервером и клиен-том установлена.
Таблица 3. Основные этапы взаимодействия клиентской и серверной частей приложения

№ этапа


UML диаграмма взаимодействия Описание

1

2

68
Происходит подключе-ние клиентской части приложения к сервер-ной части, создание нового экземпляра класса «User» и запол-нение данными экзем-пляра класса «User».

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

Труды СПИИРАН. 2013. Вып. 8(31). ISSN 2078-9181 (печ.), ISSN 2078-9599 (онлайн) SPIIRAS Proceedings. 2013. Issue 8(31). ISSN 2078-9181 (print), ISSN 2078-9599 (online) www.proceedings.spiiras.nw.ru

№ этапа


UML диаграмма взаимодействия Описание

3

4

5

6
Обработка потока дан-ных в серверной части: создание нового экзем-пляра класса «Client-Sttream», занесение данных о потоке – имя потока, имя владельца потока, поиск других пользователей, под-ключенных к владельцу потока.

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

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

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

^{Труды СПИИРАН. 2013. Вып. 8(31). ISSN 2078-9181 (печ.), ISSN 2078-9599 (онлайн)} 69 SPIIRAS Proceedings. 2013. Issue 8(31). ISSN 2078-9181 (print), ISSN 2078-9599 (online)
www.proceedings.spiiras.nw.ru

№ этапа


UML диаграмма взаимодействия Описание

Отправка сформиро-7 ванного массива пото-
ков пользователю.

Обработка и отображе-8 ние пришедшего масси-
ва потоков.

На основе описанных в таблице 3 этапов работы клиентской и серверной частей приложения можно выделить два основных алгорит-ма взаимодействия: подключение потока данных от клиента и пере-сылка потока данных другим пользователям. Алгоритм обработки по-токов при первом взаимодействии устройств, изображенный на рисун-ке 1, включает в себя 2 и 3 этапы таблицы 3. Действия, происходящие в ходе алгоритма, необходимы для учета всех данных о потоке в сер-верной части приложения, упрощения дальнейшего взаимодействия между пользователями и увеличения скорости обмена информацией между ними. Второй алгоритм взаимодействия, основанный на этапе 4 таблицы 3 и представленный на рисунке 2, отображает систему рас-пространения потока. Все действия второго алгоритма происходят в серверной части приложения, тем самым освобождая клиентскую часть от нагрузки при нахождении еще не добавленных потоков. Дру-гая положительная сторона этого алгоритма – это отсутствие обмена данными между клиентами для определения еще не добавленных по-токов, все необходимые данные уже существуют на сервере и время выполнения алгоритма очень мало, благодаря отсутствию обмена дан-ными с клиентами.

70 ^{Труды СПИИРАН. 2013. Вып. 8(31). ISSN 2078-9181 (печ.), ISSN 2078-9599 (онлайн)} SPIIRAS Proceedings. 2013. Issue 8(31). ISSN 2078-9181 (print), ISSN 2078-9599 (online)
www.proceedings.spiiras.nw.ru

Рис. 1. Алгоритм создания нового потока

Рис. 2. Алгоритм распространения потока

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

^{Труды СПИИРАН. 2013. Вып. 8(31). ISSN 2078-9181 (печ.), ISSN 2078-9599 (онлайн)} 71 SPIIRAS Proceedings. 2013. Issue 8(31). ISSN 2078-9181 (print), ISSN 2078-9599 (online)
www.proceedings.spiiras.nw.ru
ство задействованных ресурсов. Так как весь функционал и объекты манипуляций этих цепочек содержатся на сервере, то это снижает вре-мя для обмена данными между клиентскими частями и значительно уменьшает нагрузку на них.
Цепочки взаимодействия клиентов и сервера позволяют так же быстро удалять потоки и пользователей, как и формировать их. Это способствует ускорению освобождения ресурсов устройств, необхо-димых для обработки других данных. Основные этапы по удалению потоков представлены в таблице 4.

Таблица 4. Основные этапы удаления потоков от пользователей

№ этапа

1

2

3

UML диаграмма взаимодействия

: ControlConnections
"call" SearchClientStream (StreamName:String)
DeletingStream : ClientStream "call" GetConnectionUsers()

ArrayConnectionFriends:String[]

Описание

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

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

4

72

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

Труды СПИИРАН. 2013. Вып. 8(31). ISSN 2078-9181 (печ.), ISSN 2078-9599 (онлайн) SPIIRAS Proceedings. 2013. Issue 8(31). ISSN 2078-9181 (print), ISSN 2078-9599 (online) www.proceedings.spiiras.nw.ru

№ этапа


UML диаграмма взаимодействия Описание

5
Удаление потока и его отображения на клиентской части приложения.

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

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