Comments 52
Статья рассчитана на широкого читателя.
Я не широкий, но я смог дочитать статью до конца.
Ага, есть такое впечатление. Но важно понимать, что в виде звезды представляется дерево маршрутизации, а не реальные соединения участников. У любого узла сети может быть десяток прямых линков с другими, по которым будет ходить трафик, но координаты от этого не изменятся. Если пропадет один "центральный узел", координаты быстро перестроятся на новом "корне". Как видите, топологии "звезда" здесь нет, нет единой точки отказа в виде центрального узла, через который идет весь трафик.
Представьте, как было бы хорошо, если роутер не был «бутылочным горлышком», и в случае его отказа все участники домашней сети могли выйти в интернет через умный телевизор, соседские беспроводные сети и в конце концов через ваш смартфон, и всё это без какой-либо дополнительной конфигурации после поломки роутера!
Но если всё это работает поверх IP, то как это возможно?
Устоявшееся понимение IP говорит нам, что должен быть шлюз по умолчанию и т.п. В случае "народного меша везде и во всем" любой Wi-Fi и провод, т.е. любой физический линк с другими устройствами является вероятным маршрутом выхода в глобальную сеть. На то она и ячеистая топология, когда каждый участник сети также выступает и роутером.
Интернет входит в квартиру по всем возможным линкам, которые ведут хотя бы к соседям, а тех соседей в следующий дом и так далее. Меш в описанном виде — некоторый упорядоченный самоорганизующийся хаос. И в этом его красота, как по мне :)
Несколько другая ситуация, на мой взгляд: вы в своих же интересах будете подцепляться к нескольким соседским узлам сети, тем самым обеспечивая собственную бесперебойность и вместе с тем — общую связность сети. Вы отвечаете за свой узел и не зависите от того, чей узел почему-то упадет, потому что вокруг десятки таких же как и вы заинтересованных в работоспособности собственного узла для личного выхода в сеть.
Вопрос достаточно острый для единоличных крупных меш-провайдеров в удаленных регионах. В случае многоквартирного дома невозможно узнать кто был транзитным узлом во время загрузки (потому что вокруг десятки и сотни меш-узлов). И даже для смельчаков, которые организуют магистральные кабеля без особого разрешения на то: невозможно будет утверждать, что пользователь загрузил что-то именно по этому кабелю. Вполне вероятно, он подключился к некоему публичному пиру через интернет и скачал свой контент таким образом.
Наверное, это красивая составляющая меш-сетей: предъявлять некому, потому что меш — общая децентрализованная технология, держащаяся на плечах тысяч и миллионов пользователей.
Как видно на иллюстрации, самой уязвимой является топология «звезда», она же является самой распространенной в быту из-за простоты организации.На правах олдфага могу вспомнить, что на коаксиальном ethernet'е была топология кольцо, с точки зрения надёжности ещё более «интересная». Отказ любого узла приводил к отказу всей сети. :)
Были мысли упомянуть "шину" и "кольцо", но воздержался во имя защиты статьи от перегрузки информацией, не актуальной сегодня, либо же просто мешающей среднему пользователю уловить суть сабжа. Но "кольцо", конечно, мощь! :)
На эзэрнете кольца вроде никогда не было. Была общая шина (и терминаторы на хвостах. И отказ узла, если он не начинал гадить в шину, на остальную сеть не влиял.
Вы с токенрингом не путаете?
Это одно из основных использований Yggdrasil сегодня: подключаемся к публичному пиру по его "белому" адресу через Интернет, и получаем устойчивое соединение со своим белым внутрисетевым IPv6-адресом Yggdrasil. Так играют в Minecraft и на USB-модемах поднимают свои общедоступные веб-сервисы (небольшие).
Целью Tor является анонимность. Никакого удобства и настоящей децентрализации в Tor-е нет. Yggdrasil же обеспечивает приватность (вся информация зашифрована), но не обеспечивает анонимность (т.к. найти владельца адреса достаточно легко: ближайший к нему пир наверняка знает его реальное местоположение).
Будет это когда-нибудь реализовано по простому, для домохозяек? Ну типа ПО на мобильнике, с кнопочками в интерфейсе: включить меш локально, включить меш с раздачей доступа к интернету?
P.S. Иду я спокойно, с супругой и ребёнком по столице, ребёнок захотел пи-пи, и жена отошла с ним на пару минут. Тут налетает маски шоу (оказывается гуляли не только мы, а ещё и единомышленники Алёши Н.) отрубается сотовая связь… Меня и других загоняют во дворик… и я никак не могу связаться с семьёй. Понятно, что даже при наличии локальной меш сетки я бы ни с кем связаться не смог, так как все популярные мессенжеры имеют серверную архитектуру… Погодите ка, а вот поэтому он никому массово и не сдался этот меш, что он вам даст кроме риска получить по голове из-за расшаривания своего интернета кому попало? А он в первую очередь нужен именно в критических и аварийных ситуациях. Но инфраструктура к этому абсолютно не готова. Вот когда уйдём от централизованных сервисов, тогда и понадобится децентрализованная сеть. Сейчас от неё простым смертным толку нет.
P.P.S. Начал знакомиться с меш сетями более 15 лет назад, и каждый год надеюсь, что вот-вот оно взлетит, вот-вот и все будем сами себе провайдеры… Но похоже, скорее будем спутниками пользоваться, чем децентрализованными сетями.
Я против повальных выходных прокси. А если кто-то их ставит — пусть будет готов к юридической ответственности и тд и тп. Внутрисетевая активность Yggdrasil подразумевает прямое взаимодействие двух адресов: пользователя и сервера, к которому он обращается. Сервер будет видеть Yggdrasil-адрес пользователя, а не промежуточных узлов. Поэтому в плане ответственности за активность здесь всё более-менее прозрачно.
Про кнопочки и интерфейсы: на смартфонах это уже реализовано. Смотрите гит-репозиторий.
Построение общего дерева координат
Напоминает описание работы протокола динамической маршрутизации в сетях TCP/IP, в частности OSPF. Только там, вроде как, используется высший адрес среди интерфейсов.
Когда в сети появляется участник с более подходящим ключом, дерево координат перестраивается, считая его корнем.
Если, теоретически, будет большой рост узлов в сети, то это скажется на производительности. В штатном режиме работы корень может вычисляться, допустим, один раз на тысячу (зависит от размера пространства координат, как я понимаю). Но если принять во внимание, что устройства могут быть недоступны и нужно довольно быстро эту недоступность заметить, то такие перестроения могут здорово повысить сетевые задержки.
Модель угрозы заключается в импульсообразном появлении и исчезновении узла с ключом подписи, который вынуждает остальных участников перестраивать координаты, беря его за точку отсчета.
А какие-нибудь способы защиты от этого имеются?
В отличие от первого запроса, установленная сессия между двумя участниками в большинстве случае осуществляется по одному маршруту, основанному на координатах транзитных узлов.
То есть, получается, каким-то образом строится таблица маршрутизации узлов и где-то хранится. Если каждый узел теоретически может выступать в роли маршрутизатора, то где должны храниться записи построенного маршрута?
Еще каким-то образом нужно понимать доступность узла в сети. В протоколах динамической маршрутизации периодически ходят healthchecks. А как это реализовано для узлов мэш-сети?
Баги выявляются и постепенно решаются силами сообщества. Проект не связан с какой-либо конторой, поэтому всё двигается не так быстро, как некоторым хочется. Однако, недавно видел информацию, что один из двух ведущих разработчиков тесно работает с Matrix (мессенджер) для интеграции в него работы p2p.
Ожидается релиз Yggdrasil 0.4, в котором планируется решение убивающих сеть "сетевых штормов". Об этой проблеме известно уже более полугода. В настоящий момент временным решением является вручную смайненный ключ подписи некоего узла энтузиаста, который всегда в сети и держит корень на себе.
Всё верно, в Yggdrasil присутствует DHT. В статье вопрос несколько упрощен для простоты восприятия не специализированного читателя. Насколько мне известно, DHT помимо координат содержит ключ и адрес узла. На вопрос "кто хранит маршрут" ответить навскидку не могу, чтобы не получилось ошибочно. Это требует разбирательства. Попробуйте посетить чаты сообщества (telegram, xmpp, matrix, irc). Возможно, там найдется человек, который ответит. Сам склоняюсь к тому, что маршрут хранится на конечных узлах сообщения, т.е. у конечных пользователей.
склоняюсь к тому, что маршрут хранится на конечных узлах сообщения, т.е. у конечных пользователей.
Логично предположить, что так и есть. Иначе какие преимущества от использования DHT. Хотя вариант с хранением на корневых узлах тоже имеет место быть. Надо поизучать.
Если смотреть в общих чертах, при значительном увеличении количества узлов в сети, компромисс будет пока что не в пользу скорости передачи данных. То есть технология пока что может быть хорошо применена в аварийных ситуациях (про маски-шоу описано выше) и в качестве резервного канала.
yggdrasil у меня давно стоит на тачках и даже есть свой публичный пир
но не сказать чтобы я был активным пользователем
с удивлением обнаружил что в этой сети нет зеркала флибусты кстати)))
Про Флибусту ты ошибаешься, глянь тут: http://[300:529f:150c:eafe::1]
Я сам флибусту последний год только через Yggdrasil открываю ;)
вот он недостаток таких сетей
что-то есть а фиг найдёшь, я смотрел в двух подобных списках там не было, а этот список я даже не видел
вот как новичку его найти?
P.S.: а флибусту я через бота в телеграме пинаю, оказалось так быстрее всего
Попытка упростить быстрый старт: В статью добавлена ссылка на внутрисетевую викию "HowToYgg" под заголовком "Начало использования". Кладезь информации от русскоязычного сообщества.
угу
и таких внутренних вики и списков там несколько (если не сказать много). информация на них конечно пересекается, но не дублирует друг друга
В официальном списке сервисов всего две Wiki: англоязычная полумертвая и приведенная выше :) А вот IRC-чатов во истину много, глаза разбегаются. На многие заходил, где-то активность хорошая. В частности, русскоязычное сообщество более всего восседает в ILITA IRC.
На момент публикации поддерживаются все распространенные ОС: Windows, Linux, MacOS, IOS и Android.Добавлю, что OpenBSD тоже поддерживает.
Попробую настроить в ближайшее время. Довольно интересно.
Завелось сразу без особых проблем. Во всяком случае адреса 300::/7, приведённые в статье и комменатиях пингуются. Прописал пока только публичные пиры Москвы и СПБ.
Однако, попытка доступа по web
lynx http://[300:529f:150c:eafe::1]
пока безуспешна.
Это при том, что lynx http://[::1] и lynx http:://ipv6.goоgle.com работают нормально. Под браузером links такая же ситуация, то только там пишут Permission Denied.
Машина стоит за NAT (для IPv4), порт я пробрасываю. А что касается IPv6, но у неё есть видимый из вне настоящий IPv6 адрес. Оба адреса прописал в разеле Listen:[]
Yggdrasil Network: Заря бытовых меш-сетей, или Интернет будущего