Забудьте про MeshCore.
Когда я впервые узнал об этой сети подумал, о круто, прикрутили маршрутизацию, и пошёл смотреть чоэта. Оказалось что это не мештастик с маршрутизацией, а прям отдельная другая сеть со своей философией. По сути это внедрение директивным методом того что нужно любой lora-mesh чтобы работать нормально:
ретрансляторы только в хороших локациях
максимальный интервал отправки нодинфо\адверта, локации и телеметрии (в идеале - полное отсутствие и только ручная отправка)
НО сразу же полезли и проблемы: если вам в поле нужен групповой чат вам недостаточно N нод вам к ним нужно x роутеров (по количеству необходимых хопов) и комната (сервер группового чата). Соответственно если по любой из десятков возможных причин ляжет инфраструктура вы нормально не пообщаетесь. Когда я это понял, как и то что тастик может работать так же если нормально расположить и настроить ноды я просто перестал о нём думать.
Однако в моём окружении и дефолт-чате мыша продолжали и продолжают появляться люди пропагандирующие MeshCore. Давайте разберём их агрументы:
1. 64 хопа
Авторы просто оставили 2 байта для счётчика хопов в заголовке вместо одного. %) В реальном эфире пакет, летящий через десятки роутеров, будет идти минуты, что приведет к вечному сбросу сессий по ACK-таймауту. С учетом неизбежного затухания и коллизий на каждом звене, вероятность доставки пакета на 64 хопа стремится к нулю. Реальный стабильный предел MeshCore — те же 4–5 хопов.
2. Но почему тогда сообщения ходят на всю Москву?
Потому что нормально расположены роутеры и настройки выбраны даже медленнее (и дальнобойнее) чем LоngFast в мыше, а сеть не перегружается потому что в ней нет телеметрии, трекеров и тому подобного, да и, будем честны, народу не то чтоб много.
3. Ну и что, даже на этих настройках трансивера (62.5 kHz|SF7|CR7) сеть работает быстрее чем тастик на MediumFast.
Это правда, за счёт меньшего числа коллизий можно укоротить интервалы ожидания между пакетами и добиться даже с перегруженным заголовком пакета сравнимого или даже чуть большего datarate. Но я добавил бы тут слово ПРЕДПОЛАГАЕМОГО (меньшего числа коллизий), смекаете? Подобное архитектурное решение делает сеть менее устойчивой к коллизиям.
4. Есть маршрутизация!
Да, и это позволяет сократить managed flood используя его только при включении ноды ну или... постоянно, если нода движется. %) Более того маршрут запихивается в сам пакет, причём, внезапно, оказалось что роутеров может быть больше чем 255 и теперь приходится запихивать по 2 байта на каждый. Попробуйте умножить свои любимые 64 хопа на 2 и потом вспомните что в пакете всего 255 байт. %)
5. Осмысленные диалоги, сообщения всегда доходят, есть история
Это плюс комнаты, работающей по pull модели, но есть и минусы, так как весь траф группового чата стекается к серверу комнаты и забирается оттуда же. И мало того что сервер у комнаты может быть всего один (распределённых серверов с синхронизацией пока нет), так ещё и, внимание, КАНАЛ У НЕГО ВСЕГО ОДИН. И, как уже писалось, не то чтобы широкий. Наложите на это pull модель: клиент по просьбе пользователя говорит серверу "чо там пишут" и сервер несколькими пакетами возвращает историю. А теперь вспомните про 2 байта на каждый роутер в маршруте и представьте как пара сотен человек проснулась, или вышла на обед и запросила историю чата.
Да, в тастике этого вообще нет, вернее есть костыльный store-forward и поэтому каждый по сути решает эту проблему сам через открытый ли клиент, ботов, bbs, ретрансляцию в другие мессенджеры, mqtt... Однако так или иначе проблема это решаемая, а в корке групповой чат без комнаты в принципе невозможен.
И да может клиенты и скрыты потому что излучают в эфир очень мало, но зато роутеры и комнаты видны прекрасно и при этом являются ключевыми узлами сети без которых она просто перестанет существовать. Странно не понимать, что это вцелом довольно хрупкая и потенциально контролируемая архитектура. В мыше же ровно одна неустранимая архитектурная проблема: SNR-weighted Tx Delay.
Резюмирую. Это архитектурно, и я бы даже сказал, идеологически разные вещи. Лично мне мешкор пока не нужен ни для чего.