Надо было подключить чат гпт

обычная "номерная радиостанция"... больше слухов чем реальности))
это использовали ещё во время войны... сидит оператор и читает по бумажке... "одноразовый код" ))



после прочтения бумажка сжигается... а пепел рассеивается))

а на другом конце сидит оператор... и записывает в журнал...



если код совпал... то ключ на старт ! ))



потому что код одноразовый ... и действует ограниченное время ...



потом меняется...

Ты прячь веселые картинки в сполер , больно они глупые и темы не касаются .
Кому интересно - пусть открывают .
А то тема не журнал "Крокодил"
Или всех хочеш удивить ?

на самом деле это передача сообщений с помощью "одноразового блокнота".
применятся ещё в первую мировую... см. Шифр Вернама.
никому расшифровать этот бред не удалось... потому что код с абсолютной криптографической стойкостью.

ну и ладно...
а где наш мешмастик... или как его там))





Добавлено after 21 minute 47 seconds:
а мешмастик... использует следующие шифры))

Ed25519 для подписей
X22519 для обмена ключами ECDH
HKDF для получения ключа
AES-256 в режиме CBC
HMAC-SHA256 для аутентификации сообщений
SHA-256
SHA-512

в целом пойдёт)) но немного старело.


сейчас все используют такой шифровой набор (самый свежий)...
TLS_AES_256_GCM_SHA384



поэтому надо переделать))

но нас сейчас больше интересует топология сети...


Добавлено after 22 minutes 34 seconds:
цитата...
"AES-256 в режиме CBC с дополнением PKCS7"
уже давно никто не использует...
сейчас AES_256 в режиме GCM.

цитата...
"SHA256 для аутентификации"
уже давно никто не использует...
сейчас SHA384.

цитата...
"IV генерируются с помощью os.urandom()"
так делать нельзя.
это снижает криптографическую стойкостью.

и т.д.

цитата...
"Reticulum — относительно молодое программное обеспечение, и его следует воспринимать именно так. Несмотря на то, что при его создании в первую очередь учитывались передовые методы криптографии, оно не прошло внешнюю проверку на безопасность, и в нём вполне могут быть ошибки, нарушающие конфиденциальность или безопасность."

это мы уже поняли))

а что там с топологией сети...

А что может быть непонятного с топологией?
Тут всё просто: либо создаём свою сеть, либо используем одну (или несколько) уже существующих. Лично я за второе решение. Например, сеть Интернет проводная и мобильная. Если одну по каким-либо причинам использовать не удаётся, то вторая всегда выручит. Как резерв Интернету - местная голосовая УКВ-радиосвязь. А всякие там Мечтастики и Гоутенны - это несерьёзно!

не всё так просто))
сеть мешмастик построена на базе LoRa.



в сети мешмастик есть шлюзы... для подключения к интернет по Wi-Fi или по Ethernet.

кроме того... в комплект мешмастик входим модем))



к которому подключаются радиостанции Yaesu... пакетный радиомодем...
скорость передачи данных 1200 бод.
возможно использовать транкинговую систему.



мешмастик сам определяет как передавать пакеты... по интернету или через LoRa или по рации)).

я же говорю... ребята из мешмастик серьёзно подошли к вопросу связи.


Добавлено after 31 minute 59 seconds:
сеть мешмастик пропускает только шифрованный трафик (не шифрованный блокируется).



для передачи голоса используется аудиокодек Codec 2... с качеством от 700 до 3200 бит/с.
можно послушать как он звучит...
https://www.rowetel.com/?page_id=452

оригинал
https://www.rowetel.com/downloads/codec2/hts1a.wav

сжатый до 700 бит/с.
https://www.rowetel.com/downloads/codec2/hts1a_700c.wav

и т.д.
короче ребята из мешмастик решили переплюнуть TETRA 4,6 Кбит/с... и DMR 4,8 Кбит/с...


Добавлено after 36 minutes 57 seconds:
цитата...
"реальный тест дальности..."
-до 10 км с машины.



-до 30 км с горки))



