Алгоритм и программная реализация совместного редактирования графических схем в режиме реального времени с использованием библиотеки Socket.IO

Алпатов Алексей Николаевич ORCID: 0000-0001-8624-1662 кандидат технических наук доцент, кафедра инструментального и прикладного программного обеспечения, Федеральное государственное бюджетное образовательное учреждение высшего образования «МИРЭА — Российский технологический университет» 119454, Россия, Московская область, г. Москва, проспект Вернадского, 78, каб. Г-225 Alpatov Aleksey Nikolaevich PhD in Technical Science Ph.D. of Engineering Sciences, Docent, Department of Instrumental and Application Software, Federal State Budget Educational Institution of Higher Education «MIREA — Russian Technological University» 78 Vernadsky Avenue, office G-225, Moscow region, 119454, Russia alpatov@mirea.ru

Юров Илья Игоревич ORCID: 0009-0003-7121-4321 магистр, кафедра инструментального и прикладного программного обеспечения, Федеральное государственное бюджетное образовательное учреждение высшего образования «МИРЭА — Российский технологический университет» 109383, Россия, Московская область, г. Москва, ул. Полбина, 35к2, 912 Iurov Ilia Igorevich Master student, Department of Instrumental and Application Software, Federal State Budget Educational Institution of Higher Education «MIREA — Russian Technological University» 109383, Russia, Moscow region, Moscow, Polbina str., 35k2, 912 frit_027@mail.ru

Введение

Протокол HTTP появился в конце XX века и за это время стал преобладающей технологией передачи данных, применяемой при разработке клиент-серверных приложений в веб-среде ^[1]. В основе работы протокола HTTP лежит принцип «запрос-ответ», когда клиент посылает нужный запрос, например, GET или POST, а сервер в зависимости от типа запроса выполняет необходимые действия и возвращает клиенту нужные данные. Для реализации алгоритма совместного редактирования графических схем в режиме реального времени в протоколе HTTP выявляются существенные недостатки: отсутствие двунаправленной и полнодуплексной связи между компонентами системы ^[2]. Вследствие этого процесс обмена координатами курсора мыши между сервером и клиентами при рисовании линий в браузере может вызвать задержки и оказывать дополнительную нагрузку на сервер.

Обозначенных недостатков лишен протокол WebSocket. Технология позволяет веб-серверу и браузеру обмениваться данными по одному и тому же соединению одновременно в обоих направлениях ^[3]. Сервер в любой момент времени может отправить сообщение сразу всем клиентам, ранее установившим с ним соединение. Точно также любой клиент по тому же соединению может отправить нужные данные на сервер ^[4].

Но при использовании протокола WebSocket без вспомогательных библиотек реализация алгоритма совместного редактирования графических схем в режиме реального времени потребует разработки дополнительных процедур для обеспечения бесперебойной и стабильной работы компонентов системы. В рамках данной работы будет предложено решение данной задачи за счет использования JavaScript-библиотеки Socket.IO, которая добавляет управляемость событиями, автоматическое переподключение при разрыве соединения, мультиплексирование и другие функции ^[5].

Модель процесса совместного редактирования в реальном времени

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

Тогда процесс совместного редактирования можно описать следующей формулой:

где D₀ — начальное состояние документа до начала редактирования, ∆D_i(t) — изменения, внесенные i-ым пользователем в момент времени t, n — количество пользователей, участвующих в редактировании.

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

В ходе совместного редактирования документов в режиме онлайн могут возникать различные конфликты (конфликт вставки, удаления, форматирования, перемещения и т. д.) ^[6]. Рассмотрим процесс возникновения конфликтов данных в веб-приложении для совместного редактирования документов. Пусть каждый пользователь, редактирующий графическую схему, имеет свой локальный набор данных о состоянии документа. Пусть D_A(t) и D_B(t) представляют текущее состояние документа для пользователя A и пользователя B в момент времени t. Тогда можно определить конфликт следующим образом: конфликт возникает, если пользователя A и B внесли изменения в один и тот же узел или связь графической схемы в период времени ∆t — интервал времени, в течение которого изменения могут считаться конфликтными.

Иными словами, оба пользователя начинают редактировать документ в момент времени t₀. Пользователь A внес изменения в документ, приводя к изменению его состояния от D(t₀) до D_A(t₁) в момент времени t₁, или D_A(t₁) = D(t₀) + ∆D_A(t₁). Пользователь B также внес изменения в документ, что приводит к изменению его состояния от D(t₀) до D_B(t₂) в момент времени t₂ или D_B(t₁) = D(t₀) + ∆D_B(t₂). Теперь если t₁ < t₂, то возникает конфликт, так как оба пользователя внесли изменения в документ в разное время.

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

