Pull to refresh

Comments 109

Объявление: Если вдруг кто хочет помочь с иллюстрациями/диаграммами, прошу стучаться в личку :)
В избранное! Я мечтаю, что именно такой и будет глобальная сеть след. поколения.
было бы неплохо, но наврятли интернет-магнаты позволят такому случиться
Самое забавное в том, что интернет-магнатам это таки на пользу. Если они конечно смогут это понять.

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

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

То есть, при грамотном сотрудничистве, выиграли бы все.
Проект мне кажется изначально не рассчитан на широкую аудиторию. Пробежка по их сайту и «манам» дает это понять. Это видимо позиция создателей, потому что если бы они думали по-другому, то Netsukuku стала бы уже (за три года-то!) крупнейшей p2p сетью. Потому что то, что вы описываете весьма и весьма любопытно.

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

Если нечто является удобным, хорошим и дешевым — люди сами об этом узнают :)
Подождите, а как подобная сеть может решить проблему последней мили, которая заключается в физических носителях?
За счет абонентских устройств. Вместо того чтобы тянуть провод в каждый дом, провайдер ставит районные маршрутизаторы, ну и опорные точки для покрытия. А все что ниже — организуется автоматически.

Разумеется, совсем проблему это не решает, и возможно только при относительно высокой плотности абонентов.

Но скажем распределение нагрузки на все каналы, организация трафика и др осуществляется уже само.
Всегда можно попробовать в OS среде. Foneros к примеру
Очень печально, что последнее изменение в svn — 4 месяца назад.
Проект преинтереснейший.
Возможно вы не в ту ветку смотрите. В песочнице постоянно происходят обновления. Бот на ирц то и дело рапортует о новых правках
Признаю свою ошибку, в песочницу — не заглянул.
Я еще не прочитал новый материал, но по предыдущей статье у меня возник вопрос как планируется регулировать зафлуженность сети маршрутизаторскими пакетами?
в той-же предыдущей статье в комментариях есть ответ — маршрутизаторские пакеты посылаются на ограниченную длину узлов.
А со спуфингом-то что?
Я для кого-то hash node — кто мне мешает модифицировать записи на мне и резолвить их совсем в другое место?
Или кто мне мешает присвоить эти имена — зарегистрировать их на самом себе со своим ключом?
Имена вы можете регистрировать не все — только те, хеш которых указывает на ваш узел. Иначе, только соседние ноды будут вместо правильной ноды адресовать пакеты вам.

Насчет хешей — хз. Можно хранить открытый ключ вместе с именем и после резолва проверять его валидность с целевой нодой.
Это если по логике.
Понятно, что не все. Вот те, которые на меня указывают — мне что мешает перехватить?
Открытый ключ и так хранится, но я так понимаю, что он вместе с резолвом не передается — клиент ничего проверить не может.
Да и передавать его смысла нет — если я hash-node, то я его и подменить могу — у клиента все сойдется.
Нет конечно. В общем случае проблема спуфинга существует. И не зависит от того, интернет это или какая другая сеть. Проверка подлинности не должна осуществляться только на базе имен. То есть, это уже задача прикладного уровня, а не сети.
Именно что сети.
В централизованной сети у нас доверенные DNS'ы есть, а здесь что? Механизм резолва есть, а защиты его — нет. И смысл в такой сети? Академический эксперимент?
Ну а что такое доверенные DNS? В любой корпоративке есть свои сервера. В любой сети есть куча цисок, очень многие из которых настроены чуть ли не по дефолту, что позволяет получить доступ и опять же рулить пакетами. Так что вся эта довереность, не более чем формальна.
Не путайте проблемы архитектуры (протокола) и проблемы реализации. Тем более куча цисок вообще никакого отношения к DNS не имеют.
Проблема архитектуры — это например arp-spoofing, представьте, что такое же было на уровне DNS. Был бы интернет в таких условиях? Нет.
Если у вас есть конкретные предложения по этому поводу — пожалуйста, готов выслушать. А на нет и суда нет. Эти вещи я и сам знаю и буду обсуждать с разработчиками.
Задача построения полностью децентрализованной сети — это и есть задача обеспечения ее безопасности в условиях, когда безопасность каждого отдельного узла обеспечена быть не может. Просто трафик в облаке передавать — это велосипед — и обсуждать нечего.
Так вот — как раз безопасности в текущей реализации не заметно совсем — задача не решена. И если решена не будет — будущего у такой сети нет.
И «конкретными предложениями» и «обсуждением с» тут делу не поможешь. Здесь не какие-то частные уязвимости, здесь системные проблемы, и решения их должны были быть в первоначальной архитектуре сети — вообще до всякой реализации.
Странно, что разработчики этого не понимают.
Перечитайте еще раз часть про механизм регистрации.

Чтобы сотворить такое безобразие вам надо:

Иметь ip например a.b.c.d. Теперь, надо придумать такое имя, хеш от которого был бы равен a.b.c.d. Ну или наоборот, умудриться как то заполучить такой адрес автоматически. Ввиду односторонней природы хеш функции, просто так по значению аргумент вы не найдете. Либо потратите очень много времени на это.