-до 1...3 км по горду))



-может упасть до нескольких сотен метров в плотной городской застройки... ))

Добавлено after 12 minutes 8 seconds:
LoRa...
минимальная скорость 300 бит...
максимальная до 1,6 МГц... можно передавать видео))



короче... накрутили там пипец)) но в целом стандартно.


Добавлено after 3 minutes 3 seconds:
далее... Маршрутизация трафика...
а тут всё печально...


Добавлено after 25 minutes 44 seconds:


1.
сначала писали про анонимность в сети... типа адреса не передаются...
потом оказывается что только адрес отправителя не передаётся... а адрес получателя передаётся открыто по сети...
т.е. про анонимность можно забыть))

2.
максимальная дальность связи ограничена тремя соседними ретрансляторами...
т.е. нафига делать такую сеть... с ограниченной дальностью связи... не ясно))
или всё таки можно менять ?
"В Meshtastic-сети количество "хопов" задаётся в прошивке и по умолчанию составляет 3 прыжка. Это количество можно поменять при самостоятельной сборке прошивки. Каждый прыжок добавляет в заголовке сообщения +1 и видится всеми участниками ретрансляции."

3.
количество маршрутизаторов в сети ограничено...
не все точки могут работать маршрутизаторами...
цитата...
"Если позволить всем узлам маршрутизировать трафик, то в итоге вы будете тратить огромное количество пропускной способности на трафик, связанный с маршрутом/маршрутизацией/обслуживанием потенциально сотен узлов, которые на самом деле никогда не будут маршрутизировать трафик. Кроме того, эффективность маршрутизации будет намного ниже, и большинству пакетов, скорее всего, потребуется гораздо больше переходов, чем оптимально.
Вы разрабатываете алгоритм, который пытается выбрать оптимальную топологию маршрутизации. Теперь вы тратите на это всю пропускную способность. Существует также физический предел количества узлов, которые может поддерживать ваша сеть, и он экспоненциально уменьшается при снижении скорости передачи данных. Прощайте, LoRa и подобные технологии.
Тогда вы говорите: «К чёрту всё» — и просто решаете, что все наводнения заполняют всё вокруг, и надеетесь на лучшее. Что ж, вы видите, что происходит и здесь.
В конечном счёте подход, которого придерживается Reticulum, является наиболее оптимальным и единственным масштабируемым и функциональным решением в реальном мире, даже при очень низкой пропускной способности."

мда...
Итого.
сеть мешмастик "сырая".
нет нормальной маршрутизации... нет нормальной синхронизации... короче ничего нет))

Да кто же против-то? Нет предела совершенству. Другое дело, что мешмастик не предложил ничего нового в области передачи данных. Между БС используется И-нет, а на "последней миле" - всё тот же аналоговый радиоканал со всеми своими особенностями. Ну и какой смысл менять шило на мыло?

Нет. Изначально речь не про последнюю милю. На сайте мешмастик рисуют покрытие городов... областей... и целых стран. Объединяющих "всех свободных людей".
Но для этого надо начать с разработки сети. Для начала написать спецификацию с четким описанием. Как в сети интернет есть четкие стандарты с подробным описанием.
Вместо этого ребята сосредоточились на приложениях. Поэтому это нормально работать не будет. Именно так всегда и происходит когда сетью занимаются не связисты и сетевики а программисты приложений))

Руководство "сетевиков" в построении комплексной структуры тоже не приводит ни к чему хорошему. Например, система цифрового обмена данными Nexedge, разработанная специалистами Kenwood примерно в то же время, когда разрабатывались Tetra-4 и DMR, с технической точки зрения имеет очень неплохие характеристики, но не нашла широкого применения. Зато технология 4G, занимающая всю сетку частот отведённую для мобильной связи, активно продвигается.

в этом смысле анонимности нет НИ У КАКИХ адресных передач.
альтернативовой может быть только бродкаст, но при разрешении ретрансляции бродкастов возникает лавинообразная загрузка каналов. (ухудшение полезного использования полос)


