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

Vort orignal: я сделал поддержку 0мс пингов: github.com/PurpleI2P/i2pd/pull/2026

Vort этот код работает чуть иначе, чем раньше

Vort но тоже должно быть ок

Vort там был почему-то "медленный старт" усреднения (с нуля)

Vort я же сделал старт с первого семпла

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

Vort то есть, если идут пинги 40мс 40мс 40мс 40мс, то раньше код выдавал 20мс 30мс 35мс 37мс. теперь же (с моим изменением) так и будет 40 40 40 40

Vort для различающихся значений, понятно, будет усреднение

onon Сделал повторные замеры количества "пустых" туннелей. На обновлённом роутере пустых - 66,06%; на не обновленном 56,23%.

Vort это одновременно работающие узлы ?

onon Естественно

Vort сейчас кстати волна атаки пошла

Vort могла попортить вычисления )

onon И вправду

onon Tunnels:

onon Queue size: 6383

Vort CPU сколько занят?

Vort у меня Queue size: 0. но у меня и дестинейшенов мало

onon Там транзиты строятся по 100 в секунду

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

orignal 1

onon Это только на 1 роутере такое

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

Vort всё же 0мс когда 0мс лучше, чем хак

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

orignal неправильно у тебя

orignal uint64_t m_Latency; // in milliseconds

Vort ну и что?

orignal чини

orignal а ты ему -1 ставишь

Vort компилятор знает эту фишку

Vort мне не хотелось туда кучу fffff пихать

orignal не надо -1 ствить безнаковому

Vort некрасиво?

orignal лучше поменяй на int64_t

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

Vort а зачем там 64 бита вообще?

Vort может и 32 хватит?

orignal да можно 32

orignal да сделай просто int и все

Vort сейчас попробую. и потестирую

Vort заодно гляну как пингуется узел под атакой )

onon На других роутерах тоже бывает очереди проскакивают. Tunnels: Queue size: 260

Vort если атака не уйдёт пока код допишу

orignal ну или как я предлагаю пришел ответ 0 ставить 1 и все

Vort onon: у меня стабильно 0

orignal да новая атака Transit Tunnels: 35761

orignal мне в приниципе не нравится 0 когда реально там не 0

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

Vort с округлением до целых - вполне себе ноль

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

Vort у меня на локалхосте стабильно 0мс выдаётся. так я это и заметил

orignal ну вот если не 0 всегда ставить 1 и все

orignal я обычно везде так делаю

orignal ладно завтра продолжим

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

Vort ок

orignal причина всего этого одна. псих

orignal еще слищком много его кода который надо переделаывать

onon1 Давайте в лог добавим что-то вроде "Пришел запрос на построение транзитного туннеля от ХХХ."

onon1 Мне кажется, что такое количество запросов он делает напрямую, не через туннели.

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

Vort а зачем ему через определённый узел слать?

Vort я думаю нагрузка по всей сети размазана

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

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

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

Vort то есть, сравнить два набора данных

Vort orignal: посмотрел, где вызывается GetMeanLatency(): 1. для вывода значения в HTTPServer. 2. в TunnelPool для выбора туннеля с наименьшим пингом. 3. в TunnelPool для выбора туннеля с HasLatencyRequirement (через LatencyFitsRange())

Vort нигде там не вижу деления (на ноль)

Vort по поводу новой версии моего изменения: как я уже понял, вызов GetMillisecondsSinceEpoch() ненадёжен и может давать значения из будущего, поэтому для избежания добавления отрицательных пингов сделал проверку if (dlt < 0) dlt = 0;

Vort тьфу. из прошлого*

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

Vort надо будет ещё логирование добавить, тогда станет понятнее

onon Какое у нас новое максимальное значение для транзитных туннелей?

rev 20 000

Vort onon: стандартное или вообще?

onon Максимум

rev по умолчанию

Vort миллион вроде

rev если не указано иное

onon Transit Tunnels: 71704

Vort ого

onon Поставлю миллион, посмотрим

rev а какой у тебя ulimit?

onon 8192

Vort маловато для такого количества транзитов

Vort ну если не пустые

rev ну тогда ставь ulimit -n unlimited

Vort у меня в 2 раза меньше транзита:

Vort Transit Tunnels: 33448

Vort Transit: 80.42 GiB (2692.10 KiB/s)

onon Transit Tunnels: 95311

onon Transit: 97.19 GiB (2850.48 KiB/s)

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

Vort можно проверить кластеры IP адресов на всякий случай. надо вообще инструмент для этого сделать

Vort прошлые атаки просто бывали с группы адресов

Vort сейчас вроде никто не жаловался, но мало ли

Vort Transit: 81.16 GiB (3809.73 KiB/s) Transit Tunnels: 38261

Vort скоро в лимит по трафику упрёт если так и дальше будет

onon Transit Tunnels: 109871

Vort рекорд

onon Туннели на сервисах не строятся.

onon Которые есть продолжают работать, новые не строятся.

Vort у меня строятся, но вяло, понятное дело

onon Transit Tunnels: 116502 Transit: 98.38 GiB (3617.03 KiB/s)

onon И это последняя сборка, если что.

Vort как думаешь - с одного компа такую атаку реально делать?

Vort это я к тому, стоит ли кластеры адресов искать

onon Хз, я не пробовал.

Vort проверил у себя кластеры - ничего особо интересного не нашлось. максимум - около 10 узлов с 8 битной подсети

Vort правда смотрел только ipv4

onon Вроде, стабилизировалось. Выше 130к не поднимается. Вероятно новые запросы прибывают со скоростью, с которой "старые" начинают дропаться

Vort у меня как и в прошлый раз максимум был около 40к

Vort до лимита не дошло

onon Transit Tunnels: 150006

Vort а у меня вниз идёт

Vort Transit Tunnels: 33093

onon Transit Tunnels: 200100

onon Интересно, атакующий много ресурсов тратит на шифрование сообщений для строительства туннелей?

Vort это точно не от твоих модификаций в коде? я просто у себя такого не вижу

onon Врят ли.

onon На других роутерах с теми же модификациями, такого нет.

Vort про ресурсы для шифрования не знаю

onon Попробовал построить через этот роутер двунаправленный 1хоп туннель. Туннель строится без проблем, вот только пинг примерно на порядок выше, чем без атаки.

Vort постоянно высокий или колеблется?

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

onon Колеблется

onon Похоже, успокоился акакер. Туннели вниз поползли. Выше 230к не поднялись.

Vort опять вверх количество транзитов ползёт. Transit Tunnels: 28568

Vort а вот это уже мой рекорд: Transit Tunnels: 53147 (максимум на моём узле)

Vort Transit: 98.48 GiB (3386.75 KiB/s)

tetrimer По моим графикам: на двух серверах более менее синхронно падает количетство роутеров, флудфилов и tcsr.

Vort firewalled вылез может?

Vort или вылезал

tetrimer Они по-жизни за натом

tetrimer Долго висит Network status: Firewalled (Testing)

Vort похоже или на проблемы с сетью или на зависание i2pd

tetrimer На втором: Network status: Firewalled - Symmetric NAT но картинка - та же

Vort стоит потыкать пиртест

Vort а трафик идёт?

tetrimer На первом - тыкал минут 25 назад.

tetrimer Транзита - ноль, но это так всегда, а свой трафик - идет.

tetrimer Живых стримов - 6 штук

tetrimer Т.е. вроде как всё живое.

tetrimer Похоже, опять забивают сеть мертвыми роутерами.

tetrimer Надоело ждать милостей от природы: поднял у себя функционал ацетонового майора.

rev атака идёт?

orignal счас похоже опять трафиком

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

Vort Transit Tunnels: 53143

Vort Transit: 154.41 GiB (2878.28 KiB/s)

rev у меня впска кладёца

rev казлэ

Vort CPU перегружен или что?

rev да

Vort а трафика сколько ?

Vort может стоит лимит трафика поставить

rev под 3 мегабайта/с

Vort ну вот 2.5 можно лимит поставить

rev вот такой лимит и стоит

Vort или 2. чтобы CPU перестало перегружать

rev ну придёца

rev самое интересное впн стал отваливаца

rev я не сразу сообразил чо происходит

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

orignal Vort я имел ввиду будушее использование. у нас функция говорит что время есть а значение выадет 0

orignal rev поставь bandwidth=1000 для начала

rev orignal: я поставил ipv4=false

rev впизду

rev надоело

rev зате теперь всё летает

rev зато

onon Дезертир!

orignal ну это читерство

orignal ты добейся чтобы с ipv4 летало

orignal например с 1000

rev не будет

rev оно не будет клиентские тунели строить

orignal будет

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

orignal это только на транзит

tetrimer rev: Можно флудфил выключить - станет полегче.

rev во время атаки количество исходящих клиентских 0

orignal ну так если у него ipv4=false у него уже не флудфил

rev а с ipv6 only всё отлично

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

orignal толко у тебя не флуфдил

Vort "<~orignal> Vort я имел ввиду будушее использование." а я говорил про округление. 0.2мс, допустим, округляется до 0мс. 0.8мс округляется до 1мс. нам большая точность не нужна, так что целые числа иметь логично

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

rev Router Caps:99,99 XfR

rev Version:99,99 2.50.2

Vort но просто портить данные из-за того, что может произойти в будущем (а может и не произойти) - мне это не понятно

orignal Vort а если 0.1?

Vort можно комментарий добавить, что 0мс тоже бывают

rev Network status:99,99 Unknown

rev Network status v6:99,99 OK

rev Tunnel creation success rate:99,99 18%

rev Received:99,99 6.48 GiB (118.58 KiB/s)

rev Sent:99,99 7.08 GiB (121.42 KiB/s)

rev Transit:99,99 4.67 GiB (79.04 KiB/s)

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

Vort обрезание - это тоже округление

Vort к минус бесконечности допустим

orignal 0.8 будет 0 или 1?

Vort есть несколько разновидностей

rev Routers:99,99 1514 Floodfills:99,99 508 LeaseSets:99,99 159

rev Client Tunnels:99,99 31 Transit Tunnels:99,99 6146

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

orignal просто еще не все получили обновления

orignal скоро лизсетов станет 0

orignal ты фледфил то выключи а то тебя еше и забанят

rev а меня нет в ipv4

rev а в ipv6 я ничего не нарушаю

orignal нарушаешь

rev что?

orignal ты флудфил держить там где не имеешь право

onon Прокурору бедешь рассказывать... не нарушвешь.

rev у меня нет ipv4 адреса

orignal тебя сеть может посчитать фейком

orignal заебал

orignal тебя узлы будут выкидывать из netdb

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

rev какой адрес сеть будет выкидывать из netdb?

onon RI

orignal твой роутер

onon Со всеми адресами

orignal считать что тебя нет

rev ну ок

rev вырублю

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

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

Vort en.cppreference.com/w/cpp/chrono/duration/duration_cast

Vort casting to an integer duration is subject to truncation as with any static_cast to an integer type.

Vort в i2pd GetLocalMillisecondsSinceEpoch

Vort return std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::system_clock::now().time_since_epoch()).count ();

orignal естественно там truncate

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

Vort там бОльшая проблема есть. но я пока что мало разбирался, как её решать

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

orignal так есть же они

orignal посмотри в RouterContext

orignal там uptime берется с монтонных

orignal uint32_t RouterContext::GetUptime () const

orignal {

orignal return std::chrono::duration_cast<std::chrono::seconds> (std::chrono::steady_clock::now() - m_StartupTime).count ();

orignal }

onon Лось, много ли мощностей атакующий задействовал на генерацию 230к транзитных туннелей? Он же эти сообщения шифрует всётаки.

orignal мизер

orignal счас же не эль-гамаль там

onon Тогда странно, что не нагенерил больше...

orignal ума не хватило

СуперПуперПогромист В i2pd же вроде 17 стандарт, да?

СуперПуперПогромист Почему не 20 использовать везде? Там многий код можно было бы на корутины переписать вместо каллбеков

СуперПуперПогромист boost asio же имеет их у себя

СуперПуперПогромист Да и концепты из 20 тоже тема

СуперПуперПогромист Да и вообще в 20 стандарте много полезного

СуперПуперПогромист orginal

onon Анонимус перелогинься

СуперПуперПогромист Уже узнали меня что-ли

onon По старому ключа зашел же

СуперПуперПогромист Не, ключи перезапускались

СуперПуперПогромист Эх, ладна

onon Значит в клиенте забыл старый ник сменить

orignal нет 11-ый

sha512sum Да не, я поменяла ключи, зашла, но забыла ник сменить. Ну щас ещё раз ключи поменяла и зашла. Ключ поменялся вроде.

sha512sum Ну так вроде cmake проверял на CXX17

sha512sum А почему не перейти на свежие стандарты?

sha512sum if(CXX17_SUPPORTED) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17") elseif(CXX11_SUPPORTED) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

sha512sum Метапрога намного приятнее на новых стандартах

sha512sum C++17 как по мне с fold expressions вообще необходим, чтобы не делать рекурсию на каждом шагу

orignal по кочану

orignal иногда 17 использщуется под ifdef

orignal 11 потому что еще есть CentOS 7 и Ubuntu 16.04

sha512sum А почему бы не поставлять туда уже в собранном виде бинари? Статик линковка жеж. Ну а если собирать, то ИМХО приятность написания важнее, чем поддержка древних осей

sha512sum А с момента C++20 довольно достаточно времени

onon А почему у жабоводов по поводу атаки ничего не слышно? Или их это не касается?

orignal потому что я предпочитаю 11

orignal onon слышно

orignal у них те же проблемы

onon А где они все тусуются? На форуме и в ирке тишина...

sha512sum ~orignal, ну это ИМХО неправильно. Новые стандарты надо изучать, прогресс же идёт всё таки

sha512sum А могу я поинтересоваться, почему 11?

Orion Router Caps: XfRD добавилась "D". Упирается во что-то?

onon Пока ещё не упирается, но приближается

orignal Orion уже на грани значит

orignal sha512sum почему 11 а не 98?

sha512sum Потому что вариадик паки

sha512sum en.cppreference.com/w/cpp/language/parameter_pack

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

orignal если понадобится что то из 20 ого буду использовать

sha512sum Ну так и я так же

sha512sum Ну и мне просто пригождаются вещи из 20 ого

orignal как из 17-ого в чатсности слияение списков

orignal #if (__cplusplus >= 201703L) // C++ 17 or higher

orignal m_SentPackets.merge (resentPackets);

orignal #else

orignal m_SentPackets.insert (resentPackets.begin (), resentPackets.end ());

orignal #endif

orignal например

orignal надо будет что то из 20 добавлю

sha512sum Ну вообще самое полезное это части языка, а не стдлибы всё таки.

sha512sum en.cppreference.com/w/cpp/language/lambda Вот например лямбды сильно прокачали в новых стандартах

sha512sum en.cppreference.com/w/cpp/language/fold Вот из 17 стандарта полезное

sha512sum en.cppreference.com/w/cpp/language/constraints en.cppreference.com/w/cpp/language/coroutines en.cppreference.com/w/cpp/language/modules en.cppreference.com/w/cpp/language/aggregate_initialization#Designated_initializers

sha512sum А из стдлибы там ренжи, формат

sha512sum Что это было

onon Отвал моста.

onon Давай лучше нам стримы почини

orignal нетсплит

sha512sum Так полезные же новые возможности плюсовые. Ренжи так вообще кайфовые, концепты лямбды, корутины

orignal мне они пока не нужны

sha512sum orignal, ну корутины бы могли облегчить читаемость кода. Какой-нибудь userver с корутинами и код при этом асинхронный и выглядит просто

orignal а мне проще так

sha512sum Я бы всё таки посоветовала попробовать пописать со всеми новшествами от C++14 до C++20. Можно очень удобные интерфейсы делать на шаблонах. Тот же мой PR в userver. Ну или я просто так написала хуйню, там везде новые стандарты

orignal ну я буду писать так чтобы работало

Vort "<~orignal> но мы может микросекунды боать" дело в том, что один из таймстмпов берётся из сообщения DeliveryStatus, а там миллисекунды. не знаю, зачем их вообще передавать для пинга но так вот сделано

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

orignal почему нельзя? главное ведь разница

orignal и монотонность надо в первую очередь и фнункции в Timestamp написать

Vort "<~orignal> и монотонность надо в первую очередь и фнункции в Timestamp написать" ну пинги то мы сами себе отправляем, тут без разницы. но в других каких-то местах эти же данные другие узлы будут обрабатывать? и вот там нужна коррекция

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

orignal про те я и говорю

orignal естественно в большинстве разные

orignal но вот в пингах как раз можно монотонный

Vort никто кроме нашего зла его не прочтёт?

Vort узла*

Vort :)

Vort функции формирования таймстама там вроде общие для DeliveryStatus. а вот в каких случаях это сообщение применяется - я не знаю

Vort std::shared_ptr<I2NPMessage> CreateDeliveryStatusMsg (uint32_t msgID)

Vort про пинги я уже знаю. а где ещё оно есть - без понятия

orignal никто в принципе

orignal потому что он зашифрорван для нас

orignal оно много где

orignal для пингов надо отдельное

Vort а, так если зашифрованное, так вообще полностью пофиг что туда тыкать?

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

orignal да

orignal но оно только для пингов

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

Vort я понял - можно мигрировать пинги с DeliveryStatus куда-то ещё

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

orignal да

orignal почему то вообще DeliveryStatus а не отдельное сообщение дед как всегда сослался на jrandom-а

Anonymous R4SAS: ssssssssssssssssssssssssssssssssssssssssssssssssss

Anonymous approve commit when?

Anonymous i2pd.readthedocs.io/en/latest/tutorials/filesharing