333.i2p

Нет я дефолтный флаг не трогал. Просто если разные треды то действительно могут быть проблемы.
Я попробовал запускать снарк, там все нормально запускается и останавливается.
Если новые сессии не создаются это значит тред подвис, неплохо бы к нему прицепиться gdb и посмотреть на чем.

Да, забыл добавить, когда этот баг случился, новые i2cp сессии не будут создаваться.

>А если только одна сессия, то завершается нормально?
>И еще вопрос: там один тред или несколько? Параметр i2cp.singlethread в конфиге.
У меня он не был задан в конфиге. i2pd на виртуалке с одним ядром. BiglyBT создаёт минимум 2 сессии, но вторую с большой задержкой. Тогда постараюсь подловить момент, когда ровно одна сессия...

i2pd 2.53.0 с сегодняшним фиксом. Роутер только что запущен, запускаю BiglyBT, жду появления нужного количества сессий, создания туннелей, и выключаю BiglyBT...

i2cp.singlethread=true и 1 сессия. Результат: 100% cpu, единственная сессия исчезла, новые сессии не создаются.

i2cp.singlethread=true и 2 сессии. Результат: 100% cpu, осталась 1 из 2 сессий, новые сессии не создаются.

i2cp.singlethread=false и 1 сессия. Результат: 0% cpu, единственная сессия исчезла, ошибку "I2CP: Can't receive header" видел, новые сессии создаются и работают.

i2cp.singlethread=false и 2 сессии. Результат: Результат: 0% cpu, обе сессии исчезли, новые сессии создаются и работают.

Я подозреваю, что ошибка "I2CP: Can't receive header" была во всех случаях, но я не успел её заметить. Потом проверил, когда во второй раз выключал BiglyBT с двумя сессиями, два раза появилась эта ошибка.

Вывод: нужно ставить i2cp.singlethread=false.

orignal, а дефолтное значение этого флага менялось в новой версии? У меня в конфиге его не было. В конфиге, который лежит в репозитории в contrib, тоже его нет. Разве что в доках можно узнать о его существовании.

Кстати, когда с i2cp.singlethread=false во второй раз выключил BiglyBT, стала проскакивать такая ошибка: error - Router: Runtime exception: cannot create std::vector larget than max_size()
Где-то в течение минуты она прекратила появляться.

А если только одна сессия, то завершается нормально?
Этот код никто не трогал несколько лет.

И еще вопрос: там один тред или несколько? Параметр i2cp.singlethread в конфиге.

Last edited: Tue, 23 Jul 2024, 05:24pm от orignal

Фикс не помог.
Ничего не изменилось, и в логах та же ошибка I2CP: Can't receive header.

Починил.
https://github.com/PurpleI2P/i2pd/commit/23e323...

i2pd 2.53.0 проблема после закрытия I2CP сессии

После обновления с версии 2.52.0 на 2.53.0 появилась проблема с I2CP.
К i2pd по I2CP подключается BiglyBT. i2pd и BiglyBT запущены на разных хостах в одной локальной сети, так что присутствует фактор небольшой задержки в I2CP соединении. Но я пробовал минимизировать задержку и искуственно создавать её настройками netem, разницы нет, значит она не играет роли здесь.

BiglyBT создаёт 5 I2CP Local Destinations:
[BiglyBT: DHT Pure+]
[BiglyBT: DHT Bridge]
[BiglyBT: DHT Pure]
[BiglyBT: DHT Mixed]
[BiglyBT: DHT Mixed+]

Качается нормально.

Когда выключаю BiglyBT, появляется эта проблема. Сразу же i2pd нагружает процессор на 100% (и она не проходит без перезапуска), I2CP Local Destinations не исчезают (точнее, только одна из них исчазает (вроде всегда [BiglyBT: DHT Mixed] исчезает)):
[BiglyBT: DHT Pure+]
[BiglyBT: DHT Bridge]
[BiglyBT: DHT Pure]
[BiglyBT: DHT Mixed+]

Со временем у них исчезают исходящие туннели, но остаются входящие.