ты ж сам привел абзац из обьяснения почему "нет нормальной маршрутизации" - это чисто обьективная проблема сети из узких каналов, где маршрутная информация создает существенную нагрузку на полосу. и выше я другими словами обьяснял это же.
и выбор именно узкополосных линков - осознанный выбор и осознанное ограничение.

проблему дальней маршрутизации можно решить только отказавшись от динамики сети (мобильности и непостоянной готовности) узлов. а это означает и отказ от однородности сети (мобильные клиенты не могут работать дальними маршрутизаторами)
тогда возможно за n секунд(или часов) построить деревья связности и использовать их некое длительное N>>n время (например сутки или неделю), cэконмив траффик на прокладку каждого маршрута, в предположении что закэшированные актуальны.

и открытые адреса назначения (а для диагностики маршрута и адрес источника) - необходимое требование маршрутизирующей сети.
к анонимности это прямого отношения не имеет при относительной свободе выбора своего адреса. (по сути технические ограничения связаны только с допустимой скоростью смены(генерации) адресов в рамках вышеупомянутых закэшированных деревьев связности.

неплохие характеристики... этого мало. надо ещё учитывать кучу параметров... стоимость оборудования... удобство использования... и т.д.
телефон спутниковой связи тоже был хороший)) но что-то никто с ними по улице не бегает))

конкретно мешмастик предлагает дешёвое решение... купить радиомодуль и простой МК... и можно передавать - принимать смс по сети.
идея хорошая. но не доделанная))
и в первую очередь из-за отсутствия стандарта с нормальным описанием.

не надо писать сеть для "всех свободных людей".))

надо писать: любительская безлицензионная сеть мешмастик.
технические характеристики:
-частота...
-полоса...
-скорость...

точно так же как в любой связи:
-частота...
-полоса...
...

далее... любой желающий может собрать своё устройство и подключить к сети... бесплатно)).


Добавлено after 42 minutes 50 seconds:
А что мешает сделать широко вещание ?

Добавлено after 6 minutes 17 seconds:
Хуже чем сейчас все равно не будет.

Добавлено after 1 minute 58 seconds:
В приведено обзаце ребята не объяснили почему не стали делать маршрутизацию. Они сказали что просто на это забили))


Добавлено after 16 minutes 44 seconds:
сеть в которой можно транслировать сигнал максимум через три ретранслятора (это несколько километров по городу) это не сеть. Такая сеть никому не нужна. Поэтому с широковещанием хуже не будет. Потому что хуже не бывает))
Надо исходить из этого.

они не забили, они не смогли придумать адекватное решение проблемы и решили оставить так.
про неограниченную ретрансляцию бодкастов - будет экспаененциальный рост загрузки полосы ...а экспаненциальный рост параметра в условиях жесткого лимита всегда приводит к неразрешимому конфликту (в данном случае к переполнению полосы и фактическому разрушению связи).

...это только экономисты могут верить в стабильный бесконечный экспанаенциальный рост

тогда не надо писать что это невозможно...
надо писать варианты решения...
-для начала надо добавить адрес получателя и адрес отправителя.
-придумать маршрутизацию... хотя бы простейшую)) как в коммутаторе локальной сети...
коммутатор запоминает из какого порта пришел пакет и знает в какой порт отправить ответный пакет.
так получается меньше трафика... на уровне локальный сетей.
-далее идет глобальная маршрутизация...
-надо отключить шифрование по умолчанию... и транслировать все пакеты с пометкой "мешмастик" ))
получается ещё меньше трафика... на уровне шифрования (обмена ключей).
а ещё.. кто-то использует шифрование... кто-то нет... кто-то использует другой протокол шифрования... дело добровольное))
-установить приоритет трафика... со скоростью 300 бит можно только смс передавать)) но можно и голос... если канал свободен.
точно так же как GSM приоритет для голоса... но можно и GPRS... если канал свободен.
-а ещё есть куча других частот...
-а ещё есть синхронизация...
-а ещё есть адаптивная модуляция...
-а ещё есть куча всего ))...
-и т.д.