Далее, допустим даже у нас есть такое имя blabla, и h(blabla) = a.b.c.d. Ура! Теперь любой, кто захочет резолвить имя blabla (вопрос еще, нафиг ему это надо), будет попадать к нам.

Эта задача являтся основной задачей криптоанализа, касательно хеш функций. При использовании нормального алгоритма хеширования, это не так просто. В противном случае — проблемы будут несколько больше, чем подстановка имен :)

Далее. Чтобы зарегистрировать имя (не у себя), надо чтобы хеш нода обратилась к узлу счетчику, чтобы он сказал что лимит на количество имен еще не исчерпан. Допустим мы хотим сляпать свой «счетчик», который на все запросы будет отвечать что еще можно.

Узел счетчик находится как хеш от публичного ключа регистрирующегося. Чтобы начать беспредел и закиберсквоттить все имена, нам надо сгенерировать такой открытый ключ, хеш от
которого совпадал бы с адресом нашего псевдосчетчика. Опять же, задача на тысячу лет.

И самое главное. Мы имеем в руках открытый ключ, но нам же блин надо еще его использовать! Чтобы подписать такое выстраданное имя. А закрытого то и нет. И мы оказываемся на тех же правах, что и любой хаксор, пытающийся подобрать секретный ключ по открытому ключу. Опять криптоаналитик чешет репу.

И все это ради одного несчастного имени.

Ну и самое главное — распределенная природа сети просто не позволяет проводить локальные атаки. Вследствия отсутствия таковых. Мы хотим обломать соседа, а он, зараза такая, вместо нас цепляется на узел на другом конце земли.

Наконец, никто не запрещает проверять валидность хоста с помощью цифровых подисей и сертификатов от того же cacert.org

Вы мне рассказываете, про те задачи, которые авторы уже софта предусмотрели — спуфинг выбранного домена X, киберсквотинг — да, тут вроде все хорошо.

Я же предлагаю совсем другую:
мы _уже_ hash-node для кого-то — нам не нужно подбирать имя по хэшу, это имя на нас уже зарегистрировано, он сам к нам пришел
мы не хотим регистрировать на себя все имена — пока мы решаем задачу перехвата одного, и счетчик здесь вообще не у дел

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

Защищенные протоколы, вроде SSH и так проверяют отпечатки. Незащищенный HTTP — ну здесь вариантов несколько, либо переходить на SSL, либо вводить поголовную сертификацию а-ля cacert (для тех, кому критична безопасность).
Интернет — вообще никакой не ориентир, он ни разу не безопасен.

С сертификатами тоже проблема — у нас сеть децентрализованная, в ней корневых CA быть не может.

А что если запись о регистрации и ключ от нее хранить на разных нодах? Одна hash-node, другая hash+salt-node? А при резолве ключи проверять.
Тогда для перехвата домена нужно контролировать не одну ноду (собственную), а две — и вторая случайна.

С локальным кешем только тогда все плохо.
Да, без локального кеша вся идея идет лесом, ибо ни один роутер не выдержит нагрузки. Даже в кластере.

Еще есть вариант в полном распределении инофрмации. То есть, хранить данные не в пределах группы, а в максимально отдаленных друг от друга частях. А при резолве давать запрос к нескольким узлам и сравнивать ответы.

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

Скажем, для сайта habr.ru хэшировать не только «habr.ru», получая ноду 6d.32.fd.f6, но и «ur.rbah», получая ноду b6.05.fc.52
В принципе, одновременного запроса всего к двум таким нодам должно хватить…
Понятно, нужно анализировать хэш функцию, убеждаясь, что хэши от строки и обращённой строки никогда не приводят на один и тот же узел. В принципе, это вполне посильная математическая задача.
Хотя нет, первый вариант отпадает — если клиент всегда резолвит в группе, а не через нас — никакой мы не авторитетный резолвер.
Остается второй.

Сдается мне, что и регистрация выглядит иначе чем вы описываете. Здесь нужно регистрировать имя не на одной hash-node, а на всей ее группе — хотя тоже не без нюансов…
регистрация выглядит иначе чем вы описываете
Да, конечно такое возможно. Собственно вот вырезка из документа netsukuku.freaknet.org/doc/main_doc/andna.pdf

3.6 Registration step by step
1. The node n wants to register its hostname h,
2. it finds the rounded hash gnode rgH(h) and contacts, randomly, one of
its node. Let this node be y.
3. n sends the registration request to y. The request includes the public key
of the node n. The pkt is also signed with the private key of n.
4. The node y verifies to be effectively the nearest gnode to the hash gn-
ode, on the contrary it rejects the request. The signature validity is also
checked.
5. The node y contacts the counter gnode cr(n) and sends to it the IP, the
hash of th hostname to be registered and a copy of the registration request
itself.
6. cr(n) checks the data and gives its ok.
7. The node y, after the affirmative reply, accepts the registration request
and adds the entry in its database, storing the date of registration,
8. y forwards to its gnode the registration request.
9. The nodes, which receive the forwarded request, will check its validity and
store the entry in their db.

