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

orignal багу нашел

orignal верификация шифровонного лизсета фейлится

onon Пытаюсь я гонять тесты на стримах, но они постоянно зависают. Вроде всё шло хорошо, потом он мне написал Streaming: Another lease has been selected

onon Потом: Streaming: Another outbound tunnel has been selected, а потом насыпал кучу ошибок Garlic

orignal значит ответы не приходят

onon А вот эти гарлики это про что?

onon Garlic: Flags/static section AEAD verification failed

onon Garlic: Can't handle ECIES-X25519-AEAD-Ratchet message

onon Тысячи их

orignal дубликаты скорее всего

onon А стримы так и висят на клиенте, а в логе жалуется что лизсет не подтверждён за 4000 мс и что подтверждение публикации не получено за 5 сек или фейл

onon И так бесконечно

orignal нупроблема где то

orignal с тагами

onon Рядом с этими сообщениями он ещё пишет Streaming: Неизвестный стрим сСИД=123456789

orignal это скорее всего прилетает на уже закрытый стрим

orignal ну вот еще одной багой меньше

onon Похоже, проблема воспроизводится если сфейлились все пары туннелей одновременно, если какой-то из стримов выживает, остальные потом оживают через некоторое время.

orignal ну это понятно

onon С этим нужно что-то делать

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

orignal тогда RTT будет все время скакать

onon Это можно как-то включить, попробовать?

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

onon Это сильно сложно?

orignal да дохуя

onon Значит после релиза, попробую тебя достать.

Vort "<~orignal> случается ли это на пустых дестинейшинах?" - думаю, что да

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

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

Vort а, понятно, сообщение "Garlic: Can't handle ECIES-X25519-AEAD-Ratchet message" может из двух мест выводиться

Vort подтверждаю, что глюк вылазит на пустых дестинейшенах

Vort неиспользуемый прокси, к примеру

Vort orignal: с тегами всё просто. ReceiveRatchetTagSet::IsSessionTerminated возвращает !m_Session || m_Session->IsTerminated ()

Vort то есть, этот коммит не делает ровно ничего: github.com/PurpleI2P/i2pd/commit/bb702700f7ba3069340eacb03b22344adabd414b

Vort "<onon> ... Вроде всё шло хорошо, потом он мне написал Streaming: Another lease has been selected" я тоже в эту хрень упёрся, гоняя локалхостовую проблему с SSU2

Vort кажется, понятно, откуда 8 секунд затупления берутся: m_RTO = INITIAL_RTO; // drop RTO to initial upon tunnels pair change first time

Vort неясно только что там можно менять, если у меня всего одна пара туннелей с одним узлом (через explicitPeers)

Vort похоже, "Streaming: Another remote lease has been selected for stream" может иметь последствия в виде "Streaming: Can't send packets, missing remote LeaseSet"

Vort у меня подозрение, что либо стримы, либо SSU2 неадекватно реагируют на 100% загрузку CPU, а это естественное явление при тестировании на локалхосте

Vort сделал самый локальный тест стримов который только можно. и вот такое увидел: 949461501:me ⇒ ( 1ms ) established, 17179869182.14 GiB

Vort стрим через 0 хопов на том же самом узле выдаёт 33 мегабайта/сек и если глючит, то слабо

Vort стрим через 0 хопов на двух узлах - сыпет сообщениями "Another remote lease has been selected", но не зависает при этом

Vort скорость - 11 мегабайт/сек при таких ошибках

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

Vort через три узла с отключенными кейсами 2..4 - стрим заглючивает реже

orignal Vort там у SymmetricTagset он переопределяется

Vort сейчас буду проверять

orignal для этого и сдлано

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

orignal я тут пытался публикацию шифроанного лизсета чинить

orignal похоже он протухает быстро

onon Я что-то не могу найти как часто мы отправляем ACK или NACK на полученные сообщения в стриме, не подскажете?

orignal от RTO зависит

onon Это плохо.

onon На принимающей стороне RTT почему-то считается криво

onon Видимо в сообщениях нет тайстемпов

onon Но я точно не знаю

Vort orignal: я заметил один дубль тега

Vort но пока что не на прокси

orignal понял

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

Vort секунды 23, 24, 25

orignal нашел багу с шифрованными лизсетами очередную

Vort ну я с ними не разбирался ещё

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

Vort может, стоит проверку добавить?

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

orignal стоит

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

