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

orignal почему то начинаю в родество

onon Наверное у кого-то свободное время появляется

orignal точно не у меня ))

` Показывают бурную деятельность под конец и на начало года 🤔

relaybot 13apophis: Uptime: 1 day, 9 hours, 39 minutes, 23 seconds

relaybot 13apophis: Network status: Firewalled

relaybot 13apophis: Tunnel creation success rate: 72%

orignal свежачок собрал?

relaybot 13apophis: нет на релизе с патчем от китайцев

relaybot 13apophis: патч по профайлингу только

relaybot 13apophis: без явы

relaybot 13apophis: говорили, что работают чтобы яву не брать. Похоже не из за скорости, а какие то политические упрямые идеи.

orignal так собери транк там много чего улучшено

relaybot 13apophis: конечно соберу к понедельнику

orignal Tunnel creation success rate: 73%

orignal как в лучшие времена

Vort ygg что ли?

Vort или Firewalled

Vort у меня 28% за 11 часов аптайма

Vort лучше, чем 10-15%, конечно, но до 70-80% ещё далеко

orignal нет OK

orignal но с отклюбченным транзитом

onon Да это он включил, чтобы только через фф строились

Vort а, понятно

orignal после 2 часов работы

onon И выпендривается тут

Vort у firewalled юзеров, наверно, ситуация будет схожей

Vort так как там транзита хоть и не ноль, но около того

onon 44% на FW

orignal а какой мне смысл?

orignal счас еще один коммит сделаю

orignal одну дыру нашел

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

Vort я так делал, запускал два узла параллельно

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

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

orignal Vort я по прежнему уврене что причина в том что на банят

orignal из-за транзита

orignal закоммитил

orignal согласитесь такая не слабая дыра была

Vort ну а я уверен, что U узлы тоже садят рейт

Vort причин явно несколько

orignal если правильно эксплуатрировать то можно хорошо сеть засрать

orignal U то само собой

Vort я пока что не понял, что коммит делает

orignal смотри

Vort if (i2p::data::IsRouterBanned ... newRouters.push_back. нафиг нам список баненных роутеров?

orignal опечатка

orignal счас

Vort )

Vort тогда понятно

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

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

orignal тепреь все

orignal кроме того мы как дятлы запрашивали несовестимы е снами

onon А чего эту проверку убрал?

onon if (it.iTag && ts < it.iExp)

onon Где-то в другом месте проверяется?

orignal да. там выше строчка

orignal написано же

orignal // introducer is not expired, because in indices

onon Ага, нашёл

onon Правда, что ты в SSU сессию в пробитую дырку не шлёшь пинги?

onon Отмазка про туннельные тесты не катит.

onon Потому что он на одном узле теряется, и на всех остальных unbinding делается

orignal почему не шлю? глю

orignal шлю

onon Ворт сказал только до интродьюсера

orignal ну да

orignal так если данных нет то сессия быстро заврешается

orignal зачем слать то?

onon irc туннель много данных шлёт?

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

orignal раз в 30 секунд пинг

orignal а дыра обычно подольше бывает

onon 30 сек - старндартное время NAT unbinding для UDP

orignal ну я согласен надо продумать

onon У тебя пинг задержался или потерялся и всё

orignal надо что то слать чтобы заведомо получать ответ

onon На самом деле у некоторых производителей сейчас 20 сек

orignal а такого сообщения нету

orignal все упирается в это

orignal знаю что есть такая проблема

onon Я может чего забыл, но вроде исходящего пакета было достаточно

onon Нужно освежить

orignal а в обратную сторону как?

onon Если я U узел, я должен слать.

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

Vort всё же интродьюсеры - это отдкльный случай

onon Что бы дырка не закрылась

orignal согласен что надо

Vort для поддержания _своей_ дырки много не надо

Vort хоть что-то отправить

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

orignal Vort но тут вопрос во что уперсы

Vort вопрос упёрся в то, что именно отправлять

orignal таким макаром у нас сессии никогда не будут завершаться

onon 10 мин, если не было входящих пакетов

onon С той стороны

orignal мы все время гоним данные даже когда активности нет

orignal и как сессия заврешится?

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

orignal у нас все сообщения с данными считаются

orignal сначала придется переделать

Vort а без данных?

orignal если тип пакета "Data" то считается данными

Vort я могу попробовать в логах обсуждение найти....

orignal даже если там только паддинг

orignal да я помню в чем была пробелма

orignal я еще не настолько старый дед ))

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

Vort если слать не данные, а что-то другое

Vort данные держат сессию, а какая-то прочая хрень поддерживает дырку

onon А что для SSU нет протокола пинг-понгов?

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

orignal onon то то и оно что нету

onon Тогда делай нешифрованные

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

orignal так он опять начал

onon Можно просто слать пакет, который вторая сторона дропнет

onon Главное, чтобы через нат был дестинейшен в заголовке

orignal кстати да можно короткий пакет слать

orignal которые сразу дропнется

Vort я таки нашёл лог: major.i2p/ilita/dev/2024/04/18#msg106

Vort orignal: "HolePunch" - это внутри Data или нет?

orignal если и блок и отдельное сообщение

orignal а нет это только отдельное сообщение

Vort то есть, годится для цели пожжержания дыры без подержания сессии?

Vort поддержания*

orignal ну так та сторона будет ошибку кидать

onon А механизма завершения сессии, вроде FIN или ещё как не предусмотрено?

orignal есть блок Terminate

onon Так а можно точнее сформулировать проблему?

onon Если ты говоришь, что сессия никогда не завершится

Vort onon: надо держать дыру не держа сессию

Vort чтобы сессия могла отвалиться по таймауту если нету данных

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

onon Если верхние уровни не просят её держать

Vort onon: удержание и от приёма работает

Vort не обязательно слать, можно только принимать

onon Ну так та сторона и завершит

onon Когда устанет

Vort я уже плохо помню, как этот механизм работает, но простого решения, по-моему, там нету

Vort нужен такой пакет, который бы не держал сессию, вот и всё

Vort пустой отправить нельзя

orignal так мы иницируем заврешение по таймауту

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

onon Ну если я отправитель, и мне с верхних уровней 10 мин не приходит данных, я завершаю

onon А так я в рамках сессии 10 мин исправно шлю свои пинги

onon Или как вы их там называете

Vort onon: в i2p потоки данных односторонние

onon Ну, и чему это противоречит?

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

Vort "если я отправитель ... мне ... не приходит данных" - тут два направления в этой фразе

Vort а бывает, что направление всего одно

onon Значит либо данные "правильные" либо кто-то нарочно нам держит сессию, с плохими намерениями

Vort короч я не могу пояснить, получается. может, у orignal получится

onon а бывает, что направление всего одно

onon Ты имеешь в виду роутеры, которые не поддерживают новую логику?

onon Или что?

onon Так они не будут слать пинги

Vort да не нужны тут пинги, нужен keepalive

Vort без ответа то есть

onon Назови как хочешь

Vort "<onon> Или что?" имею в виду, что через транспорт может течь транзит, в одну сторону. и это как бы не совсем "мы" отправляем

Vort и ответа на этот транзит никакого не будет. ушло себе и ушло

onon Значит сессия нужная

onon И закрывать её не стоит

onon Или не так?

onon Если транзит идёт

orignal короче суть в том что сесии заврешаются по таймуту

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

onon Ну так а предложение принудительно закрывать сессию если с верхних этажей нет пользовательских данных?

onon Где там косяк в логике?

orignal а если они с той стороны приходят?

onon Ну значит та сторона и закроет, когда закончатся

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

orignal ты не догнал

onon Ну сейчас же не шлёт

orignal сейчас мы просто не шлем ничего

weko Нет именно что пингов

onon А если будет слать, значит она знает новую логику

orignal а счас ты предлагаешь слать чтобы дырку поддерживать

onon И сама закроет соединение когда закончит

orignal а та сторона будет думать что от нас идут данные

orignal и на той стороне аналогично

weko orignal: я понял например шлёп паддинг, если ничего кроме паддинга нет закрываем сессию самостоятельно

onon Нет в моей логике нет "входящих" пакетов

weko Или DateTime

weko Что там ещё

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

onon Только исходящие

orignal weko так я и гвоор что вот это надо переделать

orignal что считать даннными не сообщение Data

orignal а наличие в нем определенных блоков

weko Ну вот решение вполне рабочее

orignal onon а если реально потом данных одностронний

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

orignal weko так я сразу это сказал просто руки не дошли починить

weko orignal: сейчас обе стороны должны понять, что сессия закрывается при неактивности и закрывают пассивно? Или всегда активнл

orignal сейчас одна и стороны видит что данных нет в обе сторны и шлет Terminate

weko Активно. Получается если время одинаковое то они одновременно почти это делают

weko С разницой в величину задержки

orignal наврное да

weko Это не вызывает проблем?

weko Получается мы уже закрыли а нам Terminate приходит

orignal неее

orignal мы должидаемы потверждения на него

orignal мы тоже не дураки

weko Получается мы можем ждать подтверждения и к нам приходит Terminate

onon А механизм отклонения Terminate и продолжения сессии предусмотрен?

weko onon: а зачем

weko Если сторона отказывается то какой толк пытаться дальше

onon Надо подумать

weko Так или иначе сессия завершается

onon Значит нужен служебный пакет, который бы продлевал сессию на 10 мин

onon И шлётся когда строится транзитный или наш собственный туннель

onon Даже если коннект уже есть

onon Новый туннель построили - продлили на 10 мин

onon Таймаут вышел - закрываем

weko onon: об этом уже говорили ну и самое элементарное это пинги в туннелях

orignal ну так что упорядочиваем интродьюсеры по времени?

orignal первым пробуем более свежий

onon Раз уж ты сейчас в этом коде копаешься, почему бы и не переделать...

orignal так я думаю верно ли это

onon Мне например навскидку не приходят варианты негативной эксплуатации

onon Чтобы из этого можно было какую-то атаку намутить

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

orignal который может быть дохлым

orignal не атака а логика работы

onon Ну так если не получится мы следующие пробуем?

orignal нет

orignal мы пробуем только один

onon В любом случае самый свежий с более высокой вероятностью будет живым

onon Потому как с течением времени вероятность выключения роутера растет

orignal а если таки нет?

onon А таки как?

onon Как нам оценить ещё вероятность?

onon На что мы можем опираться?

onon Какие есть критерии?

onon Если один из интродьюсеров уде есть у нас в подключенных

onon уже*

onon Например

onon Или "пробивать по базе" список интродьюсеров?

onon Выбирать isReal

onon или ещё по каким критериям

onon Что мы ещё можем узнать об каждом из интродьюсеров?

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

onon Просто повесить эту роль на фф

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

onon А нагрузка тут не тонны трафика

onon А стабильность работы механизма интродьюсинга радикально повысится.

orignal надо основываться на том что есть сейчас

onon Просто сделай, чтобы при выборе итродьюсеров был приоритет на фф

onon А ещё лучше на "ближний" фф

onon Потом можно будет даже не зная интродьюсеров у роутера, спросить на фф.

onon Нету ли у него такого в подопечных

weko В идеале основываться на профилировании

orignal ну если есть то откуда ты таг возьмешь?

onon Какой таг?

orignal ты когда RekayRequest шлешь ты должен сказать таг сессии с чарли

onon Так я не про текущий протокол

onon А про будущий

onon Тогда можно TBM слать

onon We->FF->U->We

onon Это просто как пример, нужно будет делать чтобы не плодить фантомных туннелей

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

onon А думать наперёд не нужно?

orignal нужно

orignal но у меня времени нет )))

onon Тогда выноси на обсуждение вариант отдавать приоритет фф при выборе интрлдьюсера

onon И с дедом обсудить

onon Потому что нам нужна надёжность, сейчас слишком много вариантов, где может случиться отказ.

orignal а как я узнаю флдфил ли это?

orignal толкьо если есть у меня в netdb

onon Мы же выбираем из нетдб разве нет?

onon Я понял, мы о разном думаем

onon Я имею в виду, что я firewalled

onon И я выбираю себе интродьюсера

onon Так вот нужно выбирать ff