Собственно, ключевыми являются пункты 2,3,5,9. То есть, другие ноды, получив форвард каким то образом проверяют пакет. Мне только непонятно как они могут его проверить. Они же не знают, тем ли ключом подписано или не тем.

Ну и то что никакого авторитетного резолвера нет, ибо всегда выбирается случайный член группы
Плохо здесь все — не клиент регистрируется на множественных нодах, а hash-node после регистрации на себе раздает запись в группе.
Что мешает ей сразу присвоить запись и раздать в группе именно ее? Поди ее потом отбери.
Сheck its validity — это скорей всего обращение к hash-node — «мне тут какой-то форвард пришел, у тебя и в правду есть такая запись?» — защита от рассылки поддельных форвардов.
Спасибо за комментарии. Буду толкать эти мысли разработчикам.

Собственно утешает то, что до ANDNA дело еще не дошло. Это не более чем черновой вариант и разработчики сами это говорят. На данный момент отлаживается собственно уровень маршрутизации, обнаружения путей и т. д. ANDNA является прикладным сервисом, который крутится поверх сети.

В принципе, на первых порах, вполне можно было бы применять промежуточный вариант — обычные DynDns сервера с фиксированными адресами. Конечно, это будет централизация, но ее возможно прозрачно заменить в будущем. Ну и домены могут быть только третьего уровня.
Кстати, а с cache poisoning у нас что?
Я нода Y из «Распределенное кеширование запросов», кто мне мешает на все полученные запросы выдавать неверный резолв?
Этот резолв на X закешируется и далее лавиной. Рано или поздно этот кеш разбежится по всей группе — хотя она и посопротивляется :)
Вероятно проблема (и методы решения) того же плана, что и с злонамеренной хеш нодой.
У вас есть соображения относительно того, как можно разрешить ситуацию с минимальными проблемами?
Резолвить несколько раз через разные ноды, сверять результат, вносить в собственный кеш только после верификации?
Хотя как-нибудь элегантнее наверное можно…
Ну да, это первым приходит на ум. Но мне кажется можно что-нибудь придумать. Собственно, задача состоит в том, чтобы связать {IP, имя и ключ} в один триплет, не позволив участникам взаимодействия как-то повлиять на это. Как при регистрации, так и при резолвинге.
Вариант решения — при регистрации и резолвинге делать не один хеш доменного имени, а три (или больше) разными алгоритмами, соответственно у нас будут три абсолютно независимые хеш-ноды. Конфликты описанного типа разрешать автоматическим голосованием. Плюс можно придумать какое-то «занесение в чёрный список» спуфера.

Либо можно использовать не разные хеш-алгоритмы, а просто брать хеш не непосредственно от доменного имени, а добавлять к нему три разных окончания и строить хеши от трёх полученных разных строк (например, для «habr.ru» это могут быть «habr.ru.1», «habr.ru.2» и «habr.ru.3»).
Спасибо за комментарий! Однако буквально на днях я шарился в документации и нашел там именно второй вариант.

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

То есть, помимо распределения информации в пределах хеш группы, существует несколько таких групп. Соответственно, разрешение имени можно производить независимо по таким строкам для усложнения намеренного искажения информации отдельно взятой группой.

Конечно, от проблемы cache poisoning-а это не спасает.
Проблема со спуфером в том, что не совсем понятно как его вычислить. Ну то есть теоретически понятно, что если 9 нод говорят одно, а 1 другое, то скорее всего последняя гонит. Допустим ее адрес можно занести во временный черный список. Но вопрос в том, как определять правомерность занесения и критерии оценки.

А что есть крэкер намерено занесет 9 реальных нод в блеклист, а сам тем временем будет раздавать нужные ему адреса?

По идее, проверка должна осуществляться независимо, то есть узел может дать в запрос в сеть «Ребят, что-то мне не нравится вот этот товарищ. По моему, он что-то замышляет». Тогда, к примеру, другие узлы тоже могут попробовать разрезолвить такое имя самостоятельно и убедиться, что его данные отличаются от ответов остальных. Соответственно, они могут вести черные списки самостоятельно.
Можно сделать по аналогии с counter node — вычислять хеш от адреса хеш-ноды, на основании этого хеша получать адрес некой ноды, назовём её «сторожевой нодой» (guard node), и пусть уже она хранит информацию о благонадёжности хеш-ноды. Собственно, этот механизм можно использовать не только для случаев, когда нода выступает в роли хеш-ноды, но и практически для любых других, когда требуется независимая проверка доверия к ноде. И, кстати, вполне может быть, что этот механизм уже реализован — идея-то на поверхности лежит.
Поясните пожалуйста подробнее, что вы имеете в виду. Особенно как именно определяется благонадежность. Хранить то не проблема.
Благонадёжность (точнее, неблагонадёжность) определяется, как количество случаев несовпадения сопоставления IP-адреса имени. Т.е. предположим, что резолвится какое-то имя (тот же habr.ru). Кеширование пока не рассматриваем, чтобы не путаться.
1. Нода N хочет узнать IP-адрес по имени habr.ru. Она конструирует три строки («habr.ru1», «habr.ru2» и «habr.ru3»), для каждой вычисляет хеш и на основе их получает три адреса хеш-нод — HN1, HN2 и HN3.
2. Для каждого из этих адресов тоже вычисляется хеш и на основе этих хешей получаются три адреса соответствующих сторожевых нод — GN1 (для HN1), GN2 (для HN2) и GN3 (для HN3).
3. У полученных сторожевых нод спрашиваем про благонадёжность их подопечных.
4. Если всё нормально, то у каждой благонадёжной хеш-ноды спрашиваем IP-адрес имени habr.ru.
5. Если все ответы совпадают, то всё хорошо.
6. Если же один из ответов отличается от двух остальных (предположим, нода HN1 вернула неправильный ответ), тогда её сторожевой ноде (GN1) отправляем жалобу.
7. GN1 у себя увеличивает счётчик жалоб (который, собственно, и есть мера неблагонадёжности и который используется на шаге 3).