tetrimer Подскажите пожалуйста, если мы имеем Router Caps: PfRE - то это значит, что и локальные ресурсы этого роутера будут недоступны пока E висит?

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

Vort хотя даже не совсем так

tetrimer По факту, пока не перезапустился - ничего не коннектилось: т.е. пакеты в стрим уходят, а оттуда - по нулям.

Vort E ставится при 90% перегрузке, а пропускаться не будут когда перегрузка достигнет 100%

Vort tetrimer: скорее всего это отдельная проблема

Vort orignal: словил дубль тега при построении туннеля (Tunnel::Build), на клиентском туннеле ко второму локалхост узлу

tetrimer Отдельная от чего? Или, не связанная с флажком E?

Vort не связанная с E

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

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

Vort orignal: при этом, дубль сразу же после потребления тега пришёл

Vort в ту же секунду это точно

orignal ну не удивительно

orignal вопрос где мы их не фильтруем

Vort это получается двойной ответ на построение туннеля пришёл?

orignal получается что так

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

orignal отправилось один раз

orignal где то была переосылка

orignal ловить надо в TunnelEndpoint.cpp я думаю

orignal ты msgid у чеснока печатаешь?

Vort нет. могу сделать

orignal это более интересно

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

Vort orignal: разные msg id. отличаются, правда, не сильно: 452512175 и 452455104

Vort [15:30:48] <Vort> orignal: разные msg id. отличаются, правда, не сильно: 452512175 и 452455104

Vort orignal: а вот теперь тест туннеля задвоился. и тут уже msg id совпадают: 3561224424

Vort и второй ответ теста пришёл через 2 секунды после первого

Vort опять тест задвоился. и опять совпали id

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

orignal то есть это не повторно тест посылается

orignal а где то перепосылка

Vort ну для тестов - да

Vort с SessionNextTag тоже похожее происходит

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

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

Vort наверно проще всего будет

orignal оба на

orignal SessionNextTag это надо отследить

orignal тесты тоннелей надо понять где дубли

Vort да это похоже на общий источник проблемы

Vort дублируется всё, что можно )

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

Vort то есть, сами по себе дубли - это нормально? только фильтровать надо?

orignal да

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

orignal возмождно это признак еще одного бага

Vort тогда не до конца понимаю

Vort должны дубли быть или нет при нормальной работе сети (без хакеров)?

Vort ну при условии потерь пакетов, лагов и т.д.

orignal по уму нет

Vort понятно. значит надо баг ловить

Vort я почти уверен, что это не атака

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

orignal конечно не атака

orignal допустим мы отсылаем сообщение по SSU2

orignal и не получаем акк

orignal через некототорое время мы снова его пытаемся послать

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

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

orignal просто акк не дошел

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

Vort получается, при условии потерь пакетов (в реальной сети) этого эффекта не избежать

orignal или например было пересоединение

orignal скорее всего

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

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

Vort SSU2 глючит больше положенного? :)

orignal может это и не там

Vort ну вообще состояние i2p сейчас не супер

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

orignal раньше все было еще хуже

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

orignal теряются как раз понятно

orignal просто дропы

Vort не факт. это могут быть огромные лаги, по 5-10 секунд

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

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

onon Простые выловлены, остались сложные...

orignal не сказал бы

orignal я счас выловил баг с шифрованными лизсетами

orignal простой

onon У меня наконец-то получилось прокачать через сеть 1ГБ без обрыва стрима....

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

orignal коммит

orignal мега бага была )

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

Vort иначе "блуждать" можно долго

Vort "<~orignal> мега бага была )" много ли юзеров знают вообще про эту фичу? баг то может и мега, а влияние на сеть?

Vort любые баги, конечно чинить надо, это понятно

onon Он похоже про очистку excluded флудфилов

onon Вот это да, бага, так бага

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

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

Vort понятно

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

orignal и вчера нашел что публиковал их не туда

orignal вообще не туда

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

Vort как же тогда юзеры этой фичей пользовались?

orignal ну флуфдилы пересылали сами куда надо

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

orignal то есть работало но хуево

orignal это я починил еще вчера

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

orignal проверил. теперь все там работает идеально

orignal все уехал до вечера

onon Vort, ты там пока с дубликатами и тагами разбираешься?

Vort onon: я пока ни с чем не разбираюсь

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

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

Vort ситуации, похожие на те, о которых tetrimer пишет

onon Я уже протестировал, работает хорошо

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

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

