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

Vort работало у меня на одном и том же компе два узла - первый - флудфил с транзитом (TCSR 24%), второй - флудфил без транзита (TCSR 45%)

Vort решил я обменять им NetDb - и за 17 минут аптайма получил следующие значения - у первого узла рейт вырос с 24% до 62%, у второго узла рейт упал с 45% до 35%

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

Vort (уточнение - эти узлы я перезагружал)

Vort за час аптайма у первого узла рейт упал до 57%, у второго - поднялся до 44%

Vort то есть, второй узел довольно быстро восстановил свой прежний рейт, даже с "проблемной" NetDb

Vort если у кого-то сейчас на узле рейт 20-30, предлагаю попробовать перезапустить узел с чистой netdb. профили можно не трогать, только саму базу удалить

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

Vort за два часа аптайма у первого узла рейт упал до 40%, у второго остался на 44%

Vort ещё вчера заметил странную особенность - у второго узла (который G) NTCP2 коннектов в 3 раза меньше (сейчас 637) чем SSU2 (сейчас 1560)

Vort у первого узла сейчас NTCP2 ( 1448 ) и SSU2 ( 1517 )

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

Vort и вместе с этим начал проседать рейт

Vort не знаю, насколько это правильно - запускать флудфил на чистом SSU2, но сейчас переведу первый узел в такой режим - может это что-то прояснит

Vort за два часа аптайма первого узла (флудфила в SSU2-only режиме) рейт - 40%, количество SSU2 коннектов - 2673

Vort orignal: нашел подозрительное место в коде, похоже на баг, можешь глянуть?

Vort github.com/PurpleI2P/i2pd/blob/ae5239de435e1dcdff342961af9b506f60a494d4/libi2pd/Transports.cpp#L805-L809

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

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

orignal да такая возможность есть

orignal надо бы починить

orignal на самом деле насколько я помню в тот список вставляется из PeerConnected

orignal так что не должно быть

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

Vort но логирование сейчас довольно ограниченное, поэтому полноценно разобраться не получится

Vort похоже, разобрался: paste.i2pd.xyz/?623f9b27b19dfc78#4pTCPoWyCC4TecmQUATKTzSwzUHPV3KEVHq6jDKzJSGs

Vort полминуты искался RI, а как нашёлся и пошёл коннект - пришло время удалять пира

Vort всё нормально. кроме поиска RI полминуты :)

Vort замечал, кстати, что иногда флудфилы и подольше тупят. хотя может и этому есть логичное и естественное объяснение

Vort надо будет собрать статистику по времени поиска RI

Vort построил гистограмму разницы по времени между сообщениями в логе "not found, requested" и "found, trying to connect" для конкретных identhash

Vort paste.i2pd.xyz/?fe2e49770164543c#WtaiWSTfXZeiKWh6GF3sX7wSnc21YcVpQ14hsZKnSom

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

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

Vort ещё около 20% поисков где-то секунду идут

Vort дольше - вполне бывает, но уже редко

Vort ещё, конечно, есть случаи, когда найти не удаётся, но это отдельно надо смотреть

Vort сейчас посчитаю сколько раз попадается "Transports: RouterInfo not found, failed to send messages"

Vort foundCount: 39291 notFoundCount: 2481

Vort подозреваю, что это не все не найденные. маловато как-то

Vort хотя вот ещё интересные случаи есть. не очень частые, но и не очень редкие:

Vort [03/Aug/2023:15:26:08 +0300]@339/debug - Transports: RouterInfo for DFoZw9-u4j4F2Dgbu0tQL-PeTGxRVKJqgjeTYz5Z~Y4= found, trying to connect

Vort [03/Aug/2023:15:26:08 +0300]@339/info - Transports: No compatible addresses available

Vort узлы с потерянными (сброшенными при пир тесте?) интродьюсерами что ли?

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

Vort paste.i2pd.xyz/?10295f28f1e75dec#6VWZ3GHaskoC3vGw5AM9LgbwoSzsTv7HLZd9vBwA5nqe

Vort несколько штук таких RI удалось найти - все Java

Vort но то что такое бывает и с i2pd - это я знаю, сам видел

orignal no compatible значит нет совместимых с тобой

Vort ну а у меня на моём узле 4 варианта - NTCP2/SSU2 4 и 6. только ygg не включил - но то мелочи

Vort это пустышки скорее всего

orignal неее

Vort то есть, когда другой узел заказывает туннель - у него нормальный RI. а когда мне пришло время этот туннель строить и я запрашиваю RI из сети - там пустота

orignal скорее всего ты к нему подключаешься

orignal а у него нет входящих транспортов

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

Vort скорее всего это из-за транзитов такое происходит

orignal ну а тот кто строил тоннель думал что нет

orignal скорее всего интродьюсары протухли

Vort да. и получается такая хрень и в i2pd и в java сейчас

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

orignal ну и что ты предлагаешь делать?

Vort ну с i2pd понятно - чинить. или как мой вариант или модифицировать как-то. а вот с java посложнее будет :(

Vort самое загадочное - это то, что я уже долгое время пытаюсь найти причину проседаний рейта. кажется, что есть какая-то одна большая причина. но, может, нету? и проблема состоит из большой кучи мелочей?