В случае, если на шаге 3 какая-то хеш-нода оказалась неблагонадёжной, можно прохешировать строку «habr.ru4» («habr.ru5» и т.д.) и повторить цикл ещё раз.
А как тогда разрешить ситуацию спекуляции?

Допустим, хакеру чудовищно повезло и одна из его подконтрольных групп является хеш группой для habr.ru (или google.com)

Однако имеется еще скажем 5 других хеш групп (и соответствующих им сторожевых нод)

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

Этого можно избежать, если вместо жалобы (и счетчика), будет посылаться «пакет недоверия», описанный выше. Тогда контрольный узел может сам проверить и убедиться что действительно, данная хеш группа гонит пургу.

Но в целом как то громоздко все получается. Слишком много перекрестных запросов, да и безопасность в целом несильно повышается.
С «пакетом недоверия» другая проблема — злоупотребляя им, можно попытаться завалить запросами честную хеш-ноду. В общем, нужно будет внимательно почитать доки и посмотреть, придумано ли для таких ситуаций что-нибудь.
можно попытаться завалить запросами честную хеш-ноду. Ну тут главное самому не сыпать запросами. Если пакеты недоверия «льются рекой», то тут не важно один пришел пакет или тысяча. Однажды проверив хост, можно закешировать это значение на некоторое время (вплоть до момента смены IP адресов). К тому же, сама сторожевая нода/группа уже может быть зафлужена этими пакетами.

Нет, не придумано. Сейчас авторы концентрируются на
самой сети, а не на безопасности сервисов (я говорил с ними).

Утешает то, что в случае ANDNA всегда можно внести изменения потом и сеть от этого не пострадает. Да и в любом случае, если интересует безопасность — надо использовать SSL.

Если есть желание, можно посидеть и попробовать написать свой документ, отражающий возможные пути решения проблемы.
Не, граждане, черные списки — зло. С ними приходится еще и систему контроля над черными списками устраивать — со своими черными списками :)
Голосования, кстати, тоже зло — хотя временами и неизбежное.
А вот резолвинг через триплеты — клевая идея, она помимо надежного резолвинга автоматически сессию удостоверяет — спускаем это с уровня приложения (SSL и проч.) на уровень сессии, где ему и место.
Вы сути списков не поняли. Бродкастится не информация «узел А гонит», а запрос «узел А подозрительный». Какой он на самом деле — решают сами узлы. Поэтому скомпрометировать напрямую нельзя.

Чем резолвинг «через триплеты» отличается от такового «голосованием»?
А если резолвить у хеш-нод, чьи адреса похожи на искомое значение, только разнести их по разным «мета группам». То есть «подняться вверх по иерархии» и «на самом верху», в каждой из тех групп, искать ноды, чьи адреса похожи на искомый хеш. Будем иметь несколько резолверов и не надо играться с разными вариантами имени.
А как решается проблема, когда два узла на «разных концах сети» (она ведь относительно медленно работает) почти «одновременно» сообщают о регистрации на себя доменного имени? Не получится ли, что два разных адреса будет соответствовать одному имени, причем с правильными с точки зрения каждого «dns-сервера» подписями?
Andna сервер для них будет один и тот же, и он не даст зарегистрировать это же имя второй раз.
Я правильно понял, что конкретный сервер зависит от хеша имени домена (или просто от имени домена)?
Да. Адрес хеш ноды, то есть, тот узел, который хранит у себя соответствие имени и текущего IP адреса определяется как хеш от имени.

То есть, у узла X может быть два имени, например habr.ru и habrahabr.ru. Причем эти имена будут лежать на совсем разных хеш нодах, поскольку их хеши различны.
А какой узел будет выполнять роль ANDNA сервера? Любой клиент, или это отдельно запрограммированный сервер? Просто, если это делает каждый клиент (что логично), могут возникнуть нежелательные эффекты. Например отдавать приоритет в очереди не так, как заложено в стандарте. Или еще лучше, «отбирать» имя до того, как истекут 30 дней бездействия.
А если это отдельный сервер, то тут появляется контролирующий орган, бюрократия и т.п.
Никаких серверов! Все делается средствами самих клиентов. Нежелательные эффекты возможны, но очень маловероятны. Не забывайте, что никто, включая непосредственных участников, не в курсе того что происходит на них. Вы понятия не имеете, какие имена будет хранить ваш узел. А если даже захотите намеренно искажать логику, то это не поможет. Для этого потребовалось бы изменить все 256 машин в группе. Оно надо? Самое главное что здесь нет корыстных интересов, потому что именно ваше имя будет храниться черт знает где.