короче... всё решаемо)) если не забивать на сеть.
а сеть тут главное. сами модули лора без сети не представляют интереса.


Добавлено after 19 minutes 20 seconds:
-на одной частоте передаем... на другой принимаем... друг другу не мешаем)) как в GSM...
Тогда хоть как-то будет работать.

в эзернет свиче портов не много, редко собирают транками в единые свичи более чем 100..200 портов
а самое главное в свиче полоса внутренней шины обычно порядка 10+Gbps и в рамках этой полосы траффик из инициирующих бродкастов ничтожен, по сути ему надо отправить на все свои порты бродкасты в самом худшем случае (если 1 инициирует соединения со всеми а остальные сидят тихо и только отвечают) по количеству ожидаемых узлов в сегменте сети. и обычно это короткие фреймы (64b) с arp пакетами. дальше заполняется map-hash (строится граф связности) и бродкасты постепенно сходят на минимум, если ничего не сломалось и если свич не ддосят безответными фрэймами..

а здесь какбы нет быстрых соединений вообще и каждый байт на счету, и нужны огромные таймауты чтоб пробежать некую глубокую цепочку

...и нет явно выраженных "портов", отправления с 1 узла могут слышать множество соседних узлов, которым в общем случае не извесно надо ли ретранслировать посылку или ее уже услышал следуюший хоп в цепочке маршрута.
тоесть нужен алгоритм построения логического графа ретрансляций и алгоритм его минимальных модификаций при выпадении узлов.
и наверняка это должен быть активный алгоритм (не использующий эзернетовское пассивное обучение на бродкастах с данными) потому что это тяжело для полосы


короче для автоматической мобильной однородной сети решение ограничить количество хопов до 3-4-5 шт - вполне практичное решение. а дальше надо делать оочень серьезные потуги которые сильно ограничат однородность и мобильность и пропускную способность. скорее всего эти потуги неадекватно усложнят сценарий развертывания и пользования такой сетью.

Добавлено after 18 minutes 16 seconds:


это примерно как: "мне надо возить кирпичи с кирпичного заводу на дачу 500km . посему все велосипеды и легковушки надо отправить под пресс или переделать в самосвалы! ...и вообще все велосипедисты пидоры! "

при чём тут шины порядка 10+Gbps... arp... ддос...
начнём с простого))

сеть мешмастик передаёт два байта FF FF адреса назначения.
а всего в сети мешмастик может быть 65536 абонентов)).
добавляем еще несколько байт...
Destination MAC - FF FF
Source MAC - FF FF
Destination IP - FF FF
Source IP - FF FF
итого 8 байт - FF FF FF FF FF FF FF FF

можно меньше... если заголовок переменной длинны как в TCP... но не важно))

далее... есть сеть мешмастик.



Добавлено after 28 minutes 20 seconds:
далее...
допустим у всех абонентов сети есть своя таблица маршрутизации.
допустим никаких служебных пакетов по сети не передаётся.
но каждый раз когда абонент принимает пакет (а все абоненты постоянно слушают эфир) абонент обновляет свою таблицу маршрутизации.
оптимальный маршрут рассчитывается по метрике...
а метрика берётся из TTL (время жизни пакета)... или на языке мешмастик "количество прыжков".))



далее...
допустим абонент 5 передаёт пакет абоненту допустим 25...
допустим абонент 5 только зарегистрировался в сети... и другие абоненты про него ничего не знают))
в этом случае пакет абонент 5 рассылается по всей сети... всем 65536 абонентам)).
происходит лавинный эффект...



но лавинный эффект происходит только один раз... при первой зарегистрации абонента 5.
все последующие пакета абонента 5 будут маршрутизироваться согласно таблице маршрутизации.
потому что абонент 5 уже есть в таблице маршрутизации всех 65536 абонентов)).



и вот наш пакет без труда добрался до другого конца города по кратчайшему пути ))
получилась простейшая маршрутизация.


Добавлено after 3 minutes 36 seconds:
максимальное количество ретрансляций может быть столько сколько абонентов сети...
в нашем случае максимум может быть 65536 ретрансляций)).
что вполне достаточно для небольшого города... или даже области...


