惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Martin Fowler
Martin Fowler
WordPress大学
WordPress大学
月光博客
月光博客
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
大猫的无限游戏
大猫的无限游戏
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
博客园 - 聂微东
Apple Machine Learning Research
Apple Machine Learning Research
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
雷峰网
雷峰网
小众软件
小众软件
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 叶小钗
美团技术团队
宝玉的分享
宝玉的分享
Hugging Face - Blog
Hugging Face - Blog
阮一峰的网络日志
阮一峰的网络日志
A
About on SuperTechFans
Jina AI
Jina AI
D
Docker
Last Week in AI
Last Week in AI
MongoDB | Blog
MongoDB | Blog
Stack Overflow Blog
Stack Overflow Blog
Microsoft Azure Blog
Microsoft Azure Blog

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
WardLink: что дальше и несколько открытых вопросов
wardcore · 2026-06-27 · via Все публикации подряд на Хабре

Средний

2 мин

106

Это продолжение поста о 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