Контролирующие органы убили бы идею на корню.
Почему же неизвестно какие имена хранит мой клиент? Например в ed2k запрос хоть и посылается к ближайшему вычисляемому по хешу, но посылается в открытом виде (все-таки коллизии возможны, поэтому отправлять хэш имени менее надежно). Но даже если в запросе имя домена не содержится, то что мешает перебрать короткие названия.
Конечно, самое больше препятствие для искажения информации, это отсутствие «хороших» имен, которые бы хотелось заполучить. Но как бороться просто с вредителями, которые будет выдавать ошибочную информацию? Видимо нужно делать дублирование имен на нескольких серверах (минимум трех), чтобы получить два одинаковых значения адреса?
Под «неизвестно» я понимал отсутствие какой либо определенности в том, что именно вы будете хранить интересующий вас домен.

Видимо нужно делать дублирование имен на нескольких серверах (минимум трех), чтобы получить два одинаковых значения адреса?

Прочитайте статью еще раз, вдумчиво, а не по диагонали. Там написано, что информация дублируется в пределах группы, а это 256 узлов. Чтобы исказить информацию, надо сломать их все.
Спасибо. Действительно написано про группу.
А как конкретный ANDNA-сервер решает должен ли он хранить это имя? По хешу имени, чтобы он относился к его группе? Тогда два вопроса: 1) хеш ANDNA-сервера может изменится со сменой его адреса; 2) не возникнет ли проблемы, что очень много имен придется хранить в одной группе и серверы не будут справляться с этой задачей?
Как я понимаю, решение хранить или не хранить имя домена не может основываться на адресе узла, т.к. этот адрес меняется, значит используется хеш от имени домена.
Ничего он не решает. Он просто распространяет всю имеющуюся у него информацию на все узлы своей группы — читай подсети (см. «Обеспечение избыточности»).

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

2) Не возникнет. Что значит не справляться? Хранить 20Кб текста это «не справляться»? Не забывайте, что информация кешируется и в других узлах. В отличие от DNS — чем популярнее узел, тем ниже получается нагрузка на хеш ноду (за счет того, что все и так знают его адрес).

Поверьте, систему делали далеко не дураки, предусмотрено и рассчитано было очень многое. Если уж так интересно — добро пожаловать в документацию, многие вопросы отпадут сами собой.
Верю.
Хранить 20Кб не сложно, даже 20Mb. Но, как понимаю, нужно не только хранить, но и отвечать на запросе. Все участники подобных сетей отвечают на запросы. У всех разные каналы. Хорошо, если 256 «серверов» будут работать по одинаковым данным. Плохо, если миллион запросов придет за короткое время, даже если их поделить на 256. Я понимаю, что очень далеко до момента, когда такая сеть обзаведется своим гуглом, да и не факт, что там будет необходимость или возможность для этого.
А как быть со случаем, когда node с нужным hash'ем не существует и пойдёт опрос соседей? Здесь есть какой-то порядок, или соседи случайно выбираются?
Там в статье было написано. Начнем с того, о каком случае ты говоришь. Если о резолве — то выбирается произвольный узел из хеш группы. Они все по определению имеют эту информацию. Так что хеш группа — это своеобразный кластер DNS серверов.

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

Когда отсутствующая группа/узел все же появится, то данные постепенно перетекут туда и все станет на свои места.
На самом деле, такая проблема существует. И я уже обращал внимание разрабов на этот момент. Вообще, проблема является шире, чем простая рассинхронизация. Может получиться так, что существует две полностью изолированные подсети со своими доменами имен. А потом появился узел, сшивший две подсети воедино.

В этот момент начинается мержинг адресных пространств, для исключения одинаковых адресов. И тут же происходит перераспределение имен. Если не ошибаюсь, то на данный момент применяется закон джунглей. Если в сети А и сети Б зарегистрировано одно и то же имя, то в сети А+Б будет оставлено то, чья сеть больше (больше узлов). Поскольку сеть анархическая, ее интересует выживание, а не жизнь отдельной клеточки-узла. Соответственно приоритеты смещаются в сторону большинства.

Ну и если чисто логически подумать. Вот есть огромная сеть на пару континентов, в ней имеются отображения гугловских серверов и зарегистрировано имя google.com И тут к ней подключается Вася Пупкин, который назначил, ради прикола, такое имя своей точке доступа, стоящей в дачном сортире. Как вы думаете, кому будет отдано предпочтение? :)

Есть и другой вариант: реализовать сложносоставные имена, включающие имена групп. То есть, в пределах своей сетки вы можете обращаться к соседнему компу как например fileshare. Но реальное имя узла будет что-то типа fileshare.mtuX.moscowY.russia которое формально не будет пересекаться с именем fileshare.neko8.kyoto.japan Но тут еще есть некоторые проблемы. Так что еще довольно много чего есть, что требует изучения.

