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

Vort глянул я логи и вижу, что сообщения SSU2: Received queue size xxxx exceeds max size2500 по-прежнему появляются

Vort спешить ловить проблему не стоит, но помнить о ней не помешает

orignal ловить стоит. надо ж понять почему

orignal где еще затык

onon У тебя перенос очереди как работает?

orignal путем вставки

orignal поэлементно

onon Имею в виду откуда куда

onon А то я забыл

orignal что такое "перенос очереди" в твоем понимаении?

onon При смене IP?

onon Ты делал на транспортах

onon Перенос сообщений в другую сессию

orignal ну вот я и гвоорю поэлементно

orignal есди path challenge был успешный

onon Может там что копится

orignal там при переносе время проверяется

orignal и говно мамонта дропается

onon Ааа, ясн.

onon У меня есть предположение, что там копится, но я не проверял

onon Это из-за твоей системы ретрансмитов

onon Под большой нагрузкой у тебя в SSU2 когда теряются пакеты окно схлопывается и ты не можешь отправлять новые пакеты пока не переотправишь неподтверждённые

orignal что с ей не так?

orignal ну это верно

orignal а как иначе?

onon А отправляются они у тебя с очень большим интервалом

onon И он это врямя просто ждёт

onon И копит входящую очередь

onon И отправляются большими пачками, тем самым увеличивая вероятность повторной потери

onon И так окно всё время уменьшается, пока не переотправится последний пакет

onon И только потом шлётся основная очередь

onon А я всё думаю, откуда у меня задержки в 30 и более сек на стримах

onon Я то себе переделал ретрансмиты, но на промежуточных же старый алгоритм

orignal очень большой интевал это сколько?

onon 40-50 мс вроде

orignal а ты что предлашаешь? на каждую сессию отдельный таймер?

orignal тогда дескрипторов не хватает

orignal это тебе ре стримы

onon Ничего не предлагаю. Я себе сделал, но оно жрёт проц, я уже говорил.

Vort кто-нибудь кроме меня наблюдает за историческими значениями нагрузки CPU от i2pd?

Vort по графикам то есть

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

Vort роутеров ещё многовато в базе

Vort Transit: 11.91 GiB (2133.83 KiB/s) Routers: 16545 Transit Tunnels: 15758

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

onon Кстати, хотел ещё одну мысль обсудить, касательно пустых неиспользуемых туннелей. Если мы их начнём по неактивности дропать, кто от этого может пострадать?

onon Ява пострадает?

onon Они же вроде тесты не шлют

Vort да там тоже пинги вроде

Vort это устаревшая информация, похоже

Vort хотя надо проверять, конечно

onon А то у нас сам роутер пустые туннели плодит как я вижу

orignal так понятно что если уменьшить интревал будет жрать проц больше

orignal ява шлет тесты

onon Создаст туннель, потеряет тест, зафейлит, создаст новый

Vort onon: все плодят пустые туннели, это естественно

onon Ну пустые туннели лимиты отъедают на роутерах

orignal ну и с колько они отъедают?

onon Вектор для атаки, нплодить пустых туннелей

Vort эти лимиты во многом искусственны

onon Как мы видим

Vort можно опять дефолтное значение поднять

orignal нет у меня проц как обычно

un orignal, скажи есть туннель [client]-[1]-[2]-[3]-[4]-[5]-[6]-[server] правильно ?

onon xD

onon Пришёл

orignal un нет

orignal таких в i2p не бывает

un как

Vort в i2p он из двух половинок как бы

Vort серверная и клиентская, соединяются посредине

orignal будет тоннеь client->1->2->3->OBEP и IBGW->4->5->6->server

onon Ты что-то 4 хопа нарисовал

onon Вместо 3

orignal ранизца в том что эти тоннеля строятся разными сторонами

orignal так я как у un

orignal что может быть

onon 3 - это и есть OBEP а 4 - IBGW