onon Я через 4+4 хоп гоняю и норм...

onon Странно

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

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

onon Там, кстати, дед сказал, что альфу нужно брать 0,125

onon Но я пока не уверен, нужно потестировать

Vort а не 0.875 ? :)

onon zzz: orignal, please pass along to Vort: EWMA ALPHA should be about 0.125; see RFC 6298 for guidance

onon Просто у нас RTT может _очень_ быстро скакать, не уверен, что 0,125 будет хорошо

Vort а тьфу, я там RTT и m_RTT местами попутал. для 0.5 пофигу

Vort но вообще надо поменять местами

onon Да нет, вроде все так.

onon RTT = (α · Old_RTT) + ((1 − α) · New_Round_Trip_Sample)

Vort откуда формула?

Vort я наоборот вижу

Vort даже в том RFC наоборот

Vort SRTT <- (1 - alpha) * SRTT + alpha * R'

Vort SRTT - сглаженное значение

Vort и оно на 1 - α множится

Vort ещё в стандарте RTTVAR считается

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

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

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

Vort но не уверен и не знаю точно, как

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

onon Если что-то будет работать лучше, обязательно поменяем

Vort я сейчас попробую закодить просто по RFC

onon Ты только учитывай, что у нас тут связь не напрямую, как у них.

Vort мне кажется, что VAR считать логично в любом случае

Vort да я это просто эксперимент

Vort и это*

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

onon1 Локально?

Vort да

Vort это тест на 3х узлах

Vort локалхостовых

Vort только пинги начинает колбасить - подскакивает VAR и подбивает RTO

Vort сейчас попробую графики нарисовать. и свой комп не завесить :D

Vort нарисовал графики и увидел, что с такой альфой сильно гадит округление. надо на double переводить

onon Сильно гадит то, что получатель шлёт ACKи лишь бы как, потому что не знает актуального RTT.

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

Vort github.com/Vort/i2pd/commit/a36bca9ee4a634612893cd765ecc2eb86d4a1dd6

Vort я, правда, не полностью всё по RFC сделал

Vort к примеру, вычитал вот такую фразу там: "Whenever RTO is computed, if it is less than 1 second, then the RTO SHOULD be rounded up to 1 second."

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

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

onon А на реальной сети не гонял?

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

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

Vort но в таком случае и тестировать нечего - просто m_RTO = 1000; написать и всё

Vort или я что-то не понимаю (вполне вероятно)

onon RTO это время, по истечении которого если не получен ACK, требуется перепосылка, если я правильно понял, так что установка в 1 сек вполне оправдана.

onon1 В реальной сети RTO у меня обычно около 2-4 сек

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

Vort (typically, once per RTT)

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

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

onon Все аски одним сообщением шлются

onon до 255 штук вроде

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

onon Это да

Vort соответственно, при разных скоростях нужно разное усреднение. а это хрень

onon Ты лучше придумай как клиенту правильно ртт считать, если он только качает. и асков не получает

onon Слать аски на аски?

Vort я не разбирался ещё с этим. но самый первый вопрос - а зачем ему знать RTT ?

onon Он сообщение с асками шлёт по ртт

Vort теперь по расчёту SRTT и RTO: алгоритм должен нормально работать при разных: скоростях, RTT, jitter/variance, потерях. вручную, без создания модели, это тестировать задолбаешься

Vort если не сломали алгоритм добавлением EWMA и уменьшением сбрасывания окна - и хорошо

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

onon Ещё обязательно нужно увеличить скорость роста окна

onon мастхэв

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

onon Пользователь открывает страничку с картинками - вот тебе модель.

Vort слишком много переменных

onon Из-за больших задержек у нас окно растёт очень медленно

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

onon У нас ситуация немного иная.

onon Мы не используем весь потенциал сети. И пользователи бесполезно ждут загрузки картинокю

onon Хотя мы можем их отправить быстрее

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

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

relaybot 13apophis: предлагали построить подобное, около года назад, если я не ошибаюсь ( ориж слыхал наверное ). Именно общую модель, без шифрования ( параметер нагрузки на ЦП <clipped message>

relaybot 13apophis: У ) и без цетевого стака ( параметры задержек, нагрузки, и все такое конечно присутствуют.

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

relaybot 13apophis: Ворт верно рассуждает по модели.

relaybot 13mittwerkz: а что это вообще такое DNS.CHUDO.I2P

orignal так надо менять или нет?