Кстати тоже сразу такое в голову пришло. И это касается, наверное, не только доменов, но и IP-адресов. Но в принципе оба предложенных Вами варианта очень хороши. И они ещё лучше, если их комбинировать.
Правда по второму варианту не совсем понятно: как разграничить какой запрос идёт в «свою» сетку, а какой в общую… Всё-таки наверное принцип анархии и выживания более интересный, но тут вопрос в том, как посчитать кол-во всех узлов сети.
Правда всегда можно посчитать кол-во резолвов доменного имени на самой хеш ноде и сравнить этот счётчик с «конкурирующей». Однако и тут непонятно, как защитить сеть от всякого рода спуфинга.
Резолвов чего? В общем случае, одна хеш нода будет хранить только одно из имен интересующего нас узла. Так, имена habr.ru и habrahabr.ru будут храниться совсем на разных хеш нодах (ибо хеши от строк разные).
Резолвов (запросов от клиентов), собственно, имени, которое она обслуживает. И в случае «конфликта» сравнивать это кол-во с кол-вом на «конкурирующей» ноде.
М… На самом деле это не может считаться показателем, в основном из-за кеширования.

Например нода того же google.com может являться мегапопулярной, но за счет того, что ее адреса закешированы почти в каждой ноде сети, прямое разрешение имени будет требоваться очень редко.

В то же время, некоторый узел, на который какой то бот регулярно долбится, будет давать бо́льшие показатели.
Про кеш я тоже думал, но как-то забыл учесть его особую значимость в такого рода сети (привык уже к граблям традиционной DNS :) )
А может победит та нода, чей адрес ближе к хешу.
Не, с IP адресами все ро́вно. Процесс назначения и переназначения адресов полностью автоматизирован. Причем все сделано так, чтобы при изменении топологии сети, переадресация затронула бы как можно меньше узлов.

То есть, локальные передряги «в провинции» не должны сказываться на глобальных маршрутах и адресах «магистральных» узлов и групп второго порядка.

С FQDN именами проблема в том, что если полное имя формировать автоматически, то при переадресации где-то в середине, может измениться часть имени. Тогда получится что все предыдущие URL-ы станут недействительными, что недопустимо. Хоть это и происходит редко, но все равно.
ANDNA это спецсервера или функциональность будет встроена во все клиенты?
Если я себе правильно представляю, то тут аналог DHT/Kad: ищем хеш доменного имя (имя файла) на ближайшем по XORу адресе. А если через какое-то время появится другой адрес, еще более «близкий», то у него могут быть другие данные (как раз если слились две сети, такое обязательно получится). В результате, будет не поглощение крупными сетями, а просто сервером с более близким значением хеша.
Или все-таки будет несколько контролируемых ANDNA сервером со специфическим набором сервисов, исходники которых не будут доступны всем желающим?
habrahabr.ru/blogs/p2p/87424/#comment_2648627

Когда я говорил о мержинге адресных пространств, то операция производится осознано, а не абы как. Любая нода может узнать мощность каждого из подмножеств и на основании этого принимать решения.
А Вася может запустить миллион виртуальных узлов с миллионом уникальных адресов?
А какой смысл в виртуальных узлах, если адрес должен быть настоящий?
Если речь идет только о том, чтобы нахапать как можно больше имен, то в принципе это возможно. Но для того чтобы это осуществить, надо:

• На каждый виртуальный хост генерировать валидную связку ключей
• Производить полную процедуру внедрения в сеть
• Производить регистрацию имени штатными средствами
• Поддерживать регистрацию как самого узла так и его имени

Дополнительно следует отметить тот факт, что просто выдумывать адреса из головы нельзя — пакеты регистрации просто затеряются в сети и двустороннее взаимодействие вы установить не сможете.

Стоит ли оно того? Тем более что имена могут быть произвольного формата; здесь нет жестких требований, таких как в DNS. Это все равно что регистрировать акаунты в скайпе.

Если такой виртуальный улей не будет работать как настоящий участок сети — окружающие его ноды пошлют нафиг, ибо никакие маршруты через него не прокладываются. Соответственно, все регистрации отвалятся по таймауту. А если будет — да ради бога, сети от этого хуже не станет %)
Просто ты что-то выше писал про анархию и силу большинства. Вот я и подумал, имея достаточно мощный кластер, можно ли прогнуть под себя реальные сети?
Ну разве что кластер. Вообще, чисто интуитивно мне кажется что это возможно. Поскольку нет принципиальной возможности отличить реальный узел, от такого вот облака, скрывающегося за одной единственной точкой доступа.

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

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