onon В стандартной ситуации

orignal onon так чем плохи транзитные тонели кроме записи в хэш таблице?

onon Лимит напимер у меня стоит в 10к туннелей

onon Можно просто наплодить пустых мне

onon И я перестану принимать нормальные

onon Легитимные

orignal ну поставь 100K

onon Ну я то поставлю...

un как происходжит шифрование на участке например [client]-[1]-[2]-[OBEP] ? первый слой - ключи клиентский и 1 второй сложенный - клиент и 2 и 3й вложенный клиент и 3 ?

onon Но лимиты есть

orignal на самом деле интересная мысль спросить деда про тесты

onon un, с шифрованием там проблем нет

orignal un у каждого хопа есть ключ свой

orignal и применяется послойной

un тоетсь в итоге 6 слоев?

orignal все же слои шифрует или расшифровывает хозяин тоннеля

orignal нет

orignal клиент накатит 3 слоя

orignal промежуточные накатят обратно каждый свой

un а на участке OBEP - IBGW что?

orignal и на OBEP будеи расшифрованное

orignal а на участке OBEP-IBGW сквозное

orignal это отличное от тоннелей шифрование

un а понял

orignal и от прокотолла более выского уровня

orignal там бывает и нешифрованные

un тоесть на OBEP-IBGW будет шифрованное ключами client и server ?

orignal напапример RI

orignal да именно так

un может ли 2 и OBEP знать где client ? не IP а i2p адрес

onon un, они не знают, OBEP знает только 2 а 2-ой всё пересылает 1-му

un я тоже так думал. тогда в чем был твой вчерашний поинт?

onon А 1ый уже клиенту

onon В том, что 1-й может быть майором

un что если 2 или овер майорский то жопа

onon Что если и 1 и OBEP - майор - то жопа

un что это даст майору? он не сможет расшифровать и не поймет dest

un или чо

onon Он видит что через него идёт трафик

un и все. просто ты както сказа вчера что привело к мысли что если майор на овер будет срать в туннель на 2 то это дойдет до 1

un тоесть до 1 дойдет битая посылка но по итогу так он может хуярить пакеты и найти на 1 туннель клиента

un так?

onon Ты, похоже, ничего не понял.

un похоже

onon Вообще речь вчера шла про ситуацию когда майор IBGW и 1 хоп в туннеле (в твоём примере 6)

onon С OBEP там сложнее, там нужно, чтобы майору отвечали

onon А в IBGW можно просто трафик слать меандром

onon И на 1-м(6-м) хопе смотреть пульсации

onon И так определить на каком роутере дестинейшн

un а мне показалось что ответ не нужен чтобы пульсации наблюдать

un на овер тоже

onon С высокой (но не 100%) вероятностью

onon У нас однонаправленные туннели

onon Это затрудняет такие атаки

un по факту каждай промежуточный роутер занимается перепосылкой пакета дале. и далее соседнего хопа флуктуации не пройдут

onon Точно?

orignal onon так что ты конктрено предлагаешь? снизить интревал?

onon Ну я себе 10мс сделал

onon Так проц не сильно жрёт

onon Вообще 1мс делал так он 70% жрал

onon А так около 30

onon На 3к SSU2 сессий

onon Там корреляция такая интересная получилась, на 1к - 10% на 2к - 20%

orignal 10 мс

orignal это порог

orignal разные типы таймеров используют

onon А чего у тебя тогда 4мс таймер сделан

onon Там же

orignal это где?

onon 4-13мс

onon Тм где MORE

onon Если много пакетов ретрасмит

onon Хотя это и не работает..

onon Потому что после объединения массивов у тебя он всегда возвращает 0

orignal так потому что more

orignal я имел ввижу регулярный таймер

orignal который постонно ходит по сессиям

onon Там у тебя вообще всё плохо в этом SSU2

onon Я как полазил, поразбирался, так руки опустились

