Это продолжение поста о WardLink — P2P-синхронизации между своими устройствами по LAN без сервера в петле. Здесь про то, куда это может пойти, и про несколько вопросов, на которые у меня пока нет хорошего ответа.
Сценарий, который LAN не покрывает
WardLink работает, пока оба устройства в одной сети. Это закрывает большинство домашних сценариев: телефон и ноутбук на одном роутере — всё синхронизируется автоматически.
Но есть специфичные ситуации — когда оба устройства физически рядом, однако оказываются в разных сетях, и переподключиться некуда. WardLink в таких случаях не поможет.
Bluetooth здесь работал бы. Не зависит от роутера, дальность 10–15 метров, физическая близость — всё что нужно.
Но есть одно но: скорость. BLE Classic даёт около 2 Mbps в лучшем случае. Синхронизация метаданных через это — мгновенная. Первая полная синхронизация с большой историей чатов — это несколько минут ожидания в лучшем случае.
Один вариант обойти это: использовать Bluetooth только для discovery и паринга, а сами данные передавать через WiFi Direct — он не требует общего роутера и по скорости сравним с обычным WiFi. Минус в том, что поддержка WiFi Direct на Android неравномерная, на Linux — отдельная история, на Windows и macOS тоже без гарантий.
Второй вариант: Bluetooth как транспорт только для метаданных и небольших данных. Медиафайлы ждут, пока устройства окажутся в одной сети. Гибрид, но это усложняет логику синхронизации.
Пока не уверен, что это стоит усложнения. Мне интересно, насколько вообще реальный этот сценарий: попадаете ли вы в ситуацию, когда два своих устройства рядом, но не в одной сети?
Конфликты при расхождении состояний
Текущая модель синхронизации — pull-based: каждое устройство тянет у пира то, чего у него нет. Для сообщений это работает чисто — они иммутабельны, конфликтов нет.
Для списка избранных чуть сложнее. Если оба устройства были офлайн, оба внесли изменения, потом встретились — побеждает последняя запись по timestamp. Это работает в подавляющем большинстве случаев.
Слабое место: timestamps на двух устройствах могут расходиться на секунды или минуты, и в edge cases это даёт неожиданное поведение — например, изменение, сделанное «позже», оказывается перезаписано.
CRDT решило бы это правильно, но это приличный объём работы для сценария, который большинство людей в реальной работе, скорее всего, не замечает. Любопытно: сталкивались ли вы с подобным — когда синхронизация неожиданно откатила изменение?
Три вопроса
Сценарий «рядом, но не в сети» — насколько он реальный в вашем случае? Bluetooth или WiFi Direct — стоит ли вообще туда идти?
Синхронизировать только избранные или дать выбор? Сейчас синхронизируются только избранные — это было сознательным решением, потому что полная история может быть огромной. Нужна ли возможность синхронизировать всё?
Конфликты при расхождении — вы это замечаете сейчас, или это теоретическая проблема?
Комментарии здесь или issues в репозитории одинаково полезны: https://github.com/wardcore-dev/onyx
ссылка на оригинал статьи https://habr.com/ru/articles/1052502/