Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 173
спасибо, познавательно.
но навскидку в России мало применимо из-за того что собственно инфраструктура не развита, разве что в милионниках, да и то далеко не всех.
но навскидку в России мало применимо из-за того что собственно инфраструктура не развита, разве что в милионниках, да и то далеко не всех.
Там смысл в том что для соединения сегментов можно пробрасывать туннели через интернет. Короче полная аналогия с ФИДО и нетгейтами. А так — чем больше узлов, тем надежнее и быстрее связь.
Все начинается с малого, готов поддержать.
Ребята в италии даже фидопойки устраивают. На озере «Bracciano». Правда это называется несколько не так, но суть та же. Они уже проводили тестирование какого то из протоколов меш сетей. Вроде как 802.11.
Может когда допилят сабж и с его потестят :) А так интересно было бы поучаствовать в подобном мероприятии.
Может когда допилят сабж и с его потестят :) А так интересно было бы поучаствовать в подобном мероприятии.
Очень перспективная технология, проблема одна — невозможность контроля государством может привести к законодательному запрету. Что запрещать? Да хотя-бы WiFi для «частников».
Вообще, я не очень силен в этом, подскажите кто знает — в целом, код на Питоне проигрывает по скорости коду на Си? Я имею в виду абстрактный «общий случай».
Вообще, я не очень силен в этом, подскажите кто знает — в целом, код на Питоне проигрывает по скорости коду на Си? Я имею в виду абстрактный «общий случай».
некорректно сравнивать интерпретатор и компилятор.
Ну раз так, ответ устроивает :) Просто мне почему-то интуитивно кажется ущербным делать главный демон обеспечения сети на языке-интерпретаторе… Остается одна надежда — на «гениальность» протокола маршрутизации, требующего сверхмалых ресурсов. Раз уж объявляют поддержку embedded-устройств, значит скорость работы кода не критична.
ну там же все написали, что фактически каждый узел работает максимум с 256 узлами, а сеть самоорганизующееся из других таких же узлов. Отсюда ясно видно что огромных ресурсов не нужно для обработки и интерпретатора хватит за глаза.
Питон позволяет компилировать код в байт-код, который выполняется быстрее, тем более есть такие замечательные вещи как py2exe ;)
Скорее всего переход на питон связан не со скоростью выполнения, а со скоростью разработки — отладка нужна. В дальнейшем всё равно будет на С переписан, чтобы на аппаратных маршрутизаторах мог работать.
py2exe всего лишь упаковывает интерпретатор питона и скомпилированные в байткод модули в один исполняемый файл. Что отрицательно сказывается на времени запуска.
некорректно лезть в тему, преварительно не выяснив, что питон умеет компилировать код
А по моему все корректно, если нас интересует скорость исполнения в итоге.
перспективная технология, проблема одна — невозможность контроля государством может привести к законодательному запрету.
Да, законодательные преграды — это основная проблема. И недавные посты про законодательные препоны открытому WiFi, тому подтверждение. Однако чтобы запретить Netsukuku по сути надо запретить WiFi маршрутизаторы совсем. Сеть не управляется никем, нет центра вроде трекеров, которые можно было бы атаковать юридически.
С этой точки зрения узел N ничем не отличается от просто точки доступа. Трафик шифруется, маршруты меняются непрерывно, так что в данные не залезешь.
Хотя конечно тупость законников и их кровожадность еще никто не отменял.
в целом, код на Питоне проигрывает по скорости коду на Си? Я имею в виду абстрактный «общий случай».
Я так понимаю что основным соображением была прозрачность кода и максимальное удобство отладки. Потом можно 10 раз переписать хоть на Си, хоть на ПЛИС реализовать.
Да, законодательные преграды — это основная проблема. И недавные посты про законодательные препоны открытому WiFi, тому подтверждение. Однако чтобы запретить Netsukuku по сути надо запретить WiFi маршрутизаторы совсем. Сеть не управляется никем, нет центра вроде трекеров, которые можно было бы атаковать юридически.
С этой точки зрения узел N ничем не отличается от просто точки доступа. Трафик шифруется, маршруты меняются непрерывно, так что в данные не залезешь.
Хотя конечно тупость законников и их кровожадность еще никто не отменял.
в целом, код на Питоне проигрывает по скорости коду на Си? Я имею в виду абстрактный «общий случай».
Я так понимаю что основным соображением была прозрачность кода и максимальное удобство отладки. Потом можно 10 раз переписать хоть на Си, хоть на ПЛИС реализовать.
Насчет законодательных препонов тут все просто. Даже в случае, если запретят, а юзеры будут юзать, то будут так же как с торрентами устраивать показательные порки, которые будут отбивать желание использовать такого рода свободную сеть.
Хотя, пока что трекеры все растут и растут, но все равно любой качающий, как правило в мозгу держит скрещенные пальцы «только бы не меня поймали, только бы не меня!».
Хотя, пока что трекеры все растут и растут, но все равно любой качающий, как правило в мозгу держит скрещенные пальцы «только бы не меня поймали, только бы не меня!».
В абстрактном общем случае — естественно проигрывает. На практике же, и код на Си, и код на Пайтоне, дёргает системные вызовы, и если основное процессорное время затрачивается именно на них — пофигу на чём писать. К тому же скорость может ограничиваться и другими факторами. Например, скорость скачивания файла из сети на 99% зависит от ширины канала, а не от языка, на котором написан даунлоадер.
идея хорошая, на фидо похожая просто жуть. Отцы основатели не фидошники часом? :)
Однако!
А вот я уже такое видел 8 лет назад: Р
очень похожее 9однорадговая сеть, передача по цепочку друг другу и все это на основе беспроводных технологий было реализовано… в… отечественном (!) массовом продукте под названием… :) Cybiko!!!
читаем тут ru.wikipedia.org/wiki/Cybiko
каждое устройство находит в радиусе до 100-120 метров (сам проверял) сородичей и со всеми одновременно поддерживает связь, со всеми можно переписываться в чате, играть с многопользовательские игры, также есть возможность передавать пакеты по цепочке (то есть можно 100 человек выстроить в линию, растянутой на пару километров и крайние смогут друг с другом переписываться (правда задержка будет… :))
и еще вкусность — если один из них подрубить к компу по usb кабелю и на компе есть инет — то инет появляется сразу на всех устройствах в радиусе тех же 100-120 метров :)))
эххх, вот млин умеют же наши делать…
очень похожее 9однорадговая сеть, передача по цепочку друг другу и все это на основе беспроводных технологий было реализовано… в… отечественном (!) массовом продукте под названием… :) Cybiko!!!
читаем тут ru.wikipedia.org/wiki/Cybiko
каждое устройство находит в радиусе до 100-120 метров (сам проверял) сородичей и со всеми одновременно поддерживает связь, со всеми можно переписываться в чате, играть с многопользовательские игры, также есть возможность передавать пакеты по цепочке (то есть можно 100 человек выстроить в линию, растянутой на пару километров и крайние смогут друг с другом переписываться (правда задержка будет… :))
и еще вкусность — если один из них подрубить к компу по usb кабелю и на компе есть инет — то инет появляется сразу на всех устройствах в радиусе тех же 100-120 метров :)))
эххх, вот млин умеют же наши делать…
Интересно, не слышал о таком. Ну а вообще меш сети то существуют уже давно, да и в научных изысканиях были замечены еще в 70х. Просто одно дело локальная (либо территориально-ограниченная) меш сеть, и совсем другое — сеть глобального уровня. Совсем другие проблемы на первый план выходят.
У меня был такой ;)Покупали сразу четыре в институте, для развлечения ;)
Классная вещь, и сеть работала забавно ;)
Плохо только, что памяти было мало. Чтобы на нём читать, приходилось делить книжку на несколько частей и заливать по очереди.
Классная вещь, и сеть работала забавно ;)
Плохо только, что памяти было мало. Чтобы на нём читать, приходилось делить книжку на несколько частей и заливать по очереди.
ага, до сих пор храню подготовленные таким методом по 500 килобайт разбитие книги (целая мини библиотека) на компе…
для увеличения места надо было докупать (а в америке потом вообще в подарок прилагалось) — внешний mp3 плеер — а нем место под SD карточку есть (до 2 гигов) и внешние кнопки для управления плеером.
кстати, а куда вы дели свои? — у моего экран разбился :(
PS готов купить парочку — вспомнить детство так сказать
для увеличения места надо было докупать (а в америке потом вообще в подарок прилагалось) — внешний mp3 плеер — а нем место под SD карточку есть (до 2 гигов) и внешние кнопки для управления плеером.
кстати, а куда вы дели свои? — у моего экран разбился :(
PS готов купить парочку — вспомнить детство так сказать
Идея вроде неплохая, попозже посмотрим (надеюсь).
А многих ли embedded устройств Python на борту?
А многих ли embedded устройств Python на борту?
гипертекстовый фидонет?
Я так понимаю специализированных устройств третьего уровня не существует? Роль маршрутизатора играет каждый отдельный узел?
Как тогда решить проблему траффико-тяжелых пользователей? Если такой юзер не имеет прямого выхода вовне группы, то он будет эксплуатировать нескольких соседей?
Как тогда решить проблему траффико-тяжелых пользователей? Если такой юзер не имеет прямого выхода вовне группы, то он будет эксплуатировать нескольких соседей?
Он будет эксплуатировать ВСЕХ соседей. Трафик шифруется и разбивается, после чего распределяется по разным маршрутам — чтобы нагрузка была распределенной, а не легла на один «самый оптимальный» маршрут.
А кто шифрует трафик? сами клиенты? а как проверить, что сообщение не подменено?
Неплохой подход, но однобокий. В таком случае сдвиг задержек будет немалым. Например, VoIP (и другой чувствительный к задержкам) траффик будет жестоко материть многоканальность с шифрованием на пару.
Как пишут сами авторы в FAQ, it depends. Это зависит от многих факторов: от каналов связи, от количества пиров на пути, от их загруженности и т. д.
Но на самом деле, при большом количестве узлов (например районная сеть), сеть будет работать даже лучше чем классическая. Именно из за многосвязности. В обычном случае вся нагрузка ложится на центральные маршрутизаторы. Соответственно если объявится сотня Васей Пупкиных, которые тянут кино с файлопомойки, то Петя Васькин уже испытывает проблемы.
Здесь же — нагрузка равномерно размазывается по всем нодам с учетом канала и т. д. Лейтенси конечно может быть повыше, но более равномерна.
Но на самом деле, при большом количестве узлов (например районная сеть), сеть будет работать даже лучше чем классическая. Именно из за многосвязности. В обычном случае вся нагрузка ложится на центральные маршрутизаторы. Соответственно если объявится сотня Васей Пупкиных, которые тянут кино с файлопомойки, то Петя Васькин уже испытывает проблемы.
Здесь же — нагрузка равномерно размазывается по всем нодам с учетом канала и т. д. Лейтенси конечно может быть повыше, но более равномерна.
да нет, выгоды никакой не будет. Всегда ограничителем является канал наружу, а обмен внутри районной сети не такой уж и большой. Смысл этой технологии — в отсутствии большого количества мелких провайдеров.
Явный минус — кто-то должен-таки обеспечить трафик в Интернет, так как часто, например в России, нет сплошного покрытия WiFi, и этот кто-то должен иметь возможность оплачивать этот трафик, то есть собирать деньги с пользователей сети — получается возврат к привычной схеме.
Явный минус — кто-то должен-таки обеспечить трафик в Интернет, так как часто, например в России, нет сплошного покрытия WiFi, и этот кто-то должен иметь возможность оплачивать этот трафик, то есть собирать деньги с пользователей сети — получается возврат к привычной схеме.
В следующей статье я хотел рассмотреть этот вопрос. Там фишка в том, что каналы выхода в инет могут предоставлять сами пользователи. Причем каждый от этого выигрывает. Если 10 человек предоставили канал по мегабиту, то каждый из них сможет лазить в сети со скоростью до 10 мбит (разумеется в зависимости от общей нагрузки).
Многие пользователи редко нагружают свой канал в интернет даже на половину. Поделившись им с соседом, можно получить более удобный для обоих серфинг в сети на двойной скорости.
Если таких людей много, то и выгода соответственная. Другое дело что у нас халяву любят, а вот делиться — не очень.
Многие пользователи редко нагружают свой канал в интернет даже на половину. Поделившись им с соседом, можно получить более удобный для обоих серфинг в сети на двойной скорости.
Если таких людей много, то и выгода соответственная. Другое дело что у нас халяву любят, а вот делиться — не очень.
Конкурент IPv6? =)
Я так понял, этот протокол стоит особняком от TCP/IP?
То есть, IP-адресации в нем нет как понятия?
То есть, в существующей инфраструктуре интернета со свякими NAT провайдеров этот протокол нежизнеспособен?
То есть, IP-адресации в нем нет как понятия?
То есть, в существующей инфраструктуре интернета со свякими NAT провайдеров этот протокол нежизнеспособен?
давно читал про эту штуку.вроде она работает на стеке TCP/IP, за исключение того что заменяет в нем протоколы адресации(IP,DNS). вместо DNS — DNS-anarchy, но на сколько я понял можно легко сделать гейт в интернет
Если я правильно понял, то да и цель сейчас начать распространять эту технологию, чтобы она в итоге присутствовала в любой ОС как тот же стек TCP/IP. Поначалу их пакеты будут «заворачиваться» в TCP/IP лишь бы отшлифовать алгоритмы и реализующее их ПО. Хотя в локальных сетях наверное можно использовать поверх Ethernet. Да звучит хорошо, только вот без поддержки провайдеров и производителей оборудования все будет глухо. Если исключить роутеры и NAT, то как тогда скрыть топологию «внутренней» корпоративной сети? А нет поддержки бизнеса, нет и технологии.
Хотя это больше замена IP протокола, но скорее всего и аналоги TCP, UDP и т.д. будут свои. Поправьте если глупость сказал.
Хотя это больше замена IP протокола, но скорее всего и аналоги TCP, UDP и т.д. будут свои. Поправьте если глупость сказал.
Нет, вы неверно поняли (или я неправильно объяснил). Подменяется только механизм маршрутизации. Все остальное остается на своих местах. Демон Netsukuku определяет только то, куда пойдет тот или иной пакет. А сами протоколы передачи остаются теми же.
Интернет может использоваться для туннелирования связи между удаленными анклавами или там, где невозможно установить прямое соединение. Плюс для собственно доступа в интернет организуются гейты, которые пробрасывают трафик наружу. Соответственно, чем больше гейтов, тем выше скорость инета в сети.
Интернет может использоваться для туннелирования связи между удаленными анклавами или там, где невозможно установить прямое соединение. Плюс для собственно доступа в интернет организуются гейты, которые пробрасывают трафик наружу. Соответственно, чем больше гейтов, тем выше скорость инета в сети.
Не эксперт я по сетям, но рискну спросить — если в каждый ТП прописывается полный маршрут, то в чем проблема отследить конкретного юзера если он занимается противозаконными вещами. Опять же, фидошником никогда не был, но мне всегда казалось что к любому фидошнику можно прийти ногами, так как это, по сути, сеть построенная на личных знакомствах (нода и поинта)…
Маршуры прописываются, но никуда не приводят. IP адреса назначаются случайным образом, причем в определенный момент целый регион может их поменять. Даже снифая трафик, вы понятия не имеете, куда в конце концов придет этот пакет.
Смотри, нет привычных протоколов маршрутизации -> нет необходимости в DNS -> нет необходимости в провайдерах -> нет привязки IP к географическому положению. Помимо этого, при попытке вклиниться в цепочку передачи данных, чтобы узнать куда они идут, ты ничего не получишь — тебе передадут зашифорованный послойно пакет (как в торе) с единственно доступной информацией — следующим узлом, кому надо ее передать. Географической привязки нет. Если это WiFi-узел, то возможна триангуляция и пеленгация. Но чтобы проследтить дальнейший путь пакета — надо найти ее с помощью радиооборудования (например, по пеленгу), физически захватить следующую ноду, получить над ней контроль — и все что ты получишь при этом, лишь адрес следующей транзитной ноды. Снова пеленг? А когда дело дойдет до границы государства, где кончаются правовые полномочия? С учетом этого, можно фактически утверждать, что отдельно взятая нода в такой сети, как netsukuku, физически неприступна — если только ищущему не повезло феноменально, и это оказалась физически соседняя с ним нода.
как связаны наличие протоколов маршрутизации и DNS? DNS нужен для нахождения параметров заранее неизвестного узла, зная изначально только IP адреса корневых DNS серверов. Если нет привычных протоколов маршрутизации и если для каждого входящего в сеть узла автоматически назначается IP адрес, то как тогда определить, что пользователь Вася@XX.XX.XX.XX, с которым вы общаетесь — это тот же самый пользователь Вася@YY.YY.YY.YY, с которым вы общались 2 недели назад?
Под пользователем понимается не только человек-пользователь, с которым можно обменяться авторизующими сообщениями, но и, например, сайт, живущий в Netsukuku. В обычном Интернете механизм миграции сервисов с одного IP адреса на другой основывается на DNS (и его различных инкарнациях, вроде mDNS). Если узел работает непостоянно, либо в случае сплита сети, то всё равно потребуется определённый «якорь», что бы находить информацию о новых IP знакомых ранее сервисов. Т.е. определённая иерархия всё равно потребуется.
GPG?
Описание звучит как настоящая уличная магия, я уже люблю этот протокол!
Мне кажется это неизбежно… с годами будут появляться независимые сети, не локальные сети между друзьями а именно независимые интернет сети, и возможно не будут соединяться при помощи глобального интернета, возможно и будут… но суть в том что это придет
Извиняюсь, но режет глаза используемая терминология. Интернет это имя собственное. Он один. Все остальное это не он. Лучше говорить глобальные, комплексные, составные — но не «интернет» сети.
А лучше, почитайте что он такое и как устроен. Познавательно.
А лучше, почитайте что он такое и как устроен. Познавательно.
Вы академически правы, черт возьми! Я рад за вас — удачи!
Не согласен, это как раз таки и есть современная неправильная терминология, то, что в данном случае академически употреблять «интернет» — неправильно, к сожалению да, но всегда были интранет и интернет сети, как быть с этим. Не смотря на недавно вышедшие поправки про употребление понятия «интернет» с большой буквы лично я для себя определил, что правильно употреблять интернет — да с маленькой буквы, и как обозначение именно глобальной/глобальных сетей. Как имя собственного «Интернета» не существует — сейчас под этим понятием принято обозначать гипертекстовое представление информации, с соответствующими технологиями, что никак не раскрывает всех возможностей сети, поэтому правильнее именно как интернет (с маленькой буквы, по аналогии интранету) обозначающее именно технологию глобальных сетей.
В нескольких (а не одной) независимых глобальных сетях не только нет смысла, потому что весь профит именно от соединения в глобальную сеть, а еще и дорого строить физический канал. Региональные независимые (военные, государственные) — да.
Я представлял себе немного иначе… имел ввиду что подобные сети будут строить корпорации. Хотя военные, государственные само собой.
тут предлагается что на начальном этапе на последней миле будет такая сеть, возможно с несколькими нодами с аплинком и через них доступ в глобальную сеть.
Тогда получается что TCP/IP будет заворачиваться в этот протокол? :)
Я бы с удовольствием послушал мнения специалистов, но учитывая сегодняшний праздник и завтрашнее похмелье…
Я бы с удовольствием послушал мнения специалистов, но учитывая сегодняшний праздник и завтрашнее похмелье…
авторитетно могут сказать наверно те, кто читал код или описание протокола.Я думаю что вернее сказать не TCP/IP будет «заворачиваться» а от нод сети будут идти запросы в интернет через TCP/IP, тоесть по сути эти ноды будут интернет гейтам.
Адрес хоста в глобальной сети нужно как-то передавать в пакете.
а чорт, извиняюсь. неправильно понял слово «заворачиваются» теперь понятно что вы имели ввиду. сейчас просматриваю доку, возможно я ошибался насчет полной замены ip, похоже он там всё-таки присутствует. похоже заменяются только протоколы маршрутизации и DNS. если так то пакет для интернета это обычный TCP/IP пакет, но тогда встает проблема чтобы внутренние ip не перекрывались Интернетовскими.
Товарищи, прочитайте еще раз статью! TCP никуда не девается! Изобретать велосипед не надо. Единственное что меняется — таблица маршрутизации ядра и DNS. Все остальное как было так и есть.
Кастувую вызов Мицгола, так как это долгожданный гипертекстово-векторный фидонет и есть.
Интересно, каких размеров будет время отклика, на больших растояниях (как я понимаю, промежуточных узлов будет порядком больше, чем в интернете)?
Ну, на примере скайпа… Разве такие большие задержки в скайпе?
Сам коннект бывает длительным, а потом все шустро. Тут, как я понял, в таком же виде будет существовать.
Разумеется всегда есть баланс. Несмотря на то, что интернет рассматривается авторами как «последняя надежда», скидывать его со счетов рановато :)
На начальном этапе будут организовываться анклавы регионального уровня, которые уже будут связываться аплинками через инет. То же самое и в случае наличия прямых, более удобных соединений. Поскольку протокол адаптивный, он обязательно найдет и будет использовать наилучший маршрут с минимальными задержками (ведь именно они определяются при TP флуде).
На начальном этапе будут организовываться анклавы регионального уровня, которые уже будут связываться аплинками через инет. То же самое и в случае наличия прямых, более удобных соединений. Поскольку протокол адаптивный, он обязательно найдет и будет использовать наилучший маршрут с минимальными задержками (ведь именно они определяются при TP флуде).
проект живет и здравствует а исходники на сайте страые. итоновские 2-5 лет, сишные 4-5 лет
на хабре вроде много профессионалов, может кто присоединится. вроде сишников и питонщиков должно быть много. может и мне пакет для федоры собрать…
Со времен прошлого упоминания на хабре mesh wifi сетей собирался запустить такое дома, вот и сейчас воодушевился, но приведенное выше лишь очередное(из множества) решение, как получается не первой свежести. Хочется поучаствовать в развитии и популяризации, но как определится, что из приведенного перспективно. Точно так же нашелся еще один проект tuxmobil.org/manet_linux.html Смысл в том, что не настолько силен в протоколах, чтобы определить на сколько данная реализация хороша.
Кстати так же не совсем ясно как данный проект использует wifi карту — запускается на существующем ad-hock подключении, или создает отдельно свое подключение, со своим режимом.
Кстати так же не совсем ясно как данный проект использует wifi карту — запускается на существующем ad-hock подключении, или создает отдельно свое подключение, со своим режимом.
Ответ на свой вопрос: Необходима Wi-Fi сетевая карта. Переведите её в состояние готовности (ad-hoc) используя «netsukuku» как essid
соль netsukuku в том, что это целостная сеть, тоесть неважно вайфай или ethernet или всё вместе, она самоорганиюующаяся, так что не нужно никаких огромных корневых маршрутизаторов. в теории(в идеальном мире) она может полностью заменить Интернет. другие подобные проекты (из тех, что я видел) концентрируются на последней миле или на локальных сетях.
всё это выглядит очень сладко, наверно даже слишком сладко чтобы быть правдой, поэтому я начал читать документацию.
пока возник вопрос(к знающим), разве, если сеть выростет до размеров интернета, TP Flood не убьет всю сеть?
всё это выглядит очень сладко, наверно даже слишком сладко чтобы быть правдой, поэтому я начал читать документацию.
пока возник вопрос(к знающим), разве, если сеть выростет до размеров интернета, TP Flood не убьет всю сеть?
Действительно отличие, надо присмотреться…
сам нашел ответ на свой вопрос, собственно он и в статье есть. невинмательно читал видимо
Сами авторы описывают вторую версию протокола как немобильную. Подразумевая, что новые точки появляются сравнительно редко. Сама маршрутная информация распространяется тоже постепенно, мгновенного обновления здесь не надо.
Соль в том что даже только подключившийся клиент (еще не зная ничего) уже может цепляться к хосту «на другом конце планеты». Пакеты все равно дойдут за счет того, что маршрутная информация есть у других узлов.
Наконец, сам TP флуд только звучит страшно, а на деле он получается гораздо менее агрессивным чем обычный ICMP трафик. Не забывайте, что пакет в рамках одного флуда проходит заданный узел только один раз, а затем очень быстро режется (колец не возникает). Таким образом нагрузка на сеть в итоге сравнима с обычной процедурой трассировки удаленного хоста.
С разрастанием сети, возможно, будут приняты дополнительные меры к соркащению количества таких пакетов. Например, чтобы узлы старались по возможности использовать маршрутную информацию соседних нод, а не флудить. Ну а потом по чуть-чуть наращивать свои собственные знания.
Соль в том что даже только подключившийся клиент (еще не зная ничего) уже может цепляться к хосту «на другом конце планеты». Пакеты все равно дойдут за счет того, что маршрутная информация есть у других узлов.
Наконец, сам TP флуд только звучит страшно, а на деле он получается гораздо менее агрессивным чем обычный ICMP трафик. Не забывайте, что пакет в рамках одного флуда проходит заданный узел только один раз, а затем очень быстро режется (колец не возникает). Таким образом нагрузка на сеть в итоге сравнима с обычной процедурой трассировки удаленного хоста.
С разрастанием сети, возможно, будут приняты дополнительные меры к соркащению количества таких пакетов. Например, чтобы узлы старались по возможности использовать маршрутную информацию соседних нод, а не флудить. Ну а потом по чуть-чуть наращивать свои собственные знания.
Загляните в SVN, там посвяжее.
да, сапсибо с SVN уже скачал и запустил, правда пока дело дальше не дошло
Если будет желание, можно попробовать организовать русскоязычное сообщество и каким либо образом поддержкать проект. К слову на IRC канале и русскоязычый народ тусит.
оке. по работе аврал закончится, загляну. спасибо за хороший обзор, я про эту сеть года 2 назад читал, но очень поверхностно, уже тогда разочаровала динамика появления новых версий. сейчас вот опять загорелся. может и питон заодним выучу :-D
Да, к сожалению они не особенно торопятся. Ну либо просто лень сайт поддерживать в актуальном состоянии. Если что, обращайтесь — помозгуем.
я просто не думаю что без поддержания сайта в актуальном состоянии можно собрать достаточно большое community. в community должны быть не только разрабы но и пользователи, которые по сарафанному радио делают пиар. мне кажется на сайте должны быть последние сырцы и бинарные пакеты(.deb,.rpm), также класно бы сделать стикеры в .svg типа «тут работает N, подключайся»
что-то я не въеду.
куда оно широковещательные пакеты рассылают?
на IP — в локальную подсетку, на eth — тупо в сегмент?
и если в моей домашней подсетке или подъездном езернет сегменте нет никого уже замаршрутизировавшегося в сеть — всё это великолепие лососит тунца ровно тех протоколов поверх котрых построено.
а если есть — то это шлюз в другую подсетку или сегмент, ну или точка доступа вайфайная.
в чём приемущества такой «децентрализации»?
куда оно широковещательные пакеты рассылают?
на IP — в локальную подсетку, на eth — тупо в сегмент?
и если в моей домашней подсетке или подъездном езернет сегменте нет никого уже замаршрутизировавшегося в сеть — всё это великолепие лососит тунца ровно тех протоколов поверх котрых построено.
а если есть — то это шлюз в другую подсетку или сегмент, ну или точка доступа вайфайная.
в чём приемущества такой «децентрализации»?
Вы мыслите категориями традиционной, предустановленной маршрутизации. Когда она объявлена свыше. Админом сети, провайдером и т. д. Здесь смысл несколько иной.
Во-вторых любой P2P начинает хорошо работать тогда, когда много узлов в пределах досягаемости. Чудес не бывает.
Во-вторых любой P2P начинает хорошо работать тогда, когда много узлов в пределах досягаемости. Чудес не бывает.
Насколько я понял из FAQ будут строить «анклавы», где узлы связанные или витой парой или wifi-ем находят друг-друга простым броадкастом. В анклавах будут ставить один или несколько шлюзов, которые с помощью туннелей поверх (TCP|UDP)/IPv4 (вообще, похоже нет разницы поверх чего, предлагают даже поверх Tor-a) будут связываться с другими анклавами и таким образом образуют большой Netsuku_VPN.
И вот в этом иеархиеском нечто будет рулить QSPN.
Получается если в анклаве всего один шлюз, который связывается с другими анклавами через один ISP, то все проблемы ISP будут проблемами анклава. А вот если использовать несколько шлюзов, да еще чтоб каждый выходил через свой ISP, то связь с другими анклавами будет очень устойчивой.
Интересно, как трафик будет балансироватсья между шлюзами и что там с QoS? Не нашел этого в FAQ.
И вот в этом иеархиеском нечто будет рулить QSPN.
Получается если в анклаве всего один шлюз, который связывается с другими анклавами через один ISP, то все проблемы ISP будут проблемами анклава. А вот если использовать несколько шлюзов, да еще чтоб каждый выходил через свой ISP, то связь с другими анклавами будет очень устойчивой.
Интересно, как трафик будет балансироватсья между шлюзами и что там с QoS? Не нашел этого в FAQ.
а. воначто.
я не углублялся в FAQ, и поэтому решил, что эта система работает на основе уже существующего,
тоесть надо буквально поставить софт и всё поедет, типа как скайп.
если надо строить некие анклавы, ставить шлюзы — тогда в принципе понятно.
но тогда для работы системы надо поднимать массы и вести рекламно-пропагандистскую деятельность.
взламывать и перепрограммировать свитчи и рутеры, например…
я не углублялся в FAQ, и поэтому решил, что эта система работает на основе уже существующего,
тоесть надо буквально поставить софт и всё поедет, типа как скайп.
если надо строить некие анклавы, ставить шлюзы — тогда в принципе понятно.
но тогда для работы системы надо поднимать массы и вести рекламно-пропагандистскую деятельность.
взламывать и перепрограммировать свитчи и рутеры, например…
> и поэтому решил, что эта система работает на основе уже существующего,
тоесть надо буквально поставить софт и всё поедет, типа как скайп.
Как я понял, так оно и есть :) Анклавы сами будут получатся, когда больше двух человек в сетке поставят демон, а туннели будут поднимать те, кто выходит в инет или в другую сеть IPv6, tor и т.п.
> взламывать и перепрограммировать свитчи и рутеры
Зачем? Этого похоже не надо.
тоесть надо буквально поставить софт и всё поедет, типа как скайп.
Как я понял, так оно и есть :) Анклавы сами будут получатся, когда больше двух человек в сетке поставят демон, а туннели будут поднимать те, кто выходит в инет или в другую сеть IPv6, tor и т.п.
> взламывать и перепрограммировать свитчи и рутеры
Зачем? Этого похоже не надо.
Достаточно наладить связь с проектами открытых прошивок для роутеров и помочь им в реализации этого функционала.
Доменные имена в ANDNA хранятся 3 дня, и если не обновлять, то можно потерять их. И что произойдет с доменными именами, если будут существовать несколько раздельных Nesukuku сетей, которые потом объединятся? Получается что кто-то потеряет свои имена. Это же будет война в сети.
Ну во-первых, вы не скованы жесткими рамками именования, как в традиционном DNS. Во-вторых авторы на этот счет уже говорили что-то о сертификатах и т. д. То есть возможно что ваше имя навсегда останется с вами. Киберсквоттеров будут огораживать путем ограничения количества имен на узел (хотя тут тоже не все ясно).
Боюсь, в случае роста сети бюрократия в стиле InterNIC и IANA неизбежна.
Сколько, говорите, планируют брать за сертификаты. А как будет контролироваться соблюдение связки сертификат-адрес?
Сколько, говорите, планируют брать за сертификаты. А как будет контролироваться соблюдение связки сертификат-адрес?
у кого-нибудь получилось завести?
я с питоном незнаком
я с питоном незнаком
[max@localhost pyntk]$ sudo ntkd
Traceback (most recent call last):
File "/usr/bin/ntkd", line 30, in <module>
from ntk.lib.micro import allmicro_run
File "/usr/lib/python2.6/site-packages/ntk/lib/micro.py", line 21, in <module>
import stackless
ImportError: No module named stackless
[max@localhost pyntk]$ python -c "import sys;import stackless;print(sys.version);print(stackless)"
2.6.4 Stackless 3.1b3 060516 (release26-maint, Mar 8 2010, 08:05:12)
[GCC 4.4.3 20100127 (Red Hat 4.4.3-4)]
<module 'stackless' (built-in)>
завелся. для тех кто тоже хочет обьясню в чем была проблема. питон у меня уже стоял(с бинарником в /usr/bin), я поставил stackless из сурсов(Бинарник установился в /usr/local/bin) а в ntkd прописано /usr/bin/python
Теперь вроде запустился так
[max@localhost pyntk]$ sudo /usr/local/bin/python ntkd
Нужно тесты позапускать
Теперь вроде запустился так
[max@localhost pyntk]$ sudo /usr/local/bin/python ntkd
Нужно тесты позапускать
stackless python, насколько я понял позволяет выполнять syscall-ы из питона. он нужен для запуска netsukuku. rpm найти не удалось, собрать rpm скриптом из дистра тоже, нужно будет вручную попробовать. сурсы можно качнуть тут zope.stackless.com/download/sdocument_view установка стандартная ./configure;make;sudo make install
ну и ещё добавлю что stackless python это не модуль к питону, а его модификация, такчто будьте внимательны
надеюсь комунибудь будет полезна моя писанина
ну и ещё добавлю что stackless python это не модуль к питону, а его модификация, такчто будьте внимательны
надеюсь комунибудь будет полезна моя писанина
Интересная технология. В следующих обзорах было бы приятно увидеть побольше картинок, а то на словах не очень легко всё воспринять.
Есть пару вопросов:
1) Какова максимальная пропускная способность сети?
2) Как я понимаю, что бы соединиться с компьютером в Африке, нужно составить цепочку нодов от моего до конечного компьютера; учитывая, что в Wi-Fi радиус не очень большой, для этого нужно иметь довольно большую плотность распространения компьютеров. Или я что-то упустил из виду?
Есть пару вопросов:
1) Какова максимальная пропускная способность сети?
2) Как я понимаю, что бы соединиться с компьютером в Африке, нужно составить цепочку нодов от моего до конечного компьютера; учитывая, что в Wi-Fi радиус не очень большой, для этого нужно иметь довольно большую плотность распространения компьютеров. Или я что-то упустил из виду?
Давно интересуюсь этим проектом. Но возникли вопросы, на которые нигде не могу найти ответов:
1) что с IP-адресами? Я так понял из wiki и бегло просмотренных официальных PDF`ок, что IP адреса выделяются процедурой маршрутизации (т.к. отображают все возможные узлы, подключающиеся и отключающиеся, на пространство IPv4/v6). Как тогда разрешаются конфликты между узлами, имеющими одинаковые IP? А если каждый узел видит свою собственную картину в IP пространстве, то как предлагается обеспечивать связь между двумя незнакомыми узлами?
2) Есть ли реальная wifi сеть Netsukuku в Москве? А реальная сеть, к которой можно реально подключиться через IP-туннель? Статья в википедии кардинально не менялась с 2008 года, а есть ли реальные howto для желающих работать с использованием Netsukuku?
1) что с IP-адресами? Я так понял из wiki и бегло просмотренных официальных PDF`ок, что IP адреса выделяются процедурой маршрутизации (т.к. отображают все возможные узлы, подключающиеся и отключающиеся, на пространство IPv4/v6). Как тогда разрешаются конфликты между узлами, имеющими одинаковые IP? А если каждый узел видит свою собственную картину в IP пространстве, то как предлагается обеспечивать связь между двумя незнакомыми узлами?
2) Есть ли реальная wifi сеть Netsukuku в Москве? А реальная сеть, к которой можно реально подключиться через IP-туннель? Статья в википедии кардинально не менялась с 2008 года, а есть ли реальные howto для желающих работать с использованием Netsukuku?
1) IP адреса назначаются случайно, но по определенным законам :) В случае объединения двух подсетей с перекрывающимися диапазонами применяется хитрый алгоритм голосования, о котором я напишу в следующей статье, в результате которого одна из подсетей выберет себе новые адреса. Таким образом две подсети объединятся в одну, где все адреса будут уникальны.
2) Нет, сейчас технология находится на стадии обкатки и отлаживания софта. С документацией в проекте плоховато, но можно глянуть здесь: netsukuku.freaknet.org/doc/main_doc/ А вообще наблюдается некоторое несоответствие между доками и реальностью. Как говорится, смотрите в исходниках. Надеюсь что это дело будет исправлено. Ну может и сам этим займусь. Howto есть там же
2) Нет, сейчас технология находится на стадии обкатки и отлаживания софта. С документацией в проекте плоховато, но можно глянуть здесь: netsukuku.freaknet.org/doc/main_doc/ А вообще наблюдается некоторое несоответствие между доками и реальностью. Как говорится, смотрите в исходниках. Надеюсь что это дело будет исправлено. Ну может и сам этим займусь. Howto есть там же
Вот тут написано про адресацию. netsukuku.freaknet.org/2html/documentation/main_documentation/topology.pdf Адрес в netsukuku совместим и с IPv4 и c IPv6. В зависимости от того, что выберут, такой размер сети и получится.
Адрес сам по себе содержит путь до узла в глобальной иерархии: т.е. в последний октете — номер узла в его gnode (объединение до 256 узлов), второй — номер gnode в ggnode (объединение до 256 gnod-ов) и т.д. до самого первого октета, который объединяет все g...gnod-ы в один большой узел. Мобильные адреса не поддерживаются, поэтому похоже в каждом новом месте будет новый адрес.
Связь за счет протокола QSPN: netsukuku.freaknet.org/2html/documentation/main_documentation/qspn.pdf Как я понял какая-то рекурсия которая работает для всех уровней одинаково, хотя могу ошибаться, так как глубоко не копал.
Объединение и дробление (g+)node, как я понял, будет происходить автоматически при росте и уменьшении сети, т.е. эффективное использование адресного пространства должно быть очень плотным, не то, что сейчас в IPv4 и планируется в IPv6. Хотя как это будет происходить я не нашел. Про конфликты я тоже не нашел, может их там и не будет, раз все автомагически.
Какие-то howto нашлись здесь: netsukuku.freaknet.org/index.php?pag=documentation&dir=howto
На остальные вопросы ответов не знаю :)
Адрес сам по себе содержит путь до узла в глобальной иерархии: т.е. в последний октете — номер узла в его gnode (объединение до 256 узлов), второй — номер gnode в ggnode (объединение до 256 gnod-ов) и т.д. до самого первого октета, который объединяет все g...gnod-ы в один большой узел. Мобильные адреса не поддерживаются, поэтому похоже в каждом новом месте будет новый адрес.
Связь за счет протокола QSPN: netsukuku.freaknet.org/2html/documentation/main_documentation/qspn.pdf Как я понял какая-то рекурсия которая работает для всех уровней одинаково, хотя могу ошибаться, так как глубоко не копал.
Объединение и дробление (g+)node, как я понял, будет происходить автоматически при росте и уменьшении сети, т.е. эффективное использование адресного пространства должно быть очень плотным, не то, что сейчас в IPv4 и планируется в IPv6. Хотя как это будет происходить я не нашел. Про конфликты я тоже не нашел, может их там и не будет, раз все автомагически.
Какие-то howto нашлись здесь: netsukuku.freaknet.org/index.php?pag=documentation&dir=howto
На остальные вопросы ответов не знаю :)
Т.е., получается, что nskk — полностью приватная сеть, для маршрутизации в Интернет придётся прибегать к помощи NAT — т.е. не получится использовать стандартные приватные подсети? Интересно, а софт, который sNAT`ил бы nskk-пространство адресов в такую приватную подсеть, вроде 10.42.*.* — уже написан? Если нет, то, похоже, проект ещё долго будет развиваться до стадии альфа-версии…
в адресном пространстве IPv6, современный v4 инет можно уложить несколько миллиардов раз. В простейшем случае можно мапить современные адреса в специальный IPv6 адрес с зарезервированным префиксом.
Собственно, freenet6 так и делает. Да и процедура миграции на IPv6 предусматривает создание специальных гейтов между v6 и v4 кои в инете уже работают (у нормальных провайдеров).
Но в общем случае просто маршрутизировать адреса естественно нельзя.
Собственно, freenet6 так и делает. Да и процедура миграции на IPv6 предусматривает создание специальных гейтов между v6 и v4 кои в инете уже работают (у нормальных провайдеров).
Но в общем случае просто маршрутизировать адреса естественно нельзя.
Понравилась фраза Close the world, txEn eht nepO на главной. Но ни она, ни Lain в комментариях не светилась еще. Интересно, неужели я один видел это аниме?
Несмотря на то что Netsukuku очень красиво выглядит, практически она навряд-ли «взлетит» (по крайней мере в ближайшее время). Не помню где видел расчёты скорости для p2p wireless сетей — при наличии всего одного передатчика на роутере и соединении нескольких таких устройств в цепочку скорость будет стремиться к нулю нелинейно и весьма быстро, а задержка и количество коллизий возрастать. Также добавляем сюда общую загрязнённость диапазона 2.4 (интерференцию).
По этим расчётам более-менее приемлемая скорость в mesh-сети возможна только при наличии большого количества подключений к скоростной проводной магистрали и наличии на каждом устройстве не менее трёх передатчиков с разными частотами. Одна из частот используется для раздачи клиентам, другие две для связи точек между собой и возможно разделения направлений трафика. Причём всей этой сетью ещё желательно централизованно управлять и правильно назначать частотные каналы для снижения интерференции (примерно так как сейчас сотовые операторы осуществляют частотное планирование).
Вот что-то нашёл по теме:
www.strixsystems.com/products/datasheets/StrixWhitepaper_Multihop.pdf
www.belairnetworks.com/resources/pdfs/Mesh_Capacity_BDMC00040-C02.pdf
Так что одними красивыми программными абстракциями проблему не решить (есть кстати куча других протоколов маршрутизации, например OSLRP: www.olsr.org/?q=about). Единственное что может тут помочь из программной части — технологии FIDO, т.е. сессионная передача данных. Юзер в оффлайне пишет сообщение, оно где-то складируется на пограничном узле и затем в отведённое время вместе с другими такими же отправляется дальше. Но увы, все привыкли к интерактивному вебу, онлайн-видео, системам мгновенного обмена сообщениями и во времена ФИДО уже не хотят.
По этим расчётам более-менее приемлемая скорость в mesh-сети возможна только при наличии большого количества подключений к скоростной проводной магистрали и наличии на каждом устройстве не менее трёх передатчиков с разными частотами. Одна из частот используется для раздачи клиентам, другие две для связи точек между собой и возможно разделения направлений трафика. Причём всей этой сетью ещё желательно централизованно управлять и правильно назначать частотные каналы для снижения интерференции (примерно так как сейчас сотовые операторы осуществляют частотное планирование).
Вот что-то нашёл по теме:
www.strixsystems.com/products/datasheets/StrixWhitepaper_Multihop.pdf
www.belairnetworks.com/resources/pdfs/Mesh_Capacity_BDMC00040-C02.pdf
Так что одними красивыми программными абстракциями проблему не решить (есть кстати куча других протоколов маршрутизации, например OSLRP: www.olsr.org/?q=about). Единственное что может тут помочь из программной части — технологии FIDO, т.е. сессионная передача данных. Юзер в оффлайне пишет сообщение, оно где-то складируется на пограничном узле и затем в отведённое время вместе с другими такими же отправляется дальше. Но увы, все привыкли к интерактивному вебу, онлайн-видео, системам мгновенного обмена сообщениями и во времена ФИДО уже не хотят.
Разумно. Но в принципе, зная географию точек (а она известна маршрутизаторам), можно решать задачу разделения частот автоматически. На ум приходит задача раскраски карты: ru.wikipedia.org/wiki/Проблема_четырех_красок
Представьте, что каждый цвет это одна несущая. Ломаные кривые — интерференция на сложном рельефе. Доказано, что всякую двумерную карту можно раскрасить четырьмя цветами, так чтобы по каждую сторону линии цвета были различны:
Соответственно, можно аккуратно расходовать частотный ресурс.
Во-вторых, современные вафли вполне себя комфортно чувствуют. Лично я не наблюдаю особых проблем с полосой, хотя вокруг довольно много точек. В случае если эти точки принадлежат нашей сети, можно даже предусмотреть механизмы автоматической подстройки мощности передатчика, дабы не перегружать эфир там где точек и так много.
Представьте, что каждый цвет это одна несущая. Ломаные кривые — интерференция на сложном рельефе. Доказано, что всякую двумерную карту можно раскрасить четырьмя цветами, так чтобы по каждую сторону линии цвета были различны:
Соответственно, можно аккуратно расходовать частотный ресурс.
Во-вторых, современные вафли вполне себя комфортно чувствуют. Лично я не наблюдаю особых проблем с полосой, хотя вокруг довольно много точек. В случае если эти точки принадлежат нашей сети, можно даже предусмотреть механизмы автоматической подстройки мощности передатчика, дабы не перегружать эфир там где точек и так много.
Спасибо за отличную статью, я писал про похожую сеть I2P только она по верх интернета, эта — намного интересней! было бы замечательно почитать еще статьи про эту сеть!
Никто не подскажет как собрать и поднять это чудо на Ubuntu? после скачки по SVN
Товарищ 1amer описал чуть выше свой опыт, правда безотносительно дистрибутива: habrahabr.ru/blogs/p2p/86702/#comment_2594736 (окружающие комменты тоже интересны)
это не аналог Freenet. Netsukuku может работать без Интернета, может работать вместо Интернета(на не без протоколов которые в нем используются), Freenet не маршрутизирует трафик(на network layer) и имеет такие возможности как шифрование и передача файлов.
я даже больше скажу freenet может работать поверх netsukuku
я даже больше скажу freenet может работать поверх netsukuku
Такой вот вопрос:
Если я запущу демон netsuku и натравлю его на интерфес, через который я в данным момент подключен в инету, то соединение оборвется?
Или можно сделать как при подключении к VPN, когда openvpn создает еще один интерфейс, типа tap0, который работает через ту же сетевуху, что и eth0, но при этом не обрывает последний?
Если я запущу демон netsuku и натравлю его на интерфес, через который я в данным момент подключен в инету, то соединение оборвется?
Или можно сделать как при подключении к VPN, когда openvpn создает еще один интерфейс, типа tap0, который работает через ту же сетевуху, что и eth0, но при этом не обрывает последний?
Да. Демон подразумевает что IP адреса назначаются им. В настройказ, однако же, указываются параметры. А именно, режим адресации (совместимый с инетом, независимый, етц) и наличие линка на инет с соответствующими параметрами. Исходя из этого уже оно и рабтает.
Если грамотно настроить, то интернет никуда не денется. Вы так же сможете в него лазить, просто локальные адреса будут другими.
Если грамотно настроить, то интернет никуда не денется. Вы так же сможете в него лазить, просто локальные адреса будут другими.
У нас всяческие Россвязьнадзоры запретят использование таких сетей, либо заставят производить лицензирование, что, в общем-то, убивает саму идею.
Ну а чем со стороны оно отличается от самого обычного вайфая? Либо все точки доступа надо запретить на корню, либо оставить все как есть. Поскольку диапазон 2.4 является нелицензируемым и мощность передатчика не превышает определенного уровня, то предраться в общем-то не к чему.
Хотя наши законники всегда отличались «любовью» к подобным вещам. С другой стороны, если например попытаться пропихнуть это дело как нац проект, объяснить возможность использования данной технологии для дешевого и эффективного покрытия связью всяческих зажопинсков, то может быть что-то и выгорит. Написать Медведу напрямую, наконец.
Плюс к тому: habrahabr.ru/blogs/p2p/87424/#comment_2647320
Хотя наши законники всегда отличались «любовью» к подобным вещам. С другой стороны, если например попытаться пропихнуть это дело как нац проект, объяснить возможность использования данной технологии для дешевого и эффективного покрытия связью всяческих зажопинсков, то может быть что-то и выгорит. Написать Медведу напрямую, наконец.
Плюс к тому: habrahabr.ru/blogs/p2p/87424/#comment_2647320
Спасибо за благую весть!
Ещё 10 лет назад, учась в ВУЗе я высказывал нашему преподу по сетям подобную идею и даже прорабатывал алгоритмы, но меня никто не поддержал — тогда это было ещё не так понятно и актуально.
В перспективе я формулирую эту идею как виртуальное государство, которое не зависит от «реальных» государственных служб и корпораций. Люди смогут напрямую без посредников обмениваться информацией и принимать решения. Осталось сделать только «пиринговую валюту» и будет достигнута полная социальная децентрализация — вот такие вот идеи на базе несложных в общем-то технологий :-)
Успехов!
Ещё 10 лет назад, учась в ВУЗе я высказывал нашему преподу по сетям подобную идею и даже прорабатывал алгоритмы, но меня никто не поддержал — тогда это было ещё не так понятно и актуально.
В перспективе я формулирую эту идею как виртуальное государство, которое не зависит от «реальных» государственных служб и корпораций. Люди смогут напрямую без посредников обмениваться информацией и принимать решения. Осталось сделать только «пиринговую валюту» и будет достигнута полная социальная децентрализация — вот такие вот идеи на базе несложных в общем-то технологий :-)
Успехов!
Чего уж говорить о ВУЗах, если вполне себе профильные специалисты зачастую крутят пальцем у виска. Пока не будет хоть примерно рабочих версий, которые демонстрировали бы соответствующие качества, никто нам не поверит.
Убеждался неоднократно, впрочем это уже было по другим проектам.
Убеждался неоднократно, впрочем это уже было по другим проектам.
Пиринговая валюта это очень интересная тема!
Как я ее вижу:
Каждые 2 узла имея взаимодействие создают свою валюту, внутреннюю только для них двоих.
Ей они расплачиваются за траф между собой, назначают лимит «минуса» при котором полоса начинает урезаться до некой минимальной (этот же кредитный лимит применяется к незнакомым узлам)
Долг можно погасить либо трафиком который качают через вас, либо взаимозачетом через другой узел (цепочку узлов).
Тоесть можно дать кому то денег, оказать услугу — а он вам начислит кредитов.
Во первых, это будет стимулировать бизнесменов создавать магистральные каналы.
----пояснение-----
Я держу оптику Москва-Нью Йорк, на концах канала у меня обычные ноды сети, и я ставлю цену за трафик (произвольно ставлю).
При просчете маршрута московские ноды видят что дешевле и быстрее зароутится через меня, если абонент в америке, чем ити через 1000 более дешевых нод (но за транспорт то прийдется платить каждой, либо юзать минимальную бесплатную пропускную полосу)
— В расчет роутинга ессно прийдется добавить еще одно значение, кроме количества хопов и времени задержки — цену транспорта.
Клиент ессно сможет в софте рулить — что ему щас надо побыстрее пусть и дороже, или подешевле.
Как я ее вижу:
Каждые 2 узла имея взаимодействие создают свою валюту, внутреннюю только для них двоих.
Ей они расплачиваются за траф между собой, назначают лимит «минуса» при котором полоса начинает урезаться до некой минимальной (этот же кредитный лимит применяется к незнакомым узлам)
Долг можно погасить либо трафиком который качают через вас, либо взаимозачетом через другой узел (цепочку узлов).
Тоесть можно дать кому то денег, оказать услугу — а он вам начислит кредитов.
Во первых, это будет стимулировать бизнесменов создавать магистральные каналы.
----пояснение-----
Я держу оптику Москва-Нью Йорк, на концах канала у меня обычные ноды сети, и я ставлю цену за трафик (произвольно ставлю).
При просчете маршрута московские ноды видят что дешевле и быстрее зароутится через меня, если абонент в америке, чем ити через 1000 более дешевых нод (но за транспорт то прийдется платить каждой, либо юзать минимальную бесплатную пропускную полосу)
— В расчет роутинга ессно прийдется добавить еще одно значение, кроме количества хопов и времени задержки — цену транспорта.
Клиент ессно сможет в софте рулить — что ему щас надо побыстрее пусть и дороже, или подешевле.
Красиво задумано!..
А как происходит рассылка трейс пакетов на уровне групповых узлов? Кто от имени группы начинает рассылку пакетов? Случайный узел или пограничный?
А как разруливается ситуация, когда каналов между соседними групповыми узлами несколько? Как пример в группе №1 есть пограничный узел А, который связан с узлами C, D и F группы №2 — как выбирается маршрут между ними?
А как происходит рассылка трейс пакетов на уровне групповых узлов? Кто от имени группы начинает рассылку пакетов? Случайный узел или пограничный?
А как разруливается ситуация, когда каналов между соседними групповыми узлами несколько? Как пример в группе №1 есть пограничный узел А, который связан с узлами C, D и F группы №2 — как выбирается маршрут между ними?
Прошу прощения за столь долгий ответ =)
Группа или не группа совершенно не важно. На каждом уровне иерархии есть грубо говоря 256 узлов. Которые знают друг о друге. Так происходит на каждом слое. Если трейс флуд выявил несколько маршрутов между хостами, то все они будут запомнены.
На данный момент множественные маршруты реализуются с помощью параметра nexthop утилиты ip.
Группа или не группа совершенно не важно. На каждом уровне иерархии есть грубо говоря 256 узлов. Которые знают друг о друге. Так происходит на каждом слое. Если трейс флуд выявил несколько маршрутов между хостами, то все они будут запомнены.
На данный момент множественные маршруты реализуются с помощью параметра nexthop утилиты ip.
В современных реалиях, её время ещё не пришло?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Netsukuku — свой собственный интернет