Добавлено after 19 minutes 9 seconds:
и наоборот...
пакеты абонента 25 (начиная с первого пакета) будут маршрутизироваться согласно таблице маршрутизации.
потому что абонент 5 уже есть в таблице маршрутизации всех 65536 абонентов)).



итого.
лавинный эффект есть...
но лавинный эффект происходит только один раз... при первой регистрации абонента 5.


Добавлено after 1 minute 5 seconds:
именно так работают простейшие коммутаторы в простейшей локальной сети))

Добавлено after 1 minute 32 seconds:
ну вот... уже лучше.
65536 ретрансляций лучше чем 3-4-5 шт )).

Добавлено after 42 seconds:
далее интересней...))

Добавлено after 21 minute 13 seconds:
более того... абонент 5 может передать пакет любому абоненту в сети 0...65535.
потому что все 65536 абонента ранее зарегистрировались в сети.
а может передать пакет сразу всем 65536 абонентам))

ну а как быть с 10ю различным маршрутам но одинаковыми по ttl? такое вполне возможно из-за упомянутого выше эффекта избыточной связности геометрически близких узлов.

как быть с мобильными узлами и с узлами с нерегулярной доступностью?

как быть с меняющимися во времени качеством радиоканалов ?
в весах маршрутов явно желательно использовать показатели каналов (p,s/n,..)

не так быстро... )) мы рассматриваем простейшую маршрутизацию.

какого размера будет таблица маршрутизации ?

количество записей равно количеству абонентов 65536 умноженное на количество соседей)).
для начала в таблице маршрутизации будет три записи:
Destination MAC - FF FF
Destination IP - FF FF
метрика - FF FF

у абонент 5 всего два соседа (Destination MAC - 00 01 и Destination MAC - 00 02) с которыми можно связаться.
остальные соседи недоступны))



поэтому у абонент 5 таблица маршрутизации будет небольшая.

пример:
Destination IP - 00 00 | Destination MAC - 00 01 | метрика - 00 07
Destination IP - 00 01 | Destination MAC - 00 01 | метрика - 00 09
Destination IP - 00 02 | Destination MAC - 00 02 | метрика - 00 03
... и т.д.
всего количество записей равно количеству абонентов 65536.

а сколько надо памяти ?
65536 * 6 = 393.216 байт ОЗУ.
нормально))


если ttl одинаковые... то и метрика одинаковая... то и маршруты тоже одинаковые.
потому что Земля круглая))




в этом случае не важно по какому маршруту пойдёт пакет.
выбираем первый из списка))

мы рассматриваем простейшую маршрутизацию.
и вполне рабочую. даже в простейшем варианте.


Добавлено after 9 hours 3 minutes 24 seconds:
оптимизация))

добавим гарантированную доставку пакетов.



шаг 1.
-абонент 5 передаёт пакет абоненту 890.

шаг 2.
-абонент 890 передаёт пакет абоненту 402.
-одновременно абонент 5 принимает пакет ACK от абонента 890.

шаг 3.
-абонент 402 передаёт пакет абоненту 745.
-одновременно абонент 890 принимает пакет ACK от абонента 402.

шаг 4.
-абонент 745 передаёт пакет абоненту 293.
-одновременно абонент 402 принимает пакет ACK от абонента 745.

шаг 5.
-абонент 293 передаёт пакет абоненту 25.
-одновременно абонент 745 принимает пакет ACK от абонента 293.


в случае неудачной передачи... любой из абонентов может повторить передачу.

итого.
получилась сеть с маршрутизацией из эхо-репитеров с гарантированной доставкой пакетов.
ну вот... уже лучше.


Добавлено after 3 minutes 53 seconds:

любой из абонентов может в любой момент времени изменить маршрут пакета...
т.к. сеть у нас динамическая... самоорганизующаяся... с гарантированной доставкой пакетов. ))


