Идея децентрализованной радиосвязи без вышек сотовых операторов не нова, но разные проекты решают задачу маршрутизации сообщений совершенно по-разному. Если в проекте Meshtastic каждый узел ретранслирует буквально любое чужое сообщение, попавшее в радиус его слышимости, то более молодой протокол MeshCore пошёл другим путём: он один раз находит рабочий маршрут между двумя устройствами, запоминает его и дальше гоняет трафик именно по этому пути, а не по всей сети целиком. Разница на первый взгляд кажется технической деталью, но именно из этого архитектурного решения вытекают все практические отличия между двумя протоколами: время автономной работы устройств, устойчивость к перегрузке канала и то, насколько хорошо сеть масштабируется на сотни узлов. Разберём, как именно MeshCore находит и запоминает маршрут, какую роль играет каждый тип устройства в такой сети и какими компромиссами приходится платить за отказ от простой лавинной рассылки.
Что происходит при первом сеансе связи между двумя ещё незнакомыми узлами
Когда устройство отправляет сообщение адресату, маршрут до которого сети ещё неизвестен, MeshCore временно ведёт себя точно так же, как классические лавинные протоколы: пакет широковещательно рассылается через доступные ретрансляторы, каждый из которых проверяет уникальный идентификатор сообщения и, если видит его впервые, передаёт дальше своим соседям. Этот этап называют фазой обнаружения пути, и он неизбежен именно потому, что на старте у отправителя нет никакой информации о том, через какие промежуточные узлы физически можно дотянуться до получателя. Как только сообщение доходит до адресата, тот формирует ответное подтверждение доставки, и это подтверждение, возвращаясь обратно к отправителю, попутно фиксирует в себе точную цепочку ретрансляторов, через которые оно прошло. Именно эта записанная в подтверждении цепочка и становится тем самым обученным маршрутом, который сеть будет использовать для всех последующих сообщений между этой парой устройств.
Как сеть перестаёт нуждаться в общей рассылке после того, как путь найден
Начиная со второго сообщения между уже знакомыми узлами, MeshCore встраивает найденный маршрут прямо в заголовок пакета в виде явного списка ретрансляторов, через которые сообщение должно пройти. Это принципиально меняет поведение всей сети: теперь пакет пересылают только те конкретные ретрансляторы, которые перечислены в его заголовке, а остальные узлы, даже физически услышавшие передачу, просто её игнорируют, потому что не находят себя в списке адресатов маршрута. Такой способ пересылки называют маршрутизацией от источника, поскольку весь путь целиком определяется отправителем ещё до выхода пакета в эфир, а не вычисляется динамически каждым промежуточным узлом. Чем дольше два устройства обмениваются сообщениями по уже выученному маршруту, тем меньше лишнего эфирного трафика создаёт их переписка по сравнению с сетью, где каждое сообщение приходится заново рассылать всем подряд.
Что случится, если один из ретрансляторов на выученном маршруте выйдет из строя
Обученный маршрут не гарантирован навечно: ретранслятор может выключиться, переместиться или просто оказаться временно недоступным из-за помех. MeshCore обрабатывает эту ситуацию через встроенный механизм повторных попыток: если сообщение, отправленное по ранее известному пути, не подтверждается за отведённое время, устройство повторяет попытку до трёх раз подряд по тому же самому маршруту, предполагая, что причиной могла быть случайная потеря конкретного пакета, а не полный разрыв пути. Только если все три попытки провалились, протокол считает выученный маршрут недействительным и на последней попытке снова переходит в режим лавинной рассылки, заново разыскивая рабочий путь до адресата с нуля. Такая логика балансирует между двумя крайностями: она не тратит эфирное время на постоянную проверку актуальности маршрута при каждом сообщении, но и не держится за заведомо неработающий путь до бесконечности, если реальные условия в сети изменились.
Какую роль в архитектуре сети играет каждый тип устройства
MeshCore жёстко разделяет устройства сети по функциональному назначению, и это разделение прямо противоположно подходу Meshtastic, где любой узел по умолчанию способен ретранслировать чужой трафик. В экосистеме MeshCore выделяют три основных типа устройств:
- Клиентские устройства, которые в терминологии проекта называют компаньонами, обычно это карманный прибор, привязанный по беспроводному каналу к телефону пользователя, - такие устройства только отправляют и принимают собственные сообщения и принципиально не участвуют в пересылке чужого трафика;
- Выделенные ретрансляторы, устанавливаемые администраторами сети сознательно и заранее в местах с хорошим покрытием, - именно эти устройства составляют весь несущий каркас маршрутизации и берут на себя всю нагрузку по пересылке пакетов между клиентами;
- Серверы комнат, работающие по принципу доски объявлений с сохранением истории сообщений, - такие узлы хранят переписку сообщества и отдают её подключившимся клиентам, а не просто мгновенно ретранслируют пакеты дальше.
Почему клиентские устройства принципиально не участвуют в ретрансляции чужого трафика
Отказ от участия обычных клиентских устройств в пересылке чужих сообщений - осознанное архитектурное решение, а не техническое ограничение платформы. В сети, где ретранслятором становится буквально каждое устройство, включая карманные приборы пользователей, работающие от небольшой батареи, каждое новое подключившееся устройство добавляет сети не только полезную связность, но и дополнительную нагрузку на общий радиоканал в виде ретрансляций чужого трафика. MeshCore разрывает эту связку: батарейный клиентский прибор пользователя расходует энергию исключительно на собственную переписку, а вся тяжёлая работа по пересылке чужих пакетов ложится на выделенные ретрансляторы, которые администраторы сети специально размещают со стационарным питанием и антеннами в местах с наилучшим покрытием. Такое разделение ролей одновременно продлевает автономную работу карманных устройств пользователей и избавляет сеть от эффекта, который инженеры называют широковещательным штормом, когда рост числа устройств начинает не расширять покрытие, а душить канал избыточными повторными передачами.
Как разница в подходах отражается на реальной загрузке радиоканала
Разница между полной лавинной рассылкой и обученной маршрутизацией по конкретному пути особенно заметна именно в загрузке радиоканала при росте числа устройств. В экспериментах с моделированием подземных ячеистых сетей на LoRa, где сравнивали классическую лавинную рассылку с маршрутизацией по вычисленному пути, доля времени, которое каждый ретранслятор проводил в режиме передачи, при чистой лавинной рассылке превышала десять процентов у всех задействованных узлов, тогда как при использовании маршрутизации по конкретному пути та же нагрузка падала до значений в пределах одного-четырёх процентов. Разница на порядок объясняется просто: при лавинной рассылке каждый ретранслятор в радиусе слышимости повторяет буквально каждое проходящее сообщение, тогда как при маршрутизации по заранее известному пути в пересылке участвуют лишь несколько конкретных узлов, перечисленных в заголовке пакета, а остальные ретрансляторы сети в этот момент вообще не задействованы и свободны для обслуживания другого трафика.
Какими практическими ограничениями приходится платить за такую архитектуру
Выигрыш в эффективности канала не даётся бесплатно. Во-первых, сеть MeshCore не объявляет о своих устройствах непрерывно, как это принято в Meshtastic: присутствие узла в сети распространяется через отдельные объявления, которые пользователь должен явно инициировать, и поэтому список видимых контактов на новом устройстве изначально пуст, что первое время сбивает с толку тех, кто ожидает автоматического появления соседей на карте. Во-вторых, качество работы всей сети сильно зависит от того, насколько продуманно администраторы разместили выделенные ретрансляторы: если инфраструктурных узлов недостаточно или они расставлены неудачно, обучение маршрута может занимать несколько попыток, а сама фаза начальной лавинной рассылки при первом контакте всё равно создаёт кратковременную нагрузку на канал, ничем не отличающуюся от классической схемы. В-третьих, протокол MeshCore не совместим с прошивкой Meshtastic на уровне эфира, хотя оба проекта нередко работают на одном и том же радиомодуле: устройству приходится выбирать одну прошивку, и сообщества, построенные на разных протоколах, физически не могут напрямую обмениваться сообщениями друг с другом, даже находясь в зоне взаимной радиослышимости.
Как выглядит практический пример работы выученного маршрута на цифрах
Представим сеть из десяти выделенных ретрансляторов, расставленных по городу, и двух пользователей, один из которых пишет другому впервые. Первое сообщение проходит фазу обнаружения: пакет уходит в эфир, и потенциально каждый из десяти ретрансляторов, услышавших его, включается в пересылку, если находится в пределах разрешённого протоколом числа прыжков. Пусть в итоге сообщение реально прошло через три конкретных ретранслятора, прежде чем достигло адресата, тогда именно эти три узла и их порядок зафиксируются в подтверждении доставки. Начиная со второго сообщения, заголовок пакета будет содержать точный список этих трёх ретрансляторов, и только они станут его обрабатывать, а оставшиеся семь ретрансляторов сети попросту не отреагируют на эту передачу, даже услышав её в эфире, потому что не найдут себя в списке маршрута. При активной переписке в течение дня такая экономия ощутимо снижает суммарное число передач в канале по сравнению со сценарием, где каждое из, скажем, полусотни сообщений заново рассылалось бы всем десяти ретрансляторам подряд.
Насколько MeshCore и Meshtastic совместимы друг с другом на одном оборудовании
Оба протокола часто устанавливают на идентичное аппаратное обеспечение, обычно платы на основе микроконтроллера ESP32 или nRF52 с радиочипом LoRa, и это иногда создаёт у новых пользователей ложное впечатление о взаимной совместимости сетей. На деле выбор протокола - это выбор прошивки, которая единолично управляет радиомодулем, поэтому устройство способно работать только в одной из двух сетей одновременно, и переключение между ними требует полной перепрошивки, а не простого переключения настройки в меню. Устройства с прошивкой MeshCore и устройства с прошивкой Meshtastic, даже находясь в одном помещении и слыша радиопередачи друг друга физически, не смогут прочитать и обработать чужие пакеты, потому что структура заголовка, формат адресации и сама логика принятия решения о ретрансляции у двух протоколов принципиально различаются. Сообществам, которые уже развернули инфраструктуру на одном из протоколов, при желании перейти на другой приходится заново перепрошивать и настраивать каждый узел сети, а не просто обновлять программное обеспечение поверх существующей конфигурации.
Понимание разницы между полной лавинной рассылкой и гибридной схемой с обучением маршрута объясняет, почему выбор конкретного протокола для децентрализованной сети - не вопрос личных предпочтений, а вопрос сценария использования: там, где устройства перемещаются хаотично и обмениваются короткими разовыми сообщениями, постоянное обновление лавинной рассылкой может оказаться проще и надёжнее, а там, где костяк сети образуют стационарно установленные ретрансляторы и постоянный круг переписки между известными участниками, выученный маршрут MeshCore экономит эфирное время и заряд батареи многократно эффективнее.