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

orignal Vort у нас никаких у деда вроде 10

orignal короче я вернулся

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

Vort но юзер, похоже, свалил из чата. если зайдёт, надо будет рассказать

orignal но это касается только публикуемых

orignal без публикуемого IP ограничений нет

Vort вопрос был о том, что i2pd не занимает весь канал (200 мегабит/с) или около того. ну я и предложил побольше узлов запустить

Vort 10 штук, думаю, для такого сценария достаточно

orignal вполне можно

orignal главное не флудфилы

Vort а чем плохо флудфилы?

orignal тем что посчитают это атакой

Vort java ? или и i2pd тоже?

orignal джава и дрозд

orignal мы нет

Vort ок, понятно

Vort надо наверно в доки добавить к требованиям флудфилов или рядом куда-то

Vort "only 1 floodfill per IP address is allowed"

Vort и вот в таком виде код довольно сильно глюканул - стрим завис то ли насовсем, то ли около того

Vort похоже, он не пережил события "Another outbound tunnel and remote lease has been selected"

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

Vort но скрин кину сразу же: paste.i2pd.xyz/?506893fccfa9409c#CbkYPpJCdzWNrd8C7ojamem8acGzbjkzvhG91yDohqPT

Vort pupok_temp: предварительная информация по количеству узлов на IP: можно до 10 штук, но флудфил из них только 1 должен быть (ну или ни одного, понятное дело)

pupok_temp О,благодарю. Сейчас работает 3 флудфила, на одном ip

pupok_temp как это я мимо бана прошёл, уберу 2 флага флудфила

pupok_temp будут 2 роутера и 1 роутер +фф

orignal ну скажем так

pupok_temp сейчас эти 3 роутера загрузили канал всего на 120мбит

orignal если i2pd этого не делает "это не ваша заслуга а наша недоработка"

orignal я добавлю

orignal нельзя такое делать

pupok_temp фраза знакомая, а я и не в курсе был, подозрения были но в документации к i2pd ничего о количестве не сказано

orignal ну там много чего не сказано ))

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

orignal для флудфила вообще много тербований

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

pupok_temp честно говоря, irc пиздец какой неудобный

orignal ну иди в телеграм ))

pupok_temp это я, человек привыкший к телеге

orignal сдавайся на милость дурова и фсб

pupok_temp нет спасибо, сквозь все невзгоды я тут)

orignal извини я как то упустил будучи на бора-бора кто ты по жизни будешь ))

pupok_temp использовал i2pd для андроид, и как только закрываю приложение, через секунду администратор панель перестаёт отвечать, может я где накосячил? мне интересна перспектива стабильной работы, "установил, раз запустил, оптимизацию уб

pupok_temp По подробнее, тебя какая часть моей жизни интересует? профф или ещё что

orignal про андроид не скажу

orignal я не в теме

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

pupok_temp ты думаешь нахер я поднял несколько роутеров? есть канал который от силы используется на 1процент, думаю остальное сильно пригодится этой сети, т.к моя нагрузка стабильная, хотелось бы дать стабильную нагрузку сетью i2p что бы э�

pupok_temp вижу будущее рф интернета как жутко зацензурированное, думаю тут лишний сервер с хорошим каналом будет совсем не лишним

orignal вот теперь понятно

orignal то есть ты хочешь тольо транзит гонять

pupok_temp есть ещё канал, но тот уже на 200, не на 300, может использоваться макс на 100, остаётся 100, и я их с радостью отдам, но нужно собрать рабочую конфигурацию из onu gpon терминала который отваливатся не будет

pupok_temp да, своих сервисом на базе этой сети нет, а для того что бы на сайты зайти внутри сети хватает скорости, даже если 100% транзит в конфиге

orignal кстати поверх ygg не поднимаешь?

pupok_temp нет, не пробовал даже сам ygg, но теорию немного знаю

pupok_temp этот irc пишет историю? чатов

orignal можно еще на нем роутер поднять

orignal ирк никогда не писал

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

pupok_temp слышал есть какие то расширения, но не углубляться

pupok_temp не знаю на сколько много пользы будет от ygg роутера, у них есть статистика сети? кол во роутеров и общая нагрузка за день например

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

pupok_temp когда i2pd запущен через ygg там в конфиге видел возможность

pupok_temp ?

pupok_temp много это сколько?

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

orignal у меня вот вообще 1.5 гигабита

orignal домашний

orignal запущено около десятка роутеров в разных конфигурациях

pupok_temp так сколько все таки можно? финальное число

pupok_temp что 1 фф это понятно

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

orignal я не мерял

pupok_temp очень советую скрипт с гитхаба для zabbix, я его немного доработал что бы общий трафик показывал

pupok_temp дальше графики и тд

pupok_temp удобно очень

orignal все я ушел

orignal вернусь вечером

pupok_temp я то же

onon Vort, это нормальный режим работы. Ненормальный он потому, что ему никто не отвечает. А он честно пытается слать по 1му сообщению в разные туннели, в ожидании ответа.

onon Я тут попробовал сделать пэйсер на таймерах, так оно тупо упирается в процессор.

onon Даже на одном стриме.

onon Я хз почему так, и как из этой ситуации выходить.

orignal пейсер это что?

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

onon Так у меня Destination сразу 100% CPU ест

onon Может это я чего неправильно наговнокодил

orignal значит у тебя таймер сразу зарершается

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

orignal проц не жрет

Vort onon: я говорю, что стрим завис, а ты говоришь "нормальный режим работы". с теми стримами, что сейчас в основной ветке - не виснет, значит можно сделать нормально

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

Vort как начинает отвечать - так и должна работа восстанавливаться

onon Ну так она и восстанавливается если отвечают

Vort не понимаю, почему это приходится объяснять - разве не очевидно, что стрим виснуть не должен?

Vort нет

Vort в том то и проблема

Vort короч ща логи кину

Vort скинул ссылку

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

Vort дошла ссылка?

Vort данные шли от узла #1 к узлу #2 через узел #3

Vort для узла #3 логов не отправлял, так как там стримов нету

Vort время можно сверять со скриншотом

Vort зависание случилось в 13:44:47

onon Смотрю уже

onon Это ты поймал тот баг, который я посчитал достаточно редким, и решил на него забить.

onon Сейчас подумаю как исправить.

onon Нужно в SendBuffer () добавить проверку после int numMsgs = m_WindowSize - m_SentPackets.size ();

onon Если больше 0 то проверить не делает ли это numMsgs = numMsgs - m_NumResendPackets; его меньше единицы.

onon И если делает, ставить numMsgs = 1;

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

Vort заметил только странное изменение: теперь при неудачном туннеле алгоритм ждёт не 9 секунд, а 27

Vort из-за строчки: m_ResendTimer.expires_from_now (boost::posix_time::milliseconds(m_RTO*3));

Vort мне кажется странным вот это умножение на 3

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

Vort также дальше по коду осталось условие: if (ts >= it->sendTime + m_RTO)

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

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

onon Он меняет туннель если на 3 ртт не получил ни одного аска

Vort кстати, количество транзитных туннелей сейчас на моём узле побольше стало: Transit Tunnels: 29203. может быть опять волна атаки

onon Transit Tunnels: 41313

onon Есть такое

Vort так всё же - какой смысл m_RTO в твоём коде?

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

onon Как обычно в общем.

Vort а, вижу, что таймер сейчас и вручную дёргается

onon Цель - максимально уменьшить количество ретрансмитов

onon Я не знал как его вызывать правильно, поэтому так через жопу

onon Я уверен, ты перепишешь это красиво.

Vort расщеплять эту функцию, похоже, надо

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

Vort я и нынешнюю версию этого кода понимаю не особо хорошо. твоё дополнение - так тем более

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

Vort подсунуть туда в параметр какую-то фигню и всё

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

Vort но правильнее, конечно, оставить таймер таймером

Vort если надо что-то отдельно вызывать, то отдельную функцию ему и сделать

onon Я думаю ты заметил, что все места где я что-то менял я пометил ////

Vort я и так вижу, что ты менял

onon Ну с гитом, проще

orignal что то до релиза еще надо менять?

onon Конечно

onon Надо или новый cc добавить или бесконечный буфер выпилить.

onon Они друг с другом не совместимы.

orignal в стримах?

onon Я уже писал, нынешний cc в стримах не совместим с бесконечным буфером в SSU2

onon А новому cc должно быть пофиг

orignal в SSU2 нет бесконечного буфера

orignal он есть только в стримах

onon Начинается...

onon Делайте как хотите, я устал с вами спорить.

onon Я, похоже смог написать таймер правильно, буду переписывать cc с добавлением пэйсера. Даже просто добавление пэйсинга в последнюю реализацию, даёт заметный результат.

orignal а что спрорить? я не понимаю о чем речь

orignal давай рассказывай что ты сделал

onon Я щас новый cc для стримов сделал с обратной связью через ртт, чтобы не перегрузать канал и не забивать буфера. Скинул ворту, он разбирается, тестирует.

onon А так как я научился делать таймеры, сечас сделаю ещё лучше.

onon Ну не в смысле прямо сейчас, а в смысле начинаю работать над этим.

Vort orignal: я уже сделал уменьшение размера буфера ( github.com/PurpleI2P/i2pd/pull/2047 )

Vort как раз ограничивает лаг, о котором беспокоится onon. но ему всё равно что-то не нравится, не ясно только, что

Vort onon: по коду CC: убирание m_RTO = INITIAL_RTO мне кажется сомнительной идеей

Vort после смены пути (туннелей) все предыдущие оценки или совсем или частично неверны

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

Vort 9 секунд (а не 27) на поиск RI - мне кажется нормальным значением

onon1 Все нормально, он успеет попрыгать по всем туннелям и вернуться на тот, который уже нашёл RouterInfo.

onon1 А потом, если опяту нужна смена туннеля, скорее всего уже всё будет готово

orignal смержил

Vort с новым кодом при создании туннеля прыжки получаются каждые 27 секунд. затем, допустим, если RTT будет 300мс, то каждые 0.9с. при том, что ситуация начала и средины не сильно отличается. непоследовательно как-то выходит

orignal Vort еще что то надо добавить?

orignal про стримы или еще что

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

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

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

Vort ну а касаемо нового алгоритма CC мне советовать что-то сложно. там дофига всего переделано (а будет, как я понимаю, переделано ещё больше), так что с ним существенный риск

orignal он уже есть в коде?

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

Vort есть ссылка на 2 файла авторства onon

orignal а то есть это его отдельный

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

orignal посмотрю позже