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

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

onon skmem:(r0,rb2621440,t0,tb2621440,f4096,w0,o0,bl0,d0)

onon Аптайм примерно 10часов

onon Попробую пообновлять другие роутеры тоже.

orignal может все так не с последним а с предпоследним?

orignal потому что последий был явно про netdb

onon С тем, где ты с очередями мутил

onon на SSU2

onon 1246988 this

orignal ну да но он не последний

orignal потом я взялся мутить другое ))

onon Ты мути отправку небольшими пачками лучше, это важно.

onon Но правда, там работы много.

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

onon Тогда не отвлекайся

onon1 Ещё нужно добавить проверку лизсета, что бы он был опубликован не более 10 мин назад. Я нашёл у себя лизсет с очень старой датой публикации.

orignal а дата протухания какая?

orignal в смысле время

onon1 Истечение лизов нормальное

onon1 По дате последнего лиза

orignal нет у него есть время

orignal именно протухания

onon1 А нет

onon1 На минуту больше

onon1 Чем у лиза

onon1 Самого старшего

orignal ну это нормально

orignal скорее всего джвисты так делают

orignal и мне надо

onon1 Там дата публикации 31/12/1969

orignal иначе говоря там время 0 стоит

onon1 Он такой единственный

onon1 Остальные нормальные

orignal да надо сделать проверку

onon1 Модифицированный клиент похоже

onon1 Ещё там несколько инвалидов есть

orignal да проверку добавлю это правильно

onon1 Хз, что за такие

onon1 !!! Invalid !!!

onon1 как-то так

orignal да это типа 5

orignal просто псих хуйню сделал там

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

onon1 Да

orignal для роутеров все это сделано а для лизсетов нет

` <onon1> Там дата публикации 31/12/1969

` Как это так, до нашей эры?

` Первым делом root сотворил 1970-01-01 ☝🏻

` Blinded message

Vort "<onon1> Потому что сейчас он слишком долго ждёт" если я правильно помню, скорость создания туннелей от таймаута не зависит

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

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

Vort (хотя один из методов понятен - надо пиртест чинить, это ситуацию явно улучшит, но не сильно - есть ещё проблемы)

weko Vort: да нихрена не тратит

weko Сеть в обычном состоянии перегружена по твоему?

weko Ну точнее тратит это да, но вот от скорости это не отжимает

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

onon Лось, тогда придётся тебе делать таймауты строительства туннелей. Ворт, похоже, не понимает как это работает.

orignal а я что не делаю что ли?

onon1 Ну ты пока стримы делаешь вроде.

onon1 Вот тебе ещё в туду лист

WayBest_ <~orignal> еще надо проверку сделать что время пубдикации не из будущего

WayBest_ а как мы гарантируем что время на машине ок?

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

orignal 2 минуты допустимо

weko Опять пошло говно по трубам?

Vort "<weko> Опять пошло говно по трубам?" - 599 штук "2.5.1" у меня в netdb. было раньше около 150

weko Значит пошло

Vort "<weko> Сеть в обычном состоянии перегружена по твоему?" - в состоянии низкого рейта - да. < ~15% TCSR - и узел хреначит построения нон-стоп

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

weko Но кажется я понял про что ты

weko Если убрать этот лимит будет перегрузка

Vort "<weko> Ну точнее тратит это да, но вот от скорости это не отжимает" откуда тогда фоновый трафик ~полмега/сек? пинги + построения мне кажется

orignal понятно что они будут засирать

weko Vort: ну ещё флуд

weko Vort: ну сравнительно мало

Vort "<onon> ... Ворт, похоже, не понимает как это работает." если моё описание неверно, то предлагаю рассказать, где именно. пока что мне кажется, что это твоё предложение исходит из непонимания

weko Если убрать лимит будет жопа

Vort "<weko> Если убрать этот лимит будет перегрузка" - обратная связь будет. больше построений -> больше фейлов -> больше построений. сейчас есть "failsafe". или как оно там зовётся

weko Vort: так я об этом же

weko Только всё ещё хуже

weko Ведь тогда будет больше узлов которые упёрлись в лимит

Vort угу

weko А значит что ещё больше фейлоа

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

weko Думаю надо для начала сделать чтобы был TCSR 100% хотя бы в тестнете

Vort weko: не будет :( но 99% можно

weko Vort: да просто строиться не успевают

Vort я же рассказывал про хитрую проблему в i2p

weko Vort: ну если дропов не будет

onon Vort, объясняю. Если у тебя в нетдб, напрмер много фейковых роутеров и ты пытаешься строить через них туннели. Они тебе не ответят, сколько бы ты ни ждал, понимаешь?

weko То можно и 100%

weko Vort: какую?

Vort weko: значит не читал мой рассказ

weko Vort: а в чём суть?

Vort потери пакетов в i2p "by design" - из-за коллизий идентификаторов

Vort это мелочи, но эта хрень 100% достичь не даст

Vort "парадокс дней рождения" даёт о себе знать

weko id туннелей имеешь ввиду?

Vort да всего почти. i2np сообщений, допустим

weko Ну тоже да

Vort пожалели 64 бита на идентификаторы, а теперь исправить это нереально

weko В любом случае на тестнете ssu2 only я получаю ~70%

weko Но у меня там 8 хопов стоят туннели

Vort 70% - это стабильное значение? просто при старте какие-то узлы же будут оффлайн

weko Vort: ну пару секунд

weko 10 секунд

weko Запускается 200 роутеров

Vort так эти несколько секунд вполне рейт немного просадят

weko Помнишь я кстати говорил про штормы, которые сами собой образуются?

weko Именно в тестенете

Vort короч если стабильные 70% - значит где-то жирный баг сидит

weko Vort: ну можно подождать

weko Вот штормы точно есть. Два раза было

Vort weko: а ты CPU мониторил?

weko Vort: да

weko Там дохуя

weko Какой-то тред упирался

weko Какой уже не помню

Vort просто при перегрузке i2pd вообще себя неадекватно ведёт, этот вариант пока что даже рассматривать не стоит

weko Можно в логах найти

Vort попробуй без перегрузке по CPU на рейт посмотреть

weko Несколько основных роутеров, которых штурмует, остальных думаю как побочный эффект задевает

weko Vort: так перегрузка только когда шторм

weko А это не часто случается

weko Надо ждать

Vort а, понял

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

Vort weko: ты же давно тесты делал, много багов с тех пор починено, может уже и не будет такого эффекта?

weko Не знаю. Это херня случайно появляется

weko Эта

weko Но как я сказал была два раза, так что не так уж редко

weko Вполне может быть что какая петля образуется

Vort weko: так это на последних версиях было или нет?

weko Vort: на тот момент была последняя

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

Vort onon: хоть за секунду не ответят, хоть за 30 секунд - на скорость построения туннелей это не повлияет. ну или если считаешь, что повлияет, то расскажи, почему

onon Потому что я поставил таймаут на 10 сек и мне стало хорошо =)

onon Не предлагаю никому так делать, дисклеймер.

Vort TUNNEL_CREATION_TIMEOUT - вот это?

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

onon а константа мне не нравится

onon TUNNEL_CREATION_TIMEOUT = 10;

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

Vort "<onon> Нужно реальное значение выставлять" - адаптироваться к багам и глюкам - сомнительная идея

onon Хорошая идея.

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

onon Из того, что я предложил, хуже точно не станет.

onon Если будет много фейлов, он точно так же будет болтаться около максимального таймаута.

onon А при нормальной работе будет реагировать быстрее

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

onon Хотя, наверное, это можно сделать уже сейчас. Но некому.

onon Vort, извини, ты был прав. Я не прав, это действительно ни на что не влияет.

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

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

onon Мне не совсем понятно это:

onon auto msg = m_Queue.GetNextWithTimeout (1000); // 1 sec

onon И вот это

onon msg = (numMsgs <= MAX_TUNNEL_MSGS_BATCH_SIZE) ? m_Queue.Get () : nullptr;

onon Он 256 сообщений собирает и раз в секунду tunnel->FlushTunnelDataMsgs ();

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

Vort по второй части - не знаю

Vort а, понял вторую часть - она просто собирает все сообщения из очереди (если их меньше 100)

Vort если больше 100, то обрабатывает пачками по 100

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

Vort подробней про GetNextWithTimeout: если сообщения в очереди есть, то вызов отработает очень быстро. 1 секунду будет ждать только если очередь пустая

onon Откуда взялось число 100

Vort const int MAX_TUNNEL_MSGS_BATCH_SIZE = 100; // handle messages without interrupt

Vort а вот почему именно 100 - не знаю, наверно наугад

onon И если очередь пустая, тред будет спать и ничего не делать?

Vort но я подозреваю, что это значение не критичное, и 10 и 1000 будут работать

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

orignal да это от фонаря я поставил

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

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

Vort в каком месте он засыпать должен?

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

Vort так где этот wait будет?

orignal в GetNextWithTimeout

Vort если очередь набита, то, думаю, ожидания не будет

orignal да не будет

orignal я видимо потом переделал ))

Vort )

orignal как всегда

orignal по сути тот кусок кода счас можно выкинуть

orignal msg = (numMsgs <= MAX_TUNNEL_MSGS_BATCH_SIZE) ? m_Queue.Get () : nullptr;

orignal а нет вот что

orignal все дело в этом

orignal tunnel->FlushTunnelDataMsgs ();

orignal мы делаем флаш или когда все сообщения прочли или каждую сотню

orignal но 100 это много

onon1 А почему не по 1му

onon1 Я так понимаю, он уже на транспорт перекладывает

orignal потому что они дальше пакуются пачками

orignal не всегда

orignal бывает что и входящие в тоннель

orignal вот тогда и имеет смысл паковать пачки

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

orignal отослать 1 фрейм в 16K куда как лучше чем 16 фреймов по 1K

orignal я бы заменил 100 на 16 для начала

onon1 В общем, я надеюсь донёс мысль про очереди и вставку туда больших пачек сообщений.

onon1 Очередь может быть уже не пустая.

orignal почему? потому что в NTCP2 счас фреймы по 16k

orignal <onon> Он 256 сообщений собирает и раз в секунду tunnel->FlushTunnelDataMsgs ();

orignal флаш не раз в секунду а когда очередь пустая или 100 накопилось

orignal предлагаю поменять на 16

onon1 Это я ошибся, не ту переменную посмотрл

onon1 А так да, меншими пачками лучше

orignal и для 16 есть рациональное основание в виде разумера фрейма NTCP2

onon1 А с какой периодичностью он будет вставлять?

orignal когда набралось 16 или в очереди пусто

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

relaybot 13apophis: так что, опять атаки возобновились или мен показалось ?

onon Я всё равно не догоняю, как это работает, я не вижу что бы он куда-то складывал сообщеня

onon Он их только считает.

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

orignal в TransitTunnel.cpp посмотри что куда складывается

Vort apophis: атака уже длится неделю, но сегодня усилилась

relaybot 13apophis: ясно, спасибо за подтверждение

orignal там просто цикл do-while

orignal там в начале идет обраюботка

orignal Vort намногол усилилась?

orignal я не вижу большой разницы

Vort раза в 3-4

Vort я мусор в netdb считаю просто

orignal ну так уменьшим это 100 до 16?

Vort я без понятия как измерять эффект, так что не знаю

orignal кстати я вспонил еще почему мы входил их этого цикла если 100

orignal чтобы тоннели обсулужить

orignal очистку там построение и прочее

orignal но 100 это реально много

onon Я всё равно не вижу, где бы он размер передавал.

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

Vort но вообще смысл понимаю, да

Vort в теории

orignal разумер чего?

onon Как я понимаю, он их всё-таки отдаёт по одному, а после того как отдал 100, переключается на обслуживание туннелей

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

orignal он по одному их расшифровывает

orignal этот тяжелый код в TunnelEndpoint тоже там же

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

orignal если 100 сообщений подряд обработал делает flush

orignal и переключасется на обслуживание

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

Vort ну вот тогда важно делать паузы, да

orignal но там же на веб морде видно

orignal Tunnels:

orignal Queue size: 0

orignal она почти всегда 0

orignal но бывают скачки

orignal меня бекспоит больше когда 100 пакетов подряд с одного тоннеля прилетело

onon Вот только не понятно, зачем они в одном цикле... Менеджер туннелей и обработка пакетов

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

orignal onon согласен TunnelData и TunnelGateway можно вынести

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

orignal а они в одном цикле с менеджером чтобы в одном треде

orignal Vort вот я и предлагаю 16

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

orignal в каком?

Vort <~orignal> Queue size: 0

orignal и в чем вопрос то?

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

orignal приходит

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

orignal потому что в NTCP2 мы фрейм сбрасываем за раз

Vort сейчас подумаю, как лучше объяснить

orignal смотри

orignal в NTCP2 мы получаем фрейм целиком

Vort понятно, что очередь будет набираться. не понятно, почему она не может рассосаться мгновенно, допустим, за 10мс

orignal после чего читаем I2NP блоки по одному

orignal а тоннельные мы накапливаем

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

orignal рассосется мгновенно разумеется

Vort тогда её практически нереально в интерфейсе заметить

orignal бывает иногда щтук по 10 сам видел

orignal потому что в этом треде криптография

Vort ну смотри - допустим, 10мс работает, 990мс ждёт. шанс заметить очередь - 1%

Vort ну и сколько процентов времени тред активно жрёт CPU ?

orignal дохуя кстати

orignal S 22.2 9.9 306:52.16 Tunnels

Vort транзитные туннели тоже в этом потоке?

orignal на 2RRY

orignal 22% ядра весьма немало

orignal да тоже в этом же

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

orignal разумеется отправка уже в других

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

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

Vort вот ты говоришь, что надо Manage дёргать. раз в секунду же нормально делать проверку, верно?

Vort и сколько за секунду сообщений тред может переработать?

Vort вот мне кажется, что это не 16 и не 100

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

Vort ну вот значит Manage - не главная причина для перерывов в обработке

orignal а кто сказал что это причина?

orignal я не понимаю о чем вообще речь

Vort <~orignal> кстати я вспонил еще почему мы входил их этого цикла если 100 / чтобы тоннели обсулужить

Vort вот я говорю, что туннелям так часто не надо

orignal возможно

orignal говорю же я это от фонаря сделал

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

onon А мы теперь разбираемся и ищем в этом "Скрытый Глубокий Смысл"

orignal ну я писал по прициипу "лишь бы как то работало"

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

orignal первое что в голлову пришло

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

Vort это к onon вопрос

Vort он туда зачем-то полез

onon Это я открыл рандомный файл в libi2pd и начал задавать вопросы.

onon Я часто так делаю...

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

onon Вы ещё не заметили?

Vort стандартная процедура при поиске багов, понятно

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

orignal я вот как раз и занимаюсь разделением netdb на 2 треда

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

Vort иначе это шанс создать глюки без заметного положительного эффекта

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

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

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

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

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

orignal нет там уже не файлы

orignal там зоопарк ненужных мьютексов

Vort я поддерживаю рефакторинг до тех пор, пока он не становится самоцелью

orignal самоцели тут точно нет

Vort "любую проблему можно решить увеличением количества абстракций, кроме проблемы слишком большого количества абстракций"

onon Ещё вопрос мимо темы:

onon Когда он делает auto leaseRouter = i2p::data::netdb.FindRouter (path->remoteLease->tunnelGateway);

onon Он же потом полезет на флудфил, искать этот роутер?

orignal тоннели же считаю и счас неплохо работают

onon Плохо работают

onon Когда придумаю, как сделать лучше, расскажу.

orignal нет эта функция делает только локальный поиск

orignal полагаю он так выбирает тоннель

orignal исходящий

orignal чтоюы была совместимость

onon Да, это так для понимания.

orignal а если нет роутера в нетдб то и не ищет

orignal кстати в том цикле в тоннелях может ограничивать не число сообщений а время?

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

orignal да нет причин для разеления на блоки

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

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

orignal еще флэш сообщений в тоннели

orignal если у тебя поток с одного идет подряд

Vort нормально ли его дробить по времени?

Vort ну и вообще - как часто его надо делать?

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

Vort сбрасывать, но из цикла не выпрыгивать?

orignal да

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

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

Vort вроде норм

onon Лось, я придумал как просто сделать определение ретрансмита в стримах.

onon if (receivedSeqn <= m_LastReceivedSequenceNumber)

onon {

onon // we have received duplicate

onon LogPrint (eLogWarning, "Streaming: Duplicate message ", receivedSeqn, " on sSID=", m_SendStreamID);

onon SendQuickAck (); // resend ack for previous message again

onon if (receivedSeqn <= m_PreviousReceivedSequenceNumber)

onon {

onon m_CurrentOutboundTunnel = m_LocalDestination.GetOwner ()->GetTunnelPool ()->GetNextOutboundTunnel (m_CurrentOutboundTunnel);

onon UpdateCurrentRemoteLease ();

onon }

onon m_PreviousReceivedSequenceNumber = receivedSeqn;

onon m_LocalDestination.DeletePacket (packet); // packet dropped

onon }

onon Ложное срабатывание будет только если при ретрансмите будет реордеринг пакетов.

onon Только SendQuickAck (); конечно после проверки перенести

onon Это я поспешил

` #офтоп. Why отступ 8 проблемофф?

onon табы

` табы не по 4? как-то жырно смотрица

onon В редакторе ставишь сколько хочешь

onon 1 таб = 2 спейса

orignal у меня есть еще лушчше идея

onon Давай

orignal if (receivedSeqn == m_LastReceivedSequenceNumber)

orignal менять тоннели

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

onon Типа если до конца списка дойдёт

orignal да

onon Вроде логично

orignal перепосылка самого свежего

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

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

onon Не, лучше сделать как я предложил

onon Сейчас объясню почему

onon Потому что ретрансмитить в пустоту всё окно - плохая идея. Потом мы переделаем, чтобы слал по одному пакету, как у меня сделано. И тогда == перестанет работать

onon А то что я предложил будет работать в обоих случаях.

orignal так на этой стороне мы же не делаем ретрансмит мы толлько ack шлем

onon Я про то что отправитель в будущем, не будет слать всё окно

onon Потому что бесполезная нагрузка на сеть

onon Мы переделаем потом

orignal так наша цель доставить ему ack

orignal тогда он сразу перестанет

onon Ну, так мой код сработает так же

orignal не надо лишнюю переменную держать и думать о ней

onon Зато универсально

onon И с заделом на будущее

onon Единственный момент, если проверять на == сработает при первом же ретрансмите, а в моём коде на втором

onon Думаю можно добавить в мой код проверку == тоже

onon Вот так вот:

onon if (receivedSeqn <= m_PreviousReceivedSequenceNumber || receivedSeqn == m_LastReceivedSequenceNumber)

onon {

onon m_CurrentOutboundTunnel = m_LocalDestination.GetOwner ()->GetTunnelPool ()->GetNextOutboundTunnel (m_CurrentOutboundTunnel);

onon UpdateCurrentRemoteLease ();

onon }

onon m_PreviousReceivedSequenceNumber = receivedSeqn;

orignal возможно