Про mesh-сети давайте попробую коротко объяснить. Но это сложно, да.
Некоторые товарищи полагают, что mesh-сети это прямо вот панацея от всех болезней, связанных с регулированием «интернетов». Типа, полносвязанные одноранговые построения невозможно заблокировать, выключить, фильтровать. Это действительно так. В теории.
Но на практике нужно взять в руки калькулятор и посчитать.
Вот сколько гипотетических маршрутов прохождения пакета существует для полносвязанной сети из 2 узлов? Ответ: 1.
А для 5? Ответ: 5!-1. Где (!) — это факториал. Всего, получается, 119 маршуртов. Подсчитать результат для сотни узлов, у меня уже кончился калькулятор — 157-значное число. При этом, нам же нужно не просто посчитать произведение сотни чисел — нам нужно построить оптимальный граф прохождения пакета, что увеличивает необходимость рассчётов до сложности двойного факториала.
И эти числа нужно считать на каждом узле для каждого пакета, ибо сеть-то наша ещё и динамически изменяется — узлы постоянно перемещаются, выключаются, появляются новые.
Для создания полного и математически решаемого алгоритма функционирования динамической mesh-сети нам нужно решить, ни много, ни мало, одну из «задач тысячелетия», которая называется «Равенство классов P и NP» или «проблема перебора». Уровень сложности которой лежит в одной плоскости с гипотезами Римана, Пуанкаре или решением уравнений Навье-Стокса.
Вот довольно хорошее видео про эту задачу, которое объясняет:
А как же работают mesh-сети сейчас, спросит читатель?
А вот это у меня в пост уже не очень влезет. Коротко:
- 1. Существующие алгоритмы, все — для статических сетей, где узлы прибивают гвоздём буквально;
- 2. Все эти алгоритмы базируются на неполном решении и используют «муравьинную логику» (стигмергию — видео ниже);
- 3. Работают эти алгоритмы, честно говоря, хреновенько. Иначе, все давно бы уже строили сети по mesh-топологии.
Но мы не сдаёмся! :)
Например, существуют следующие протоколы для создания и управления mesh-сетями:
- 1. Better Approach To Mobile Adhoc Networking (B.A.T.M.A.N.) — наиболее проработанный на сегодня протокол с практическими внедрениями (англ., рус.);
- 2. Netsukuku is a project with similar goals (англ.);
- 3. Ad hoc On-Demand Distance Vector Routing (AODV) (рус.);
- 4. Associativity-Based Routing (ABR) (англ.);
- 5. Dynamic Source Routing (DSR) (рус.);
- 6. Ad hoc routing protocol (целый список) (англ.);
- 7. Mobile ad hoc network (MANET) (рус.);
- 8. Wireless ad hoc network (рус., англ.);
- 9. Lugro-Mesh;
- 10. JOKER is a B.A.T.M.A.N.-based opportunistic routing protocol for mesh networks. И ещё ряд Open Source реализаций той или иной степени эффективности:
В конце хочу сказать вот чего ещё: каждый год по данной теме проходит целый фестиваль mesh-активистов разной степени упоротости. В большинстве, конечно, это галимые фрики, которые за анархию и прочую партизанщину. Но в рамках фестиваля проходит и соревнования эффективности алгоритмов, что очень круто. Называется «Battle Mesh».
В этом году он был в Париже в июле. Я опять «профакапил» сроки, хотя очень хотел съездить. Ну, на будущий год обязательно съезжу, да.
Вот страничка 12 слёта: https://www.battlemesh.org/BattleMeshV12.
Очень рекомендую, да. Особенно тем, кто пытается строить «коммунальные mesh-сети». Там для вас столько материала, что «кукуха» съедет окончательно. Ну, или просветление придёт. Одно из двух.
Часть 2
Вот отчёт с BattleMesh-10, который проходил в 2017-ом в Вене. За 18 и 19 год таких отчётов нет. На тусовку стало собираться слишком много фриков и слишком мало инженеров.
Впрочем, это всё равно дико интересно (спойлер: протокол-победитель не объявлен до сих пор).
Часть 3
А! Вот же ещё один проект «убийца-интернетов», про который часто вспоминают — FireChat.
Большинство просто никогда не включало это приложение и/или не поняли, как оно работает. Причём, с обоих сторон: и те, кто думает, что FireChat нельзя заблокировать, и потому это — клёво-круто, и всяческие кармановы, которые пишут радостные отчёты, что «оно не работает».
Рассказываю:
FireChat — это действительно работающее приложение для создания полносвязанной mesh-сети. НО!
Но вот эта вся сложность с маршрутизацией и организацией прохождения пакетов здесь решена очень изящным и простым способом: вся передаваемая внутри информация доступна всем узлам одновременно. FireChat просто берёт и рассылает ваше сообщение всем узлам, доступным в локации. И принимает всё, что ему дают другие узлы. Увидел новую ноду — отправил/получил.
Решение реально красивое, но для практического применения — бесполезное. Вы не можете отправить мессагу конкретному адресату и видите вообще все сообщения, которые ходят внутри.
То есть, получается эдакий локальный чатик-комната, где достоинство «чем больше узлов — тем лучше сеть» превращается в глобальный недостаток «здесь очень шумно и нифига не понятно». Просто представьте себе CB-радио, где несколько тысяч абонентов и все пытаются что-то сказать, и вы поймёте, о чем я.
Использование FireChat на всяких демонстрациях, действительно, имеет смысл, но при условии, что участники чата очень дисциплинированы и не лезут в эфир со всякими глупостями. Что почти невозможно. Если на демонстрации, конечно, нет военной выучки. Но если есть военная выучка, то тогда гораздо проще использовать всякие армейские технологии с командиром роты связи и «стрелками-радистами».
Ну, и, разумеется, в FireChat нельзя смотреть видосики с «ютюбчика». Только текст и только внутри приложения. А если у устройств ещё и радиус действия ограничен десятком-двумя метров, то гораздо проще ртом заорать, чем набирать текстом и чтоб потом все всё прочитали.
Автор: ЗаТелеком.