Sonix

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== Аннотация ======

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

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

====== Введение ======

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

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

Изначально взаимодействие WebSonix с устройствами Sonix+ обеспечивало устройство CChannel. К сожалению протокол, применяемый в CChannel, а так же некоторые особенности устройства, значительно ограничивают скорость работы WebSonix.

Для развития интерфейса Sonix+ тоже потребовалась дополнительная функциональность, а именно создание протокола для обмена данными между 64х и 32х битными модулями Sonix+.

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

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

====== PyChannel ======

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

В качестве базового механизма для проектирования PyChannel подошёл Message-Oriented Middleware.

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

Для обмена данными потребуются следующие виды сообщений:

  * COMMAND - Запрос на выполнение определённых действий на уровне одного физического устройства (управляющего компьютера, или сервера);
  * REPLY - Сообщение с результатом выполнения процедуры (скорее всего данный тип сообщения необходим исключительно для синхронных запросов, а при работе в асинхронном режиме будет более удобным обмениваться данными с помощью команд, так как ожидание ответа вызовет блокировку устройства на время выполнения команды);
  * ERROR - Сообщение с ошибкой, возникшей в процессе выполнения процедуры (повторяет идеологию REPLY, за исключением того, что клиент вместо возвращения данных вызывает исключение);
  * REGISTER - Данное сообщение необходимо прежде всего для составления таблицы маршрутизации, которая содержит в себе указания о том, по какому адресу нужно отправлять сообщения исходя из имени устройства.

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

====== WebSonix ======

Первоначально PyChannel разрабатывался как замена CChannel. Данное устройство должно было значительно увеличить скорость обмена данными между модулями Sonix+ и Websonix.

Основным ограничением CChannel была возможность обработки единовременно только одного запроса от WebSonix. Так как WebSonix делает множество запросов к устройствам Sonix+ при этом некоторые запросы (создание гистограммы спектра с текущими измерениями) могут требовать большого времени (до нескольких минут). В итоге это приводило к длительной загрузке web страниц.

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

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

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

{{ :ru:websonix:pychannelwebsonixstructure.png?600 |}}

====== Передача сообщений между модулями Sonix+ ======

Сейчас в ЛНФ активно развиваются устройства, которые позволяют отображать данные с научной установки для пользователей в высоком разрешении. Чем выше разрешение для отображения информации, тем больше оперативной памяти нужно приложению для работы.

{{ :ru:websonix:tofy_article.png?600 |}}

Программа для отображения данных SpectraViewer отлично работает отдельно от
Sonix+ в 64х-битном режиме. Однако базовый протокол Sonix+ поддерживают работу
только с 32х-битными приложениями, что ограничивает количество используемой
памяти до 2Гб. Это уменьшает максимальное возможное разрешение,
в котором интерфейс Sonix+ может отображать данные, накопленные во время
измерения.

Для обхода данного ограничения было предложено транслировать вызовы из
интерфейса, работающего в режиме 64х-битного приложения через PyChannel в
базовый протокол Sonix+.

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

{{ :ru:websonix:pychannelguistructure.png?600 |}}

====== Хранилище пользовательских файлов ======

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

  * В хранилище пишутся не только данные с результатами измерений, но и результаты тестовых запусков Sonix+;
  * В случае потери связи с хранилищем, пользовательские файлы нужно будет записывать в ручную;
  * Отсутствует возможность создания систем автоматической обработки данных для пользователей.

Для решения данных задач необходимо организовать дополнительный слой обмена
данными между устройствами Sonix+ и хранилищем пользовательских файлов, который
будет контролировать их запись на сервер. В качестве основы для данного уровня
отлично подойдёт PyChannel.

Дальнейшее развитие получило разделение PyChannel на подпрограммы. Дело в том,
что нам требуется модуль для обеспечения обмена данными как на сервере, так и на
управляющем компьютере. Для снижения затрат на разработку серверной части
PyChannel была адаптирована к работе на сервере. Метод обмена данными между
Sonix+, WebSonix и хранилищем был унифицирован путём выделения функций связи с
сервером в отдельную подпрограмму.

{{ :ru:websonix:pychannelstoragestructure.png?600 |}}

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

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

Функции PyChannel востребованы не только на управляющих компьютерах, но и
серверах. 

Таким образом PyChannel:

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