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

Vort onon: так что проверять надо? может, сегодня займусь

Vort кстати, похоже, что новая волна атаки пошла

Vort orignal: из-за последнего коммита опять вернулся баг с Incoming Tags: 340 и "Garlic: Can't handle ECIES-X25519-AEAD-Ratchet message"

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

onon1 Vort, 1. В Streaming.cpp 436 поменять m_RTT = std::round ((m_RTT*seqn + rtt)/(seqn + 1.0)); на m_RTT = std::round ((m_RTT*0.5)+((1.0-0.5)*rtt));

onon1 0.5 - это альфа, её нужно как-то обозвать и вынести в переменные, устанавливается от 0 до 1.

Vort EWMA, как и для TCSR. понятно

onon1 2. В Streaming.cpp 1002 поменять величину сброса размера окна. Я предлагаю сбрасывать на 10% за раз. m_WindowSize = std::round ((m_WindowSize / 10.0) * 9.0);

Vort вопроса два: 1. как оценить улучшение (или ухудшение), желательно численно. 2. по каким критериям подбирать альфу

onon1 Альфа влияет на скорость изменения RTT, чем ближе к 1 тем медленнее реагирует на изменения, ближе к 0 - быстрее.

Vort это я знаю

onon1 Оценить скоростью передачи данных в один поток

Vort на локалхосте?

onon1 Можно и так, я тестировал на всех длинах туннелей

onon1 Везде результат очень хороший.

onon1 На коротких туннелях очень быстро упирается в размер окна (128).

onon1 И скорость упирается примерно в 1 мб/с

tetrimer Да, у меня на торчащих наружу узлах трафик резко вверх рванул. И, опять-же, мертвые стримы и туннели.

onon1 Если поднимать размер окна до 256, можно разогнать до 2мб/с, но начали выскакивать сообщения в логе о превышении очереди на транспорте в 500 сообщений.

onon1 Следующий момент, это инкремент размера окна. По умолчанию делает просто m_WindowSize++. Я предлагаю как минимум += 2, а лучше + 1% за раз.

onon1 Потому как "медленный старт" очень уж медленный получается.

onon1 Ну и естественно при сбросе размера окна как-то считать, что если -10% меньше единицы, уменьшать на единицу, чтобы всё работало правильно.

onon1 И на инкременте, если +1% меньше единицы, увеличивать на единицу.

onon1 Ещё важный момент это m_RTO = m_RTT*1.5

onon1 Практика показывает, что *2 работает лучше

onon1 а *3 ещё лучше

onon1 Но с этим я пока точно не разобрался

Vort "<onon1> Можно и так, я тестировал на всех длинах туннелей" - какой был пинг между узлами?

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

onon Пишет лизсет не был подтверждён за 4000 мс, перепосылка. Так что искать в логе на этом самом "крайнем" узле?

onon Я там вижу только кучу ошибок Transports: Session to peer FKOqnTkRZk4D1BM~~XALlBQhaUTdxb-nYjoWD7ehI~s= has not been created in 15 seconds

Vort я почти не разбираюсь с публикацией

Vort это же на флудфил идёт публикация вроде как

onon1 Разный пинг был, от 200 до 1200 примерно

onon1 Ну да, получается мой узел не может достучатьс ни до одного флудфила

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

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

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

onon1 Этот баг уже 5 часо висит

onon1 Ну узел нагружен, да

Vort при чём тут узел? флудфил нагружен

onon1 Ну там же 7 фф выбираются

Vort или ты его забанил или твой узел забанил или он тупит

onon1 Или не так?

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

onon Routers: 17964 Floodfills: 758 LeaseSets: 525

Vort onon: ну с тем кодом, что ты скинул, скорость в 10 раз хуже. оценка RTT залипает на каких-то странных значениях - то 4000, то 200. при том, что это локалхост

Vort правда, я прошлый тест делал с кое каким хаком

Vort а сейчас его нету, так что результат не точный

Vort может, я где-то ошибся ещё в добавок

onon Попробуй на реальных туннелях

Vort да мне пока что локалхоста хватает

Vort один раз стрим вообще оборвался

Vort хаос какой-то

Vort скорость прыгает от теста к тесту

onon1 На локалхосте результат будет хуже

onon1 Из-за частых перепосылок

Vort он не должен быть хуже, чем был до изменений, вот в чём суть

Vort опять обрыв

Vort вот я вывел в логи изменения RTT:

Vort paste.i2pd.xyz/?d87444abad30930b#Ana8n3uttomiAFMJhzRhyMzTUDzxZQ4g7hUtqzxnKuU7

Vort это когда обрыв происходит

onon1 Хороший RTT

onon1 Обрыв в чём заключается?

Vort нет, вот хороший:

Vort paste.i2pd.xyz/?3b3aa116e070b7d9#CFrfkgHwW6Z83xhG5j7xwLxj5gidGVVPBohSGuXgP4z9

Vort (тот алгоритм, который сейчас в i2pd)

Vort "<onon1> Обрыв в чём заключается?" вот в чём: paste.i2pd.xyz/?48bf6c54ecb9632a#FJsvHpvFowPVq5YMCDqq5hmfGVbVTHUtw5LmAmVgV2D1

onon1 Ну ты ему, похоже буфер переполнил

Vort потому что ewma тупил с оценкой пинга? возможно

Vort но когда обрыва не было, была хреновая скорость, с тем самым RTT 200

onon1 Тот алгоритм, который сейчас считает RTT, действительно будет хорош на идеальной сети

Vort почему 200? у меня локалхост блин

Vort так нужен такой, который будет нормально работать при любых пингах, от 0 до 5000

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

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

onon1 Стандартно, у нас все узлы за 3мя хопами.

onon Routers: 19031 Floodfills: 754 LeaseSets: 542

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

Vort вот так обрывов нету: github.com/Vort/i2pd/commit/023323bd00c55ececfdde44f0479a23cc6195c41

Vort и скорость нормальная (как и до этого изменения)

Vort теперь попробую окно ещё поменять, с учётом особенностей округления

Vort onon: модифицированный алгоритм сбрасывания окна позволил поднять скорость с 5 мегабайт/сек до 14 мегабайт/сек

Vort github.com/Vort/i2pd/commit/f9ca82c1b3e79cfdfe2cedccf71640a854940673

Vort скорее всего, у меня скорость опять в CPU упёрлась

Vort ну да и пофиг - 14 мегабайт/сек "хватит всем"

Vort 14 мегабайт/сек были на NTCP2. на SSU2 поменьше - 9 мегабайт/сек

Vort и опять заметил проблему залипания на RTT 200, с соответствующим провалом скорости в 10 раз

Vort может проблема "RTT 200" была и раньше, не знаю

Vort сейчас график сделаю

orignal 1.0-0.5 это же 0.5

orignal Vort я думаю это дубликаты

orignal если с RTT починили давай PR

Vort orignal: проблема с тегами проявляется точно так же, как и раньше

Vort я вижу резкую очистку. её быть не должно

Vort с RTT там сложно

orignal ладно погляжу

orignal но ты же видишь сам счас

orignal да ты прав счас попавлю

Vort вот как выглядит залипание стрима на RTT 200: paste.i2pd.xyz/?9be2d97359274b4b#Daq9XHouvWcZzvaKDqA4Ymjqo9QX6LBYaBDWgoqBkyEh

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

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

orignal так что меняем RTT?

Vort orignal: без научного подхода? альфу брать наугад что ли?

Vort то же касается и процента сброса окна

orignal ну так если стало лучше

Vort то есть, в том варианте, что я тестирую, - альфа - 0.5, процент сброса 10%

Vort orignal: стало лушче при определённых сценариях, которые проще всего потестировать

Vort при этом ещё и проблема "RTT 200" наблюдается

Vort попробую сейчас чуть более плавный график сброса окна

orignal ну а в стандартных запрос страницы-ответ?

orignal и аудио или видео поток

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

Vort разве что делать виртуалки с netem или как там его

Vort ну я всё равно сейчас оформлю коммит - как минимум для тестов

orignal а разгрузить временно внешний канал ты не можешь?

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

Vort и там же будет стоять версия без патча

orignal давай я поставлю на 333.i2p

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

Vort (я пока что оформляю коммит)

Vort orignal: onon: вот, оформил: github.com/Vort/i2pd/commit/3ceb64db2e34c71358fec9601252f401dc71c88e

Vort скорость даже на SSU2 получается 12 мегабайт/сек

Vort однако держится не долго, сваливается в задницу секунд через 5-25 (как я это назвал - "эффект RTT 200")

orignal давай тогда PR

orignal хуэе думаю не будет

Vort но потестируешь хоть? :)

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

orignal за секунд 5-25 обычно страницу может прогрузиться

Vort github.com/PurpleI2P/i2pd/pull/2036

orignal мне не нравится в этом что сстарый RTT учитывается также как новый