orignal а ты найди старые релизы с SSU1 и посмотри туда ))

orignal и поймешь насколько прерасен SSU2 )))

orignal ну вот возьми и сделай лучше

onon Можешь рассказать как работает OutOfSession bkb rfr tuj nfv

onon или как его там

onon И для чего исползуется

orignal а с ним то какие проблемы?

orignal для обмена сообщениями без создлания сесиий

onon Для запросов к фф, интродьюсеров?

orignal что очевидно из названия

orignal 1. для пир тестов

orignal 2. для hole punch

orignal запрос к фф полноценая сессия

onon Т.е. там нет контроля доставки

orignal нет

orignal там по одному сообщению всего

onon Вот твой пиртест отстой потому

orignal если нет ответа то перепосылка

orignal там же не весь пир тест

orignal а только 5,6,7

orignal и там есть перепослыки

onon Пиртест нужно переделать хотя бы на другой порт не основной

onon Если к STUN не хочешь привязываться

orignal ну так доставай деда и "пиши пропозал"

onon Ту хард

KevinMitnik дед вас тормозит

KevinMitnik выкиньте его

orignal счас я у него спросшу про тесты

onon Можно сделать в RI доп флажок, что роутер имеет открытый доп. порт и через него можно делать пиртесты

onon Если протоколом не запрещено в RI добавлять

orignal можно добалять любые данные

onon А до ацетона можно как-то достучаться? А то майора на irc2p забанили, логов с 12 числа нету.

orignal не знвю

orignal напиши ему лс

onon А если я сделаю float чиселку и буду её постоянно увеличивать, какое максимальное значение и что будет если я его превышу?

onon У меня проблема с расчётом джиттера, думаю просто складывать все значения и делить на количество.

orignal не надо там float

onon инта?

orignal чем тебе плохо uint64 ?

onon Я ж не разбираюсь вот и спрашиваю что лучше

orignal float вообще следует избегать

orignal то что у тебя он используется в стримах это надо переделать

onon А double?

orignal аналогично

orignal числа с плавающей точкой тут не нужны

Vort с джиттером микросекунды нужны?

orignal даже если нужны всегда можно делать с множителем

onon Ну он при расчете RTT используется, а там есть

Vort и "все значения" - это сколько?

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

onon Ну вообще он должен сбрасываться при каждом обнаружении затора

onon А так до смены маршрута я думаю

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

onon 10 минут

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

Vort "<~orignal> даже если нужны всегда можно делать с множителем" есть ещё "фиксированная точка"

Vort для понимания диапазона - если одна "точка" - секунда, то в uint64_t влезет 18446744073709 таких точек с микросекундной точностью

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

Vort можно себе позволить :)

onon Я понял

onon Похоже, это всё-таки торренты

orignal что именно?

onon Вот сейчас поймал туннель, через который пролазило только 4-5кБ/с и пинг там скакал от 3с до 10 примерно

onon И он без перестроения маршрута вдруг стал "нормальным"

onon С пингом 600

onon и начал тут же разгоняться и нормально работать

onon А до этого ему просто очередь на транспорте перегружал кто-то

onon Причём так под завязку

onon 600мс превратить в 10 сек

orignal либо дед резал трафик

onon А потом резко перестал?

onon Да ну

Vort все типы контента важны, я об этом давно говорю

Vort если алгоритмы плохо с торрентами работают, это проблема алгоритмов, а не торрентов

onon Вот сейчас 800мс пинг 53окно, стабильно идёт и вдруг начинает RTT расти до 26 сек

onon А потом с 26 быстро до нормы и дальше работает

orignal значит где то перепосылки

onon Это точно не я туннель перегрузил

onon Может и так, нужно копать...

Vort оба конца туннеля контроллируешь?

orignal как знаешь что не ты?

onon Ну я же стабильное количество пакетов слал

onon Без перегрузок

onon Это не на разгоне было

onon А на плато

