Комментарии 6
Я правильно понимаю, что для корректного применения JSON patch на клиенте важно, чтобы патчи приходили в определенном порядке? В случае нескольких серверов (мастабируем горизонтально) и конкурентных изменений, порядок обновления state на сервере разрулит база данных. Но сообщения об этом с JSON patch внутри, могут доставляться на клиент в произвольном порядке (в зависимости от разных задержек в сети, например). Например сообщение update от одной машинки может придти раньше, чем add от другой, и состояние на клиенте будет пропатчено некорректно. Как это решить?
Все верно, реализация PatchPack предполагает строгую последовательность применения патчей, как на стороне сервера, так и на стороне клиента. Поэтому использование данного подхода накладывает ограничения на архитектуру взаимодействия сервера и клиента. Либо необходимо отдельно контролировать последовательность патчей, через порядковые номера например, либо отправлять патчи только с одного сервера, например через websocket. В случае обрыва соединения с одним сервером, и подключения к другому, необходимо заново отправить все состояние, а после уже изменения через патчи.
В библиотеке PatchPack схема/изменение передаются вместе с сериализованным состоянием/изменением
ИМХО не хватает примеров
Примером использования этой библиотеки может быть синхронизация состояния в многопользовательской онлайн игре, когда игрок делает действие (на клиенте), отправляет его на сервер и изменяет состояние игры, это изменение необходимо отправить всем остальным игрокам (на клиенты).
нет, пример оптимизированного обмена — что именно передаётся. а то размеры пакетов нет, а объяснения как они получены толком нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация трафика при синхронизации состояний через Jsonpatch