В логах сразу после выключения BiglyBT отловил это сообщение: "error - I2CP: Can't receive header".
Также много сообщений "Tunnels: Test of tunnel .... failed" про разные туннели. До запуска BiglyBT их нет. Во время работы BiglyBT они иногда появляются, где-то раз в 5-20 секунд, по одному или по 3 штуки сразу (когда уже качается несколько сотен КБ/с). После выключения BiglyBT они идут стабильно раз в 5 секунд, по 3-4 штуки сразу.

Хочу написать вспомогательный софт для замеров. Вернусь с более продолжительными наблюдениями.

Сегодня опять началось. У меня 2 http proxy на одном роутере, вёл наблюдения за ними. Оба настроены на 6 туннелей в обе стороны, длина 3 хопа + 1 рандом. Туннели большую часть времени простаивают, но где-то раз в минуту я через них посылаю маленькие запросы. В какой-то момент на входящих туннелях начали ставится примерно 50% yggdrasil-пиров. Я записывал список входных пиров чуть реже, чем раз в 10 минут. Вот 5 замеров для обоих прокси (где-то час этим занимался). Видно, что сначала ставится много ygg-пиров, потом приходит в норму. Имена пиров заменил на псевдонимы. Если подписано ygg, значит это ygg+clearnet пир. Если ничего не подписано, то это чисто clearnet пир.

Замер 1:
HTTP PROXY 1
LLLL
NNNN
EEEE ygg
SSSS ygg
3333
MMMM

HTTP PROXY 2
9999
9999
SSSS ygg
WWWW ygg
SSSS ygg
SSSS ygg

Замер 2:
HTTP PROXY 1
CDCD
EEEE ygg
IJIJ
EEEE ygg
TTTT
HHHH ygg

HTTP PROXY 2
RRRR
ABAB
9999
JJJJ
SSSS ygg
STST

Замер 3:
HTTP PROXY 1
QQQQ
SSSS ygg
EEEE ygg
EEEE ygg
EEEE ygg
6666

HTTP PROXY 2
WWWW ygg
XXXX
EEEE ygg
EEEE ygg
8888
UUUU

Замер 4:
HTTP PROXY 1
IIII
BBBB
EEEE ygg
QRQR
YYYY

HTTP PROXY 2
7777
KLKL
EEEE ygg
PPPP
2222
EFEF

Замер 5:
HTTP PROXY 1
EEEE ygg
DDDD
KKKK
9999
EEEE ygg
GHGH

HTTP PROXY 2
2222
CCCC ygg
OOOO
VVVV
FFFF
0000

Не воспроизводится проблема. Orignal, пока забей.
Если я смогу воспроизвести проблему, я напишу с большими подробностями.
Есть предположение, что надо ухудшить качество связи, я буду экспериментировать.

Сегодня записывал пиры на конце входящих туннелей у серверного. Выходит нормально, пиры чисто из клирнета почти всегда.
Странно, я продолжу наблюдения. Когда ставятся пиры из yggdrasil на конце, то явно видно, что маленькая группа пиров повторяется во всех местах туннеля. Сегодня не так, большое разнообразие пиров.
С объемами трафика это может быть связано? Сегодня много транзита идёт, обычно столько нет. Я замечал, что когда роутер простаивает, он забывает пиры.

А я пособираю статистику. Чем дольше работает роутер, тем больше вероятность, что он будет почти всегда ставить yggdrasil роутеры в конце туннелей.

Я этот вопрос поизучаю почему вдруг на концах тоннелей получаются роутеры с поддержкой ygg.

У меня 3.
Если поставить 4, то только тогда более-менее ок.

Именно поэтому минимальная длина тоннелей должна быть 2.

Когда i2pd используется в yggdrasil-only режиме, то почти всегда на концах туннелей будут другие роутеры с yggdrasil-адресами.
А ведь другой стороне видны пиры на концах наших входящих туннелей, таким образом с высокой вероятностью можно вычислить, что подключается клиент с роутера в yggdrasil...

Не понимаю, в чём проблема? Что мешает роутеру ставить в середине туннеля тех пиров, которые находятся в clearnet и yggdrasil, а на конце туннеля ставить чисто clearnet пиры (или yggdrasil-clearnet пиры тоже, но не НАСТОЛЬКО часто)?