Vort если только один конец, то вторая сторона же может свой туннель поменять

onon Типа куда акки шлёт

onon И он 26 сек искал RI

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

onon Ну он бы тогда заткнулся и перестал бы получать акки

onon Если бы они в затор попали

Vort а у тебя RTT плавно нарастал?

onon А RTT начал расти плано но быстро

orignal кто искал 26 секунд?

onon Ну типа конец туннеля

Vort да если с плавным нарастанием, то это просто трафиком забивается

Vort все искания чего-либо - это скачок с потерями

orignal а почему он искал 26 секунд?

onon Не искал, проехали это была ложная гипотеза

Vort 26 сек это вобще странно

Vort это в TCP буфер что ли так много набилось?

Vort на UDP это бы дропнулось нахрен

Vort такое у меня ощущение, что до того, как кто-то полноценно разберётся с тестовыми сетями, такую фигню полноценно отладить не выйдет

onon Есть, конечно вариант что это на самой сети перегрузка была на уровне IP и ниже...

Vort надо контроллируемый сценарий прогонять десятки раз, меняя код за каждой итерацией

Vort onon: или CPU призадумался

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

onon Но в последнее время это вылазит всё чаще...

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

onon А сегодня два раза уже за час

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

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

Vort так как сценарии перегрузок особо никто не отлаживает

onon Ну вот этот "горб" длился 44 секунды

orignal а по моему это не атака а просто разгрузили траспорты от обращеий к диску вот потоки и поперли

onon Странные выводы кмк

onon Должно быть наоборот

onon Ну так в итоге что? Я с этим сделать ничего не смогу.

onon Если кто-то перегружает маршрут

orignal почему наоборот?

orignal просто потоки сразу стали выше

Vort orignal: юзеры обычно обновляются неторопливо

Vort через год-два можно ожидать эффекта, а не сейчас

onon Алгоритм просто уходит в защиту, сбрасывает окно в минимум и шлёт очень медленно

onon Чтобы ещё больше не перегружать

Vort onon: думаешь, на "той стороне" алгоритм без такой защиты?

onon И как с этим бороться пока не понятно

onon Я в одну сторону шлю

onon С той стороны только акки

onon Или про что ты?

Vort я имею в виду, что виновник перегрузки делает её старым алгоритмом

Vort которому пофиг на тормоза

onon Не

Vort или и новый такое выдавать способен?

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

Vort так вот надо понять, это старые версии такое делают или не только

Vort может быть, конечно, посторонний процесс, как у меня торренты

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

Vort (я имею в виду не-i2p торренты в данном контексте)

onon Тот алгоритм, что сейчас в ветке может так перегрузить канал, если одновременно создаст много стримов и они будут одновременно разгоняться

onon Кто-то на кислице бабок голых смотрит из-под тормозиллы

Vort маловероятный сценарий как мне кажется

Vort так это ж на несколько секунд

onon Кучу картинок одновременно

onon Чтобы такого не было нужно делать общий лимит окна на все стримы к одному клиенту

onon И чтобы шифрование не ломалось

onon Но это будет медленнее, да...

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

Vort минуту?

onon Я ж говорю 44 сек

Vort сколько надо времени чтобы картинки с сайта загрузились?

onon От размера же зависит наверное

Vort ну я хз какие на популярных в i2p сайтах размеры

onon И я тоже

Vort но в клирнете юзеры обычно 44 секунды загрузки страницы не ждут

onon Ну там защита должна сразу сработать, примерно через 1 RTT он перестаёт разгоняться и начинает снижать скорость отправки

onon Но в зависимости от размера окна за 1 RTT он может много лишних пакетов туда напихать...

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

onon Поэтому я сейчас делаю лимит

Vort с реалистичным сценарием

onon Да, я смог воспроизвести. и получил RTT 25 сек

onon Открыл кучу картинок поверх уже работающего стрима

onon Надо нам замедлять стримы