Добавлено after 20 minutes 55 seconds:
что будет если один из абонентов будет недоступен ?
например если абонент 745 недоступен... то абонент 402 передаст пакет абоненту 100.



т.к. сеть у нас динамическая... самоорганизующаяся... с гарантированной доставкой пакетов. ))

напоминаю. никакие служебные пакеты по сети не передаются. ввиду жесткого ограничения на объём передаваемого трафика.))

Добавлено after 1 hour 46 minutes 39 seconds:

в любом нормальном модуле есть индикатор уровня сигнала... по которому подбирается оптимальная скорость передачи.
справедливо для всех абонентов сети.
это все мелочи)) самое главное в сети - маршрутизация.

простая прикидка:
1. допустим время посылки по радиоканалу t~10s
2. любому узлу чтоб убедиться что он выбрал самую "прямую" версию пакета надо подождать пока все соседние ноды отдуплятся с попытками бродкаста чтоб выбрать самый маршрутно-легкий пакет. допустим конкурирующих соседних нод 10 и каждая ретранслировала пакет.
это заняло t*10 ~100s (на самом деле больше на накладные расходы по антиколлизиям)
3. допустим мы хотим макс глубину 20 хопов по такой же плотной сети узлов
тогда общее время передачи в 1 сторону будет t*200~2000s(0.55h)
4. допустим мы хотим массовое использование мобильных узлов в маршрутизации и время работы узла в некой 1 локации предполагаем 10 минут (кэшируем маршруты не более чем на 10 минут). тогда подтверждение доставки 1 посылки в вышеупомянутом примере вернется через ~1+ час.

и это все в предположении что время выбора пакета для ретрансляции для каждой нод из фактического маршрута было свободно от других аналогичных бродкастов (что очень мало реально в сети общего пользования)


думаю подобная сеть возможна только как статическая, c оочень большим времененм кэширования маршрутов (сутки+) и с довольно сложной иерархизацией с учетом качества каналов между нодами. и мобильные ноды для ретрансляции врядли вообще получится эффективно вписать в такую иерархию.

Бродкастов в сети нет. Потому что все абоненты знают маршрут до всех других абонентов. Для этого и придумали таблицы маршрутизации.

Коллизий в сети нет. Один передаёт другой слушает. Потом наоборот.

С мобильными абонентами тоже проблем нет. Если приперемещенни абонент не знает кратчайший маршрут то он передаёт пакет соседям. Кто то из соседей точно знает кратчайший маршрут.

Все абоненты принимают и передают дальше пакет. А дальше не их проблемы)) Это как детская игра "передай другому"))

Таблице кешируются на постоянной основе. Время кеша не ограничено. Таблицы обновляются автоматичски в процессе передачи пакета. Никто специально их не обновляет.

Итого.
У нас самоорганизующаяся... само синхронизирующаяся... можно сказать самообучающаяся сеть которая сама подстраиваться под меняющуюся обстановку.
Во как )))


Добавлено after 2 minutes 56 seconds:
Можно сказать что в нашей сети пакеты сами "находят себе дорогу")) В этом весь прикол.

Добавлено after 8 minutes:
Время передачи одного сообщения... может меняться...
10 сек сообщение умножить на 20 хоров получим 200 секунд.
Это при условии что абонент какоето время не меняет свое положение и нет других сообщений ожидающих в очереди на отправку.
В противном случае время передачи сообщения будет чуть дольше... т.к. оптимальный путь неизвестен... но в любом случае время будет не на много больше.

roman.com, ты сказочник


коллизии или большие накладные на гэпы (периоды молчания) необходимы для динамического расписания приемов-передач иначе увы нельзя динамически ввести новоее (мобильное) устройство в сеть.


даже в глобальной ip сети где 90% маршрутов фактически статичны (все возможные варианты статично описаны в bgp анонсах)
и где жесткая иерархическая нумерация адресов ито нельзя обойтись без бродкастов на некоторых участках. тот же arp например или mstp.

а уж в днамической сети с радиолинками, рандомной адрессацией и мобильными узлами без существенного количества бродкастов - ну никак не обойтись.