#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

Vort похоже, нашёл сам ответ в доках java: Only the search key is modified in this way, not the floodfill router hashes.

Vort The DatabaseStoreMessage should be sent to the floodfill that is closest to the current routing key for the RouterInfo or LeaseSet being stored.

Vort увидел я всё же кое какой эффект

Vort взял по 2 старших байта, посчитал расстояния между RoutingKey всех узлов в моей NetDb и моим IdentHash

Vort также для сравнения посчитал расстояния между рандомом и моим IdentHash

Vort нарисовал две гистограммы. сверху - для рандома, снизу - для реальных данных

Vort paste.i2pd.xyz/?352c952c54dc0d1c#DGJqhuWbeQiGLFX9jPpmdbYe9xhnB9E5GKG41EVzL6mk

Vort найденный эффект - пик около нуля - проявляется на грани погрешности

Vort так что вывод всё тот же - или я где-то ошибся или механизм поломан

Vort для сценария поломанного механизма получается вот так: сейчас в сети 50к узлов. у каждого флудфила по 10к рандомных узлов. шанс нахождения нужного узла среди 7 флудфилов ещё более-менее неплох

Vort для варианта с миллионом узлов такой же шанс уже будет стремиться к нулю

weko Естественно

weko Но dht же должно увеличить шансы?

weko Ааа

weko Хочешь сказать, для роутеров это не работает?

weko Ещё одна причина использовать отдельную базу данных

weko orignal: дед не выходил на связь?

Vort так я же проверил, насколько близки RoutingKey в NetDb к моему IdentHash. оказалось что примерно никак

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

Vort хотя лучше, конечно, было бы, если бы кто-нибудь перепроверил мои результаты

Vort вот пересчитал ещё раз, примерно через час:

Vort paste.i2pd.xyz/?51749a5875b70a7c#3HBHW7oUJpCVR2QND6yvgbBqKTdCau2RT7zPh5CPeXvX

Vort пик около нуля вылазит упорно. но точно так же упорно он микроскопичен

Vort где-то у 10 RI из 10000 в моём NetDb проявляется эффект близости

Vort "<weko> Ещё одна причина использовать отдельную базу данных" одна для обслуживания запросов своего узла, другая - для запросов всей остальной сети (транзита)?

Vort у меня подозрение, что это транзит может "вымывать" близкие узлы из NetDb

Vort случайно или специально

Vort и если флудфил не предпринимает никаких мер по приоритизации сохранения близких узлов, то имеем что имеем

Vort хотя, может, и три базы надо: в одной хранить близкие узлы и выдавать по запросу (DHT), в другой - требующиеся для обслуживания транзита, в третьей - те, через которые наш узел будет строить туннели

Vort попробую проверить гипотезу о вымывании близких узлов транзитом. запустил флудфил без транзита с чистой NetDb. удивился, что G флаг не поставился сразу. ну наверно через 12 минут аптайма поставится

Vort ага, G только через 12 минут появляется

Vort хотя есть же ещё пиртест и интродьюс, они тоже могут влиять. но их вроде так просто (как транзит) не отключить

Vort хотя почему же. это всё SSU2. сейчас переключу чисто на NTCP2

user Может просто увеличить "время жизни" RI на флудфилах?

Vort user: стоит думать над теоретической ситуацией с миллионом реальных узлов. тогда станет понятнее, что надо делать, а что - не надо

Vort NetDb из миллиона рандомных RI - это хреновый выбор, как по мне

Vort ну то есть, если позволить произвольному RI "жить" подольше

Vort нужно, скорее, защищать близкие узлы от "вымывания" посторонней (не-флудфиловой) активностью

tetrimer Vort: А сколько времени потребуется узлу, чтобы собрать этот миллион RI при нормальной работе? И нужно ли узлу знание о миллионе роутеров?

Vort скорее сколько трафика потребуется. так вот я об этом и говорю. тут важно не количество, а "качество"

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

Vort так вот эту проблему и должно решать XOR расстояние - оно и сделано для того, чтобы ограничить область видимости / ответственности

Vort но, видимо, что-то пошло не так

tetrimer Надо писать свое BGP (с блэкджеком и подтанцовкой) под i2p. :)

orignal weko а должен?

Vort для флудфила без транзита, без пиртеста и без интродьюса расстояния распределились вот так:

Vort paste.i2pd.xyz/?5c4f6d259f7c5942#HBSJQhcNDQkTWzQrkD4dSwpjzuF1v5jqYnKbmXjFWJNW

Vort чуть больше околонулевых расстояний, чем у полностью нагруженного вышеперечисленным, но всё равно маловато как-то

Vort надо наверное смотреть какие запросы на хранение RI приходят - от насколько близких узлов

orignal короче скажи краткую суть

orignal ты кстати забыл еще про флуд

orignal флудфилы же еще отсылают друг другу

Vort они отсылают что попало или то, что им только что напрямик пришло?

orignal при публикации

orignal кстати да надо проверить не отсылают ли они если ответ на запрос получают но вроде не должны

Vort "короче скажи краткую суть" - подозреваю большие проблемы с масштабированием задачи хранения RI по всей сети

orignal там вроде флаг есть

Vort если у всех флудфилов рандом по расстоянию - то это ничем не лучше запроса к произвольному флудфилу

Vort короч или вся это конструкция с DHT по сути не работает или я где-то ошибаюсь

orignal или где то баг

Vort "<~orignal> при публикации" входящая публикация - это вот это? NetDb: Got request with type 0

orignal не помню

Vort стал я копаться в своих логах, перепроверять расстояния к флудфилам, через которые мой RI публиковался

Vort и обнаружил ситуацию, когда после полуночи расстояние стало считаться неверно

Vort я полностью не уверен в этом эффекте, попробую ещё поизучать

Vort нашёл очень маленький баг. на всякий случай пишу:

Vort github.com/PurpleI2P/i2pd/blob/ae5239de435e1dcdff342961af9b506f60a494d4/libi2pd/NetDb.cpp#L1181

Vort вот тут в лог пишется сообщение про лизсет. но бывает же и флуд RI

Vort в случае RI получается несоответствие

orignal угу

orignal и это явно не я писал ))

Vort сколько копий рассылается по сети при публикации своего RI ? 1 + 3 ?

Vort я, похоже, ошибался, думая, что намного больше

orignal 3-м соседям

orignal но уже без флага flood

Vort ну и напрямик же флудфилу?

Vort то есть 1 флудфилу, а 3 он уже разошлёт

orignal ты кидаешь свой ближайщшему по DHT флудфилу с флагом flood

orignal а он ближайщим соседням уже без флага

Vort ну он его себе сохраняет?

orignal само собой

orignal то есть 4 копии

Vort значит, в сумме 4. спасибо

Vort это я пытаюсь понять, сколько в норме у флудфила должно храниться вот таких вот опубликованных (близких) RI

Vort допустим, 20к узлов онлайн. из них 2к флудфилов

Vort 20к узлов публикует 4*20к = 80к RI

orignal если одновременно то да

Vort то есть, на каждого флудфила получается по 80к/2k = 40 близких RI

orignal но на флудфиле они через час протухают

Vort экономно DHT расходует место получается

Vort не ожидал

Vort то есть, место для них найти не проблема. важно 1. чтобы они попали туда куда надо. 2. чтобы их флудфил не просрал

orignal ну типа того

orignal на самом деле как мы говорили несколько месяцев назад у нас реализация DHT не оптимальная

orignal как пределагает weko можно пустые в середине ветки сворачивать