где n — узел или связь, (n, t) представляет изменение, внесенное пользователем в узел или связь n в момент времени t.

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

где n — узел или связь.

Если для пользователей A и B обнаружены одинаковые изменения в одном и том же узле или связи в течение интервала ∆t, то это считается конфликтом редактирования.

Пусть

— это набор изменений, внесенныхпользователем U_i в момент времени t, где k_i — количество изменений.

Для каждого изменения δ_i,j(t) определим его совместимость с текущим состоянием документа как C_i,j = f(δ_i,j(t), D(t)). Тогда конфликт совместимости изменений (два изменения несовместимы) определяется через

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

где Θ_i,j,k,l(t) — результат разрешения конфликта между изменениями δ_i,j(t) и δ_k,l(t) в момент времени t, δ_i,j(t) и δ_k,l(t) — изменения, которые конфликтуют между собой, D(t) представляет текущее состояние документа в момент времени t.

Функция g применяется для разрешения конфликта между этими двумя изменениями. Она принимает два конфликтующих изменения δ_i,j(t) и δ_k,l(t) а также текущее состояние документа D(t) и возвращает разрешенное изменение. Ее задача — определить, какое из этих изменений следует применить к документу. Функция g может быть реализована с использованием различных алгоритмов и стратегий разрешения конфликтов и в зависимости от характера конфликта. Например, если изменения δ_i,j(t) и δ_k,l(t) не взаимоисключающие, функция g может объединить их в одно изменение. Практически это может быть использовано для разрешения ситуации, когда одно изменение вставляет текст, а другое изменение добавляет форматирование этого текста, их можно объединить в одно изменение, которое вставляет текст с форматированием. Так δ₁(t) представляет изменение, вставляющее текст Text₁ в позицию Pos₁, а δ₂(t) — изменение, добавляющее форматирование Format₂ к этому тексту. Тогда функция g, примет следующий вид:

где φ_merged(t) — объединенное изменение, которое вставляет текст Text₁ с применением форматирования Format₂ в позицию Pos₁.

Алгоритм совместного редактирования графических схем в режиме реального времени

Реализацию алгоритма следует начать с написания серверной части приложения. Сервер с нужным портом можно создать различными способами, но в данном исследовании использовался минималистичный фреймворк Express ^[7]. После этого следует инициализировать экземпляр io с помощью класса Server, предоставляемый библиотекой Socket.IO, передав в его конструктор ранее созданный объект сервера ^[8]. Получив WebSocket-сервер, необходимо добавить слушателей событий и обработчики для них. В данном алгоритме сервер ожидает два события: connection и draw. При возникновении первого события сервер генерирует событие color и передает вновь подключившемуся клиенту случайный HEX-код цвета для графических линий пользователя. При возникновении события draw сервер отправляет полученные координаты точки перемещения курсора мыши конкретного пользователями всем остальным клиентам системы по тому же соединению. На рисунке 1 представлен код описанной части алгоритма с экземпляром io.

Рисунок 1. Серверная часть алгоритма с экземпляром io

В клиентской части алгоритма в первую очередь следует инициализировать экземпляр socket и подписать его на два события: color и draw. В обработчике первого события в переменную strokeStyle будет сохраняться цвет, полученный с сервера. В свою очередь, в обработчике draw клиент будет получать с сервера координаты курсора мыши другого пользователя и строить по ним графическую линию на своем экране с помощью специальной функции drawLine(). Стоит отметить, что сама линия отображается с помощью стандартных средств языка JavaScript, а именно, инструмента Canvas API ^[9].

Затем нужно проинициализировать необходимые переменные начальными значениями, получить элемент canvas из HTML-кода страницы и привязать к нему три события: mousedown (пользователь нажал мышью по графической области), mousemove (пользователь двигает мышью с зажатой кнопкой) и mouseup (пользователь опустил кнопку мыши) ^[10]. У каждого из указанных событий есть свой обработчик. При возникновении события mousedown алгоритм сохраняет начальные координаты startX и startY курсора мыши в созданный ранее объект mouse и устанавливает переменную isDraw в значение true. При событии mousemove, если значение isDraw истинно, сохраняются следующие координаты endX и endY курсора мыши, после чего все данные отправляются на сервер по соединению веб-сокета события draw и строится графическая линия текущего пользователя.

Затем в свойства объекта mouse startX и startY записываются значения endX и endY соответственно. На рисунке 2 продемонстрирован код обработчика события mousemove.

Рисунок 2. Код обработчика события mousemove

При возникновении последнего события mouseup переменная isDraw устанавливается в значение false.

После локального запуска сервера можно проверить работу алгоритма, нарисовав несколько простых геометрических фигур в трех разных браузерах. Результат показан на рисунке 3.

Рисунок 3. Результат работы алгоритма

Заключение

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