Единственное что приходит на ум — внести некоторые алгоритмические особенности, которые бы привели к практической невыполнимости регистрации миллионов чего-либо за разумное время. Что сделало бы экономически неэффективным такие действия. Ну как происходит с тем же асимметричным шифрованием.
За статью спасибо. Думаю, уровень детализации как раз идеальный сейчас — кому нужно глубже, те, в основном, заинтересуются сильно глубже, а там уже логичней будет читать документацию.
Хорошо, тогда так и поступим. То есть, я буду стараться передать по максимуму основую мысль и идею, а отдельных интересных/нетривиальных случаях залезать глубже.
Во-первых, всё равно будут магистральные провайдеры, всё равно будет их оборудование, всё равно будет лицензирование этого оборудования, лицензии самих провайдеров и т.д. Так что проблемы бюрократии эта сеть не решает. Да и вообще, проблему бюрократии не может решить ни одна технология в принципе. Потому что это законы регулируют применение технологий, а не наоборот. И любая технология, как только она становится достаточно распространённой и начинает ограничивать чьи-то возможности/прибыли/… попадает под действие законодательных ограничений.

Во-вторых, не ясно как защитится от изменения данных относящихся к узлу А на узле Б узлом Б. Что мешает заинтересованной в доменном имени компании подкупить узел, на который попадает хеш, что бы он запись этой компании подвинул повыше в списке претендентов?

Так что мне что-то кажется, что проблемы останутся те же, только примут другой вид. А в маленьких сетях (не интересных юристам) и существующая технология не плохо работает.

К тому же вся инфраструктура сейчас заточена под конкретное применение, и на такие переделки никто не пойдёт. Тут на IPv6 никак не перейдут, хотя профит очевидеен (и даже подвижек не видно пока). А вы говорите нетсукуку.

Вопрос о техническом превосходстве обсуждать можно, но с точки зрения органзации всего этого дела новая технология не папнацея.
В комментариях к предыдущей статье, ближе к концу писали уже.
Хотя к концу цикла статей я и хауту наверное напишу :)
Было бы замечательно иметь DEB пакет :)
Ну .deb врядли, а .ebuild может и сделаю :)
Ну потому что я под гентой сижу. На самом деле там установки как таковой и нет. Это же питоновские исходники в основном.
ebuild пробегал на багзилле, но он нерабочий. думаю, многие были бы рады увидеть в своём локальном репозитории это чудо) а может и в дереве? ;)
Спасибо за статью! Как раз хотел почитать про ANDNA, т.к. было много неясностей в принципах работы. Сейчас стало много понятней.
Пожалуйста :) В принципе, если чего еще непонятно — можете писать в личку. Собственно, это ко всем относится.

На основании этой инфы можно будет понять, в какую сторону надо копать в следующих частях
На мой взгляд, поиск соседнего узла группы методом «научного тыка» неудачен. Даже если развить идею преобразования имени в некий адрес хеш-ноды и использовать принцип DHT, то:
— вероятность соответствия этого адреса «живому» узлу очень мала
— смысла «бомбить» удаленную группу наугад нет, поскольку при первой же неудачной попытке мы получим ответ от ближайшего соседа в цепочке маршрута. А поскольку имя способны резолвить все узлы группы, то достаточно получить ответ от любого «пограничного» узла группы.
Причем здесь метод тыка? Любой узел всегда знает всех своих непосредственных соседей в пределах группы. Это заложено в механизме маршрутизации. Удаленные группы достигаются через QSPN.
Метод тыка в том, что если не удалось попасть сразу в нужный адрес (или в группу), то начинается «обстрел наугад» соседних групп. А если в сети будут «пограничные» узлы, которые кешируют имена, проходящие через них, то достаточно будет только одного запроса в сторону искомой группы.
> Для этого, он вычисляет хеш от имени: h(«habr.ru») = 0x11223344. Числовое представление хеша трактуется как адрес узла, который будет считаться хранилищем. Это так называемая хеш нода (узел H).

1. Не понял. То есть из имени генерится хеш, который принимается в качестве адреса, и туда мы стучимся в поисках требуемого узла? А адрес себе можно взять любой, на свой выбор? А если два имени дадут один хеш, как делить адреса?

2. Позанудничаю: уже вторая статья, и я никак не могу привыкнуть к слову «нода». Есть слово «узел» мужского рода, и английское «node» обычно фонетически переносят как «нод», тоже мужского рода. И так было ещё во времена ФИДО. Слово «нода» в женском роде я наньше не встречал.

3. У меня была собственная идея «бесконфликтной» системы имён. Вот её описание в давнем посте на эту тему: habrahabr.ru/blogs/domains/28948/#comment_772444
1) Перечитайте первыую часть статьи. В следующей статье я более подробно распишу механизм маршрутизации, распределения адресов и поиска маршрутной информации. Но в общем случае, все происходит именно так, как вы написали. Адреса назначаются случайным образом, но коллизии разрешаются динамически, по мере изменения топологии сети.

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

2) Ну не знаю. Всю жизнь слышал именно такой вариант. Хотя в общем то хотелось писать везде «узел», но в случае с хеширующими узлами это звучит как-то длинно. Может быть, конечно, можно писать «хеш узел».

Самое главное что такая форма женского рода позволяет удобно согласовывать предложения за счет падежных оканчаний. А форма «нод» от этого страдает. Сравните:
• «нод А, подключившись к нод Б, не обнаружив нод С, сделал себе сепуку» и
• «нода А, подключившись к ноде Б, не обнаружив ноды С, сделала себе сепуку»

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

Во-вторых, форма [мужской род-родительный падеж] в единственном числе синтаксически эквивалентна форме множественного числа. По этому, вместо того что бы полностью использовать ресурсы внимания по назначению, мы тратим их на то, чтобы уловить из контекста о чем идет речь: об одном объекте или нескольких.

Одно дело, когда это художественная литература, и совсем другое, когда техническая документация.

Можно конечно попытаться писать «ноду Б», но это еще хуже имхо.

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

Ваш вариант интересен тем, что у каждого имени есть «рейтинг», по которому будет сортироваться список имен. Это очень удачно ложиться в мою концепцию (можете поискать в профиле).
Не пойму, почему, узлу нужно постоянно отслеживать оптимальный маршрут к каждому узлу группы? Ведь, в зависимости от положения в сети, это не всегда необходимо. Нужно знать только путь до серверов и до пограничных узлов.
А если вычислять оптимальный маршрут перед самой отправкой данных? Пример: узел «А» хочет установить соединение с узлом «Я»(структура сети известна); узел «А» отправляет трейс пакет(подобный QSPN) адресованный «Я», как только первый пакет достигает адресата, узел «Я» инициирует соединение до «А» по пути «пакета победителя». Так как структура сети известна — данный «флуд» можно направить приблизительно в сторону получателя и не грузить трафиком всю сеть.
Хотя скорость доставки пакета — это еще не признак широкого канала…
Вы вероятно не совсем правильно поняли. Маршруты строятся только до групп. Маршрутизация в ntk работает «на удачу». То есть, кидаем пакет, а там разберутся.

Трейс пакет не направляется кому-то конкретно. Трафиком вся сеть грузиться не будет. Один прошедший трейс флуд дает пользу всем узлам через которых он прошел.
Я предложил вариант на основании «своего видения».) Возможно я ошибался, считая, что маршруты строятся между узлами(нодами) внутри группы, а также, на уровень выше, между группами, и т.д. повышая масштаб(фрактал). Так же, мне казалось, что каждый узел начинает «флудить», чтобы получить карту группы и оптимальные маршруты. Я был не прав?
Сдается мне, что несмотря на то, что идея красивая, у неё нет будущего.
Как бы там ни было — все равно нужны будут «широкие» магистрали между городами, странами, континентами… Такие каналы не сможет иметь какой-то Вася Пупкин — ими будут владеть организации. А они, организации, будут хотеть «иметь деньги» за использование их магистралей:-) Соль в том, что трудно взимать плату с абонентов сети, где все анонимны. Конечно можно сделать их неанонимными, но это будет противоречить общей идее Netsukuku( Также, можно существовать «поверх интернета» — тогда это совсем не будет альтернативой.
Не все так плохо. Уже есть сырое решение в виде криптовалюты BitCoin, где каждый анонимус может платить не раскрывая себя. Насколько надежен данный алгоритм — покажет время.
Не забывайте про туннели. Никто не заставляет вас делать полностью независимую сеть (хотя это и возможно в теории).

Есть два города А и Б, в каждом из которых постепенно развивается своя подсеть. Затем энтузиасны из А и Б договариваются о пробросе туннелей между собой. Начиная с этого момента подсети объединяются в одну. С точки зрения остальных узлов это будет выглядеть так, как будто узел А и Б видят друг друга непосредственно.

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

Не надо смешивать технологию и идеологию ее использования.
К стати по поводу резолвера: можно в виде хеша получать не один адрес узла, а несколько. Пример: нечетные цифры хеша — один адрес, четные — другой. В итоге есть два узла, которые с трудом могут догадаться, какое они имя «хранят в сети». И хранят они, каждый, лишь часть адреса — клиент из этих частей соберет правильный адрес. В идеале таких узлов должно быть не два, а более.
Хочу сделать несколько утверждений, а потом на них основываясь предложить алгоритмы:

Утверждения
— В сети не может существовать уникальный идентификатор узла\ресурса\домена итп
— Каждый узел, при первом конекте может обменяться с другим узлом уникальными ключами между собой, для того чтобы в дальнейшем опознавать друг друга

Пример Алгоритма:
Я сделал сайт, назвал его habr.ru, набрал какое то количество посетителей, обменялся с каждым из них парой ключей.

Возможные ситуации:
Они знают мой ip, приходят ко мне, проверяют по ключу что это действительно тот сайт куда им надо.

У меня сменился ip. Клиент не смог его найти, через andna разресолвил habr.ru в мой новый ip авторизовался и все отлично.

Наша сеть нашла общую ноду и обьеденилась с еще одной сетью — и в этой сети тоже кто то уже зарегал habr.ru
В этом случае служба andna должна выдать мне ip ВСЕХ кто считает себя habr.ru
Я схожу на все эти ip, и там где я смог авторизоваться — это и есть нужный мне сайт.

Если же клиент впервые посещает habr.ru он выберет для себя один из них, какой больше понравится. Если же он ищет какой то конкретный ресурс, который ему кто то посоветовал, то вместе с именем он может попросить уточнить текущий ip сервиса.

Sign up to leave a comment.

Articles