- en
- ru
Это старая версия документа!
# Table of Contents
1. [Аннотация](#orgc4cb4e9) 2. [Введение](#orgda9737f) 3. [PyChannel](#orge982ad2) 4. [WebSonix](#orgfd02e97) 5. [Передача сообщений между модулями Sonix+](#orgfa11657) 6. [Хранилище пользовательских файлов](#org438c8d7) 7. [Заключение](#org7d2d127) 8. [Ссылки](#org1ab13e7)
<a id=«orgc4cb4e9»></a>
# Аннотация
Командный интерфейс Sonix+ позволяет передавать команды и сигналы только в пределах управляющиего компьютера, между 32х битными приложениями и адаптирован исключительно для семейства операционных систем Windows, что значительно ограничивает возможности развития программного комплекса.
Для обхода этих ограничений была разработана программа PyChannel, которая позволяет передавать сообщения между приложениями и устройствами Sonix+, работающими на разных архитектурах, операционных системах и компьютерах.
<a id=«orgda9737f»></a>
# Введение
Одно из направлений развития программного комплекса Sonix+<a href=«#citeproc_bib_item_1»>[1]</a> - создание сервисов для организации удобной работы пользователей.
В качестве таких сервисов были разработаны система удалённого наблюдения за ходом эксперимента WebSonix и хранилище пользовательских файлов.
Изначально взаимодействие WebSonix<a href=«#citeproc_bib_item_2»>[2]</a> с устройствами Sonix+ обеспечивало устройство CChannel. К сожалению протокол, применяемый в CChannel, а так же некоторые особенности устройства, значительно ограничивают скорость работы WebSonix.
Для развития интерфейса Sonix+ тоже потребовалась дополнительная функциональность, а именно создание протокола для обмена данными между 64х и 32х битными модулями Sonix+.
Дальнейшее развитие хранилища пользовательских файлов потребовало дополнительных функций обмена данными с модулями Sonix+.
В качестве решения данных задач был создан PyChannel, который должен обеспечивать связь модулей Sonix+ с разной архитектурой, располагающихся на разных ЭВМ, с разными операционными системами.
<a id=«orge982ad2»></a>
# PyChannel
Разработка PyChannel началась с задачи создания простого способа для обмена сообщениями между процессами, которые могут быть запущены на разных устройствах с разной операционной системой.
В качестве базового механизма для проектирования PyChannel подошёл Message-Oriented Middleware<a href=«#citeproc_bib_item_3»>[3]</a>.
За реализацию функций маршрутизации и трансформации сообщений при передаче их между устройствами будет отвечать брокер сообщений. В качестве возможностей для реализации больше всего выделяется ZeroMQ<a href=«#citeproc_bib_item_4»>[4]</a>, который по сути является библиотекой для обмена сообщениями. ZeroMQ позволяет создать свою систему обмена сообщениями.
Для обмена данными потребуются следующие виды сообщений:
- COMMAND - Запрос на выполнение определённых действий на уровне одного
физического устройства (управляющего компьютера, или сервера);
- REPLY - Сообщение с результатом выполнения процедуры (скорее всего данный тип
сообщения необходим исключительно для синхронных запросов, а при работе в асинхронном режиме будет более удобным обмениваться данными с помощью команд, так как ожидание ответа вызовет блокировку устройства на время выполнения команды);
- ERROR - Сообщение с ошибкой, возникшей в процессе выполнения процедуры
(повторяет идеологию REPLY, за исключением того, что клиент вместо возвращения данных вызывает исключение);
- REGISTER - Данное сообщение необходимо прежде всего для составления таблицы
маршрутизации, которая содержит в себе указания о том, по какому адресу нужно отправлять сообщения исходя из имени устройства.
При этом необходимо отметить, что данная реализация PyChannel не предусматривает асинхронных команд и добавляет большой слой абстракции, который приводит к увеличению времени передачи сообщений.
<a id=«orgfd02e97»></a>
# WebSonix
Первоначально PyChannel разрабатывался как замена CChannel. Данное устройство должно было значительно увеличить скорость обмена данными между модулями Sonix+ и Websonix.
Основным ограничением CChannel была возможность обработки единовременно только одного запроса от WebSonix. Так как WebSonix делает множество запросов к устройствам Sonix+ при этом некоторые запросы (создание гистограммы спектра с текущими измерениями) могут требовать большого времени (до нескольких минут). В итоге это приводило к длительной загрузке web страниц.
Данное ограничение обходится через создание приложения, которое может выполнять несколько запросов одновременно. Для предотвращения спама запросов с большим временем выполнения необходимо ввести ограничения на команды с большим временем выполнения.
Кроме того WebSonix является многопользовательским сервисом, что приводит к ситуациям, когда несколько пользователей могут послать идентичные запросы. Для предотвращения повторяющихся идентичных запросов за короткий промежуток времени (менее секунды), необходимы агрегация и кэширование запросов, предпочтительнее на стороне сервера.
Таким образом получается следующая структура. На стороне WebSonix есть множество клиентов с разных научных установок, которые создают запросы. Все запросы проходят через приложение, которое занимается агрегированием, кешированием и направлением запросов на указанные научные установки. Далее запросы поступают на PyChannel, который выполняет их в отдельном процессе. Результат запроса возвращается клиентам.

<a id=«orgfa11657»></a>
# Передача сообщений между модулями Sonix+
Сейчас в ЛНФ активно развиваются устройства, которые позволяют отображать данные с научной установки для пользователей в высоком разрешении<a href=«#citeproc_bib_item_5»>[5]</a>. Чем выше разрешение для отображения информации, тем больше оперативной памяти нужно приложению для работы.
 с 1024x1024x1000 (4Gb)»)
Программа для отображения данных SpectraViewer отлично работает отдельно от Sonix+ в 64х-битном режиме. Однако базовый протокол Sonix+ поддерживают работу только с 32х-битными приложениями, что ограничивает количество используемой памяти до 2Гб<a href=«#citeproc_bib_item_6»>[6]</a>. Это уменьшает максимальное возможное разрешение, в котором интерфейс Sonix+ может отображать данные, накопленные во время измерения.
Для обхода данного ограничения было предложено транслировать вызовы из интерфейса, работающего в режиме 64х-битного приложения через PyChannel в базовый протокол Sonix+.
В качестве решения данной задачи было предложено воспользоваться возможностями PyChannel, что потребовало значительной доработки программы. Изначально архитектура PyChannel была монолитной, однако для работы с устройствами Sonix+ потребовалась возможность создавать и подключать к PyChannel отдельные программы, так как на разных спектрометрах необходима разная функциональность. Такая структура должна обеспечить необходимую гибкость при адаптации для разных научных установок.

<a id=«org438c8d7»></a>
# Хранилище пользовательских файлов
При эксплуатации хранилища был выявлен ряд недочётов, которые значительно затрудняли его эксплуатацию:
- В хранилище пишутся не только данные с результатами измерений, но и результаты
тестовых запусков Sonix+;
- В случае потери связи с хранилищем, пользовательские файлы нужно будет
записывать в ручную;
- Отсутствует возможность создания систем автоматической обработки данных для
пользователей.
Для решения данных задач необходимо организовать дополнительный слой обмена данными между устройствами Sonix+ и хранилищем пользовательских файлов, который будет контролировать их запись на сервер. В качестве основы для данного уровня отлично подойдёт PyChannel.
Дальнейшее развитие получило разделение PyChannel на подпрограммы. Дело в том, что нам требуется модуль для обеспечения обмена данными как на сервере, так и на управляющем компьютере. Для снижения затрат на разработку серверной части PyChannel была адаптирована к работе на сервере. Метод обмена данными между Sonix+, WebSonix и хранилищем был унифицирован путём выделения функций связи с сервером в отдельную подпрограмму.

Когда речь идёт о хранилище, необходимо, чтобы инициатором передачи данных мог быть как клиент (управляющий компьютер, например для случаев когда необходимо передать данные после измерения в хранилище), так и сервер (хранилище, например когда нужно проверить переданные данные).
<a id=«org7d2d127»></a>
# Заключение
Функции PyChannel востребованы не только на управляющих компьютерах, но и серверах.
Таким образом PyChannel:
- Кроссплатформенный и универсальный как для серверов, так и для управляющих
компьютеров;
- Организовывает взаимодействие разных процессов внутри управляющего компьютера,
или сервера;
- Организовывает связь между управляющем компьютером и сервером, при этом
инициатором передачи данных может быть как управляющий компьютер, так и сервер.
<a id=«org1ab13e7»></a>
# Ссылки
<style>.csl-left-margin{float: left; padding-right: 0em;} .csl-right-inline{margin: 0 0 0 1em;}</style>
<div class="csl-entry"><a id="citeproc_bib_item_1"></a> <div class="csl-left-margin">[1]</div><div class="csl-right-inline">A. S. Kirilov, “Instrument control software at the ibr-2: Directions of development,” Joint Institute for Nuclear Research (JINR), Dec. 2017. Available: <a href="http://www1.jinr.ru/Preprints/2017/089(E10-2017-89).pdf">http://www1.jinr.ru/Preprints/2017/089(E10-2017-89).pdf</a></div> </div> <div class="csl-entry"><a id="citeproc_bib_item_2"></a> <div class="csl-left-margin">[2]</div><div class="csl-right-inline">I.A.Morkovnikov and A.S.Kirilov, <i>Upgrading websonix - remote instrument control system experiment on ibr-2 reactor</i>. Varna, Bulgaria: Joint Institute for Nuclear Research (JINR), 2013, pp. 181–185.</div> </div> <div class="csl-entry"><a id="citeproc_bib_item_3"></a> <div class="csl-left-margin">[3]</div><div class="csl-right-inline">E. Curry, “Message-oriented middleware,” in <i>Middleware for communications</i>, 2005, pp. 1–28. doi: <a href="https://doi.org/10.1002/0470862084.ch1">10.1002/0470862084.ch1</a>.</div> </div> <div class="csl-entry"><a id="citeproc_bib_item_4"></a> <div class="csl-left-margin">[4]</div><div class="csl-right-inline">“Zer0mq.” Available: <a href="https://zeromq.org">https://zeromq.org</a></div> </div> <div class="csl-entry"><a id="citeproc_bib_item_5"></a> <div class="csl-left-margin">[5]</div><div class="csl-right-inline">А. Кирилов and С. Мурашкевич, “Адаптация программного комплекса sonix+ для работы с daq-контроллерами delidaq-2 и диджитайзером n6730 фирмы caen,” <i>Письма в эчая</i>, vol. 20, no. 2(247), pp. 127–135, Mar. 2023, Available: <a href="http://www1.jinr.ru/Pepan_letters/panl_2023_2/07_kirilov_r.pdf">http://www1.jinr.ru/Pepan_letters/panl_2023_2/07_kirilov_r.pdf</a></div> </div> <div class="csl-entry"><a id="citeproc_bib_item_6"></a> <div class="csl-left-margin">[6]</div><div class="csl-right-inline">“Memory limits for windows and windows server releases.” Available: <a href="https://learn.microsoft.com/ru-ru/windows/win32/memory/memory-limits-for-windows-releases">https://learn.microsoft.com/ru-ru/windows/win32/memory/memory-limits-for-windows-releases</a></div> </div>