orignal calculation а не estimation

orignal estmination это предварительный расчет

Vort не, не так же. там экспоненциальное затухание идёт

Vort мы не знаем и никогда не узнаем (не сможем вычислить) реальный RTT, можем только оценить (estimate)

orignal тогда нормаьно

Vort en.wikipedia.org/wiki/Estimation

Vort en.wikipedia.org/wiki/Exponential_smoothing

orignal ну я просто говорю как говорят на практике

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

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

Vort на основе данных можно делать модели, на основе моделей - корректировки кода, затем снова собирать новые данные

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

Vort проверю сейчас, идут ли провалы скорости по NTCP2

Vort через NTCP2 особых провалов не вижу - более-менее стабильно прёт 18 мегабайт/сек

Vort orignal: в SSU2 ведь тоже есть оценка/вычисление RTT. надо и туда будет когда-нибудь воткнуть EWMA

orignal да там все также

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

Vort ну вот если стримы сейчас не поломали - можно будет обновить

Vort но вначале тесты! )

orignal счас пересобираю 33

orignal 3

relaybot 13apophis: orignal, так была атака ?

orignal где и когда?

orignal ночью сирены выли в вашу сторону

orignal ты про это?

Vort из-за слоя багов сложно дать чёткий ответ. вроде же понятно

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

Vort и на чистом фоне уже будут видны аномалии юзерской/хакерской активности

relaybot 13apophis: > orignal: где и когда?

relaybot 13apophis: на и2п

relaybot 13apophis: > Vort: и на чистом фоне уже будут видны аномалии юзерской/хакерской активности

relaybot 13apophis: ясно.

relaybot 13apophis: я верно понимаю, что вы пришли к мнению, что то что происходило и воспринималось как атака, могло быть паттерны поведения сети плюс баги ?

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

relaybot 13apophis: осциляции при релаксации :)

Vort больше на лавину похоже

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

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

relaybot 13apophis: на лавину, такие процессы похожи, когда рассматривается какой то локальный регион, а не вся сеть целиком. По сети могут волны гулять .. с "интерференцией" даже :)

Vort моё мнение (основанное на интуиции) - что идут одновременно оба процесса - и сеть глючит от багов и кто-то перегрузками пускает волны (или атака или мозгов просто нету)

relaybot 13apophis: если кто то кромеш самой сети присутствует, то это явно усугубляет все сильно. Хрен поймешь, где натуральные моды колебаний сети, а где "атака"

Vort "когда рассматривается какой то локальный регион, а не вся сеть целиком" - локальным регионом могут быть слабые узлы (мало CPU, мало скорости)

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

Vort это не точное описание, конечно же )

relaybot 13apophis: это не только их побанила, а и перенесла нагрузку на другой регион

relaybot 13apophis: т.е. плотность потока ( абстрактно ), возросла в другом регионе

Vort так этот эффект снаружи не наблюдается

Vort если слабый узел с 50% нагрузки прыгнул на 150% - это заметно, он начинает тупить

Vort а если мощный узел с 10% до 30%, то это и не поймешь, не являясь оператором этого узла

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

relaybot 13apophis: ты смотрел, какие превалируют роутеры по всему и2п ? какой классификации : слабые, средние, сильные ?

Vort по количеству основная часть - слабые

Vort при атаке/перегрузке даже средние уже не выдерживают

relaybot 13apophis: и распределение "однородное" ?

Vort только сильные держатся

Vort про распределение вопрос плохо понял. но вот могу показать график, внизу: i2p-metrics.np-tokumei.net/router-types

Vort "Routers by shared bandwidth flag"

relaybot 13apophis: тогда, тот эффект "абсорбции" лишней нагрузки на сильных роутерах ... будет вылезать на роутерх слабых. остюда задержки и все такое.

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

relaybot 13apophis: и интуитивно, сеть будет таки колебаться ... из за слабых роутеров в большинстве

Vort ну вот недавно выяснили, что флудфилы посылали ответы через слабые узлы

Vort а от этих ответов работа всей сети зависит

relaybot 13apophis: ну это наверное баг или по спешке вот так написали

Vort да тут в логах чата есть описание

Vort уже нормально сделали

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

relaybot 13apophis: это да, согласен

relaybot 13apophis: Vort, а тестовые сети какого плана делали ? чтобы ислючить фактор "атаки" и работать только над багами и имплементацией ?

Vort apophis: weko на локалхосте с симуляцией задержек делал тестовую сеть

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

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

Vort поведение виртуальных юзеров в тестовой сети тоже сложно сделать реалистичным

relaybot 13apophis: да, про локалхост это я знаю. Я думал у вы сделали смесь и2пд/ява на другом нетИд

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

relaybot 13apophis: да

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

relaybot 13apophis: пока от багов не отделаешься, то сложно конечно

Vort apophis: последние баги, которые я ловил в i2pd, проявлялись вообще просто на нескольких локалхост узлах :)

relaybot 13apophis: :)

Vort так что даже без тестовых сетей можно много чего найти

orignal я тут с дедом разговариваю

Vort вот сегодня iperf3 через 3 узла на одном и том же компе прогнал - и, похоже, SSU2 от этого поплохело

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

Vort важно сколько хопов?

orignal пох

Vort может, ещё один пул сделать, попроще, помимо зондирующего?

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

Vort допустим, 1 хоп и скоростные узлы

orignal потому что получив нешивфрованный DeliveryStatus он сразу сделае выводы

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

Vort что он думает про новый ID сообщения теста?

orignal а я ему и не говорил

orignal это наше внутренней дело

Vort так если нешифрованное сообщение - то будет не только наше. или нет?

orignal так нешифровнное понятно что надо DeliveyStatus

Vort с потенциальными прыжками времени и пониженной точностью. а какие преимущества?

orignal сбить с толку

Vort сами себя разве что собьём, запутав код

orignal я тоже так думаю

orignal <orignal> wait. do you send tunnel tests now?

orignal <zzz> yes

orignal <zzz> disabled in 2011; re-enabled two years ago

orignal все чудесате и чудесатее

Vort значит, пустые туннели - таки пустые (в основном)?

Vort транзит имею в виду

Vort это не значит, что с ними надо что-то из-за этого делать, конечно :)

Vort важно просто для понимания ситуации

onon Я смотрю вы уже даже коммит выкатили, пока я спал.

Vort ага

onon Тестировали на реальной сети?

Vort я только на локалхосте

Vort onon: просадки скорости на SSU2 от "разогнанных" стримов замечал?

onon Конечно

Vort идёт секунд 10 нормально, потом секунд 10 с просаженной в несколько раз скоростью

onon На NTCP всегда стабильнее работало

Vort понятно. значит, это древний баг

onon На SSU пакеты терялись чаще намного

Vort это что-то иное. я не понял пока механизма

Vort почему-то оценка RTT зависает на 200мс

Vort сразу снижается нагрузка на CPU

Vort это не потери

Vort там что-то клинит

onon У меня может тоже было, просто я не обращал внимания, потому что графиков не строил.

Vort предполагаю, что надо и в сам SSU2 EWMA втыкать. там же тоже оценка RTT есть

Vort onon: а я просто запускаю iperf3.exe -c 127.0.0.2 -t 20 -i 0.25

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

onon Ну я так круто как ты не умею, я просто поток качал.

Vort 0.25 - это вывод скорости 4 раза в секунду

Vort а это и есть скачка (точнее, отгрузка) потока

Vort -R скачка

Vort полезная програмка

Vort 18 мегабайт/сек с ней получил скорость сегодня :)

onon Я смотрю, инкремент решили не трогать?

onon Мне кажется это важно, сильно влияет на юзер эксприенс.

onon Я пока пробую разные варианты.

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

Vort может и SSU2 лучше до релиза не трогать

onon И насчет альфы, будем потом подкручивать, пока на среднем значении работает и норм.

orignal onon 333.i2p и wlm.i2p на новом

onon Скорость мерил?

orignal нет

orignal но открывается быстро

orignal учитывая что wlm.i2p там много контента

onon Так сгенери в корне файл из рандома и скачай

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

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

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

Vort потестирую скоро последний коммит тут в IRC. и проверю, не будет ли сюрпризов с тегами :/

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

Vort пока что всё нормально

Vort onon: просто на всякий случай говорю: некоторые стримы шлют данные всего лишь несколько раз в _минуту_. расчёты RTT и окон должны это учитывать

weko <Vort> всё равно 0 хопов - это больше тестовый инструмент

weko нет, когда у тебя есть анонимный сервер, туда можно спокойно ставить 0 хопов

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

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

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

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

Vort заметил кучку сообщений с похожими значениями: "NTCP2: RouterInfo is too old in SessionConfirmed for 30885 seconds"

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

Vort проблема с временем уже после релиза была починена?

weko <onon1> Следующий момент, это инкремент размера окна. По умолчанию делает просто m_WindowSize++. Я предлагаю как минимум += 2, а лучше + 1% за раз.

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

orignal_laptop пробую с винды с последним измнением

weko <orignal> так что меняем RTT?

weko есть же RFC стандарт, почему бы не реализовать оттуда? более того, есть quic, можно его использовать.

weko <Vort> apophis: что-то запускает волну перегрузки сети. то ли накапливается критическая масса эффектов от багов, то ли кто-то перегружает сеть намеренно

weko кто-то иницирует волну, но она увеличивается значительно из-за лимитов роутеров

orignal не знаю

weko <orignal> короче прищли к выводу что на публикацию лисета надо отвечать через тоннели

weko почему

weko <orignal> важно чтобы IBGW не получал напрямую с флудфила

weko почему??

orignal потому что иначе вход тоннеля сразу просечет что это ответ на публикацию и узнает с какого флудфила

weko <orignal> потому что получив нешивфрованный DeliveryStatus он сразу сделае выводы

weko какие выводы? b32 не секрет

orignal секрет

orignal если ты вход тоннеля ты не знаешь чей ты тоннель

weko <Vort> 18 мегабайт/сек с ней получил скорость сегодня :)

weko я примерно такое же получал. там уже был упор в одно ядро процессора

weko <orignal> потому что иначе вход тоннеля сразу просечет что это ответ на публикацию и узнает с какого флудфила

weko и что? ему ничего это не даст

weko <orignal> секрет

weko <orignal> если ты вход тоннеля ты не знаешь чей ты тоннель

weko так легко узнать. просто шлёш туда пинг и узнаешь b32

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

weko и что это ему даст?

orignal это как?

orignal чтобы послать пинг ты должен знать лизсет

weko а стоп да, конец не должен знать b32

orignal в котором сидит ключ s

weko ну так флудфил должен шифрованный ответ слать

orignal не зная его s ты сможешь зашифровать пинг правильно

orignal так и я то том же

orignal но это ж дед

orignal что да надо но это "не в этом релизе"

weko ну мы то шифрованные шлём?

orignal нет

orignal там в сообщении нет такого

weko хорошая безопасность ...

weko но есть другой вопрос - что конец может понять, кто является флудфилом. правда пока не ясно, что это ему даёт, если это не его флудфил

weko если у него есть какая то база b32, он может вычислить какие b32 на этом флудфиле сейчас

weko можно слать мусорный трафик, чтобы концы ничего не разобрали.

weko на концы же ещё приходит ответ от строительства исходящих туннелей

weko потому точно понять, какие флудфилы, сложно

orignal узнав кто флудфил он может понять диапазон

weko да, но на входные без трафика не только ответы флудфилов приходят

weko а ещё и ответы от исходящих

orignal нешифрованный DeliveryStatus?

weko но кроме этого там есть создание входящих туннелей, что тоже усложнаяет задачу

orignal а с ними то что?

weko <orignal> а с ними то что?

weko ну там тоже видно же

weko куда шлём

orignal там приходит запрос на постороение

orignal от конца исходяшего тоннеля

onon Лось, у нас большие проблемы с SSU. Сообщения вида SSU2: Unexpected message type 90 from 94.76.140.83:28210 of 71 bytes плодим мы сами. Инфа сотка.

onon Я пока не разобрался с механизмом, но это точно мы.

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

onon Когда уже будет так, вот сказал Лосю, у тебя вот это не работает, а он такой - и правда, сейчас починю, и починил....

orignal ну вот смотри Vort говорит что проблема там то и там то

orignal и я чиню

Vort onon: может хочешь погонять проблему с проседанием скорости SSU2 ("RTT 200") ?

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

weko <orignal> там приходит запрос на постороение

weko <orignal> от конца исходяшего тоннеля

weko ну а на входящие приходят ответы от строительства исходящих

orignal они шифрованные

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

Vort вот провал и вот отвал: paste.i2pd.xyz/?32f9b7918242ede2#E9fFPWqGs9yzNbDTnYEUro743W7YGKg7LTDpobMprDzU

Vort с NTCP2 подобного не замечал

Vort на стороне сервера команда простая: iperf3 -s 127.0.0.1

onon Как минимум один случай когда мы получаем Unexpected message type, это когда мы превысили очередь для какого-то узла. SSU2: Outgoing messages queue size to xxxxx= exceeds 500.

onon После этого на том узле получаются нераспознаваемые сообщения.

Vort отвал - это ппц конечно. лаг 8 секунд был! чем i2pd занимался всё это время?

Vort onon: интересная находка

Vort может это и есть "мой" "отвал" ?

Vort 8 сек - пока транспортная сессия пересоздастся

orignal onon так а может наоброт?

orignal превышение лимита потому что там нераспознанеые сообщения

onon Я точной логики не знаю, может и наоборот

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

Vort вполне такой эффект может давать

onon По коду, рвет сессию, да.

Vort ну вот и получаются пакеты в полёте без сессии

Vort "неожиданные"

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

Vort окно то ведь максимум 128

Vort откуда 500 ?

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

onon Я не успеваю их отправлять на медленный и захлёбываюсь

Vort похоже на ту проблему, "которую непонятно как решать"

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

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

Vort значит где-то может сидеть баг

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

Vort onon: да о смене протокола можно особо не думать

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

Vort это годы на обсуждения нужны

onon Ну так тут, вроде не особо протокол менять.

Vort протокол то общий с java

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

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

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

Vort то есть, окно 128 - это на всю цепочку

onon Ну да

Vort ну вот, больше 128 ни на одном из узлов быть не может

onon Он переотправляет

onon Дополнительные пакеты

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

onon По таймауту

onon Похоже, что нет.

Vort ну там же есть какие-то retry attempts

Vort или это не то?

Vort допустим, 5 максимум попыток: 128*5=640

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

Vort немного наугад пишу правда

Vort надо разбираться

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

Vort опять же немного наугад мысли

onon А получатель их потом перезапросит, вроде звучит логично.

onon Только поток на принимающей стороне станет "рваный"

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

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

onon Если у нас окно будет маленькое, будет маленькая и скорость

onon Потому что задержки большие

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

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

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

weko <orignal> они шифрованные

weko <orignal> там чеснок приходит

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

weko ну и вопрос являтся ли проблемой эта ситация вовсе

Vort скорость, пинг и размер буфера (окно) вообще, вроде, по формуле связаны

onon Мне пока представляется только механизм "согласования скоростей" между участниками туннеля, но насколько это секьюрно, нужно думать...

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

orignal weko на самом деле цель чтобы через концы тоннелей всегда ходили чесноки

orignal что почти так и есть

orignal но в этот сообщении шифрованный ответ не предусмотрен

weko ну вопрос с определением флудфила то остаётся

weko хоть и под вопросом

weko <orignal> но в этот сообщении шифрованный ответ не предусмотрен

weko а надо чтобы был

orignal Vort так очередь потому и превышается потому что сообщения туда не доходят

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

orignal а почему вот x3

orignal weko так дед с этим согласен

orignal просто говорит что маньяна

onon Не совсем, иногда не приходят подтверждения...

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

Vort orignal: думаешь, что стрим сам по себе при нормально работающей сети не должен переполнить очередь? даже с учётом переотправок?

orignal я про SSU2

Vort ну так его же стрим переполняет

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

Vort или что?

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

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

Vort не приходят подтверждения - стрим должен встать. нет?

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

orignal а если у тебя сотня стримов на этом маршруте?

orignal если ты грузишь с килсицы страницу с сиськами

Vort orignal: а вот и давайте разбираться, какой был сценарий перегруза

orignal вот пусть onon расскажет

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

Vort примерно, конечно

onon Ну вообще один, но с увеличенной очередью

Vort окном?

onon И окном и очередью

Vort ну про нестандартные сценарии мне сложно что-то сказать

Vort для начала надо чтобы обычный режим работы к глюкам не приводил

Vort orignal: уже по другому вопросу: на последнем коммите (2.50.2-144-gce97ec15) всё же сыпет "Garlic: Can't handle ECIES-X25519-AEAD-Ratchet message"

Vort конкретно почему и насколько это мешает (строить туннели к примеру) - не знаю

orignal возможно это уже дубликаты

Vort возможно

Vort я больше резкой очистки не видел

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

Vort там же +300 штук тегов набивается, когда такое случается. может они потом мешают как-то?

orignal нет они быстро вычищаются

orignal там же просто хэш

orignal его размер не имеет значения

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

Vort вот около этих 300

Vort но плохо помню

Vort надо будет проверять

orignal главное чтобы нащи запросы не терялись

orignal типа тестов и построение тоннеей

orignal вопрос такой

orignal случается ли это на пустых дестинейшинах?

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

orignal Vort я тут осознал какую хуйню сделали когда дубликаты пропускали

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

orignal ну ладно в стримах еще выловит а вот в датакграммах