~AreEnn
~R4SAS
~orignal
~villain
&N00B
+Xeha
+relaybot
DUHOVKIN
Guest18377
HackerMan
KabaOS
Most2
Nausicaa
Ruskoye_911
Trusishka
Vort
`
acetone_
anon3
b3t4f4c3
mittwerk
nemiga
not_bob_afk
plap
poriori_
profetikla
segfault
soos
teeth
tensor
un
weko_
whothefuckami
weko
Кто может кратко рассказать, что успели сделать, пока меня не было?
orignal
стримы переделалали
orignal
баги в SSU2 починили
onon
Лось, давай подсказывай. Я пока уперся в эту проблему. Она не дает мне нормально стримы разогнать.
orignal
через неделю
onon
Через неделю я уже всё забуду.
weko
orignal: а что именно?
weko
Или вообще полностью?
onon
weko, может ты им объясни, что большие буфера - это не всегда хорошо.
weko
Да ясно что не всегда
weko
Но про что речь ?
weko
Точнее про какой буфнр
onon
Сам посмотри, у нас нынешний Congestion control не совместим с буфером на транспорте.
weko
Вполне вероятно
onon
Он работает на переполнение, а они сделали буфер бесконечным.
weko
Бесконечный???
onon
Будут задержки по 12 и более сеунд
weko
Да ещё больше
weko
Это плохая идея
weko
Вот зачем ломать то всё..
onon
Я предложил сделать обычный RED. Но ворт меня отшил
weko
Что за RED
onon
Random Early Detection
orignal
а куда пропадал?
weko
orignal: если бы я сам понимал. Менталка, больше не буду говорить
Vort
weko: лучше сам посмотри код. буфер транспорта не бесконечный, а ограничен временем (2 сек лага). таким образом, и защита от атаки на переполнение получается и быстрые узлы не упираются в искусственный лимит 500 сообщений
weko
Vort: ну так всё равно задержка конкретных данных может вырастать не оправданно
weko
А какая атака на переполнения может быть?
weko
Это любая атака спама трафиком как бы
weko
Что не решается на уровне буферов точно
Vort
сейчас поясню
Vort
допустим, у нас 1000 медленных транспортов и у каждого буфер на 500 сообщений (~500 кб)
Vort
если атакующий в состоянии наливать данные быстрее, чем справляются медленные транспорты, то он может занять 500*1000 = 500 мегов RAM
Vort
с моим ограничением - не сможет
weko
Так порт не выдержит в первую очередь
weko
[06:43:24] <weko> Это любая атака спама трафиком как бы
weko
[06:43:43] <weko> Что не решается на уровне буферов точно
Vort
поэтому я говорю про медленные транспорты - которые еле-еле шевелятся
weko
Это решается на уровне профилирования
Vort
медленным транспортам много трафика чтобы переполнить буфер не надо
weko
Ну понизить можно буфер, до 25 например
weko
Но починив стримы, естесна
Vort
"<weko> Это любая атака спама трафиком как бы" - при 100 мегабитном порте при ограничении буфера по времени в 2 секунды макс количество сожранной RAM будет всего около 22 мегабайт
weko
Да и сделаем искусственный лаг для всех коннектов
weko
Заебись решение
Vort
"<weko> Ну понизить можно буфер, до 25 например" - быстрым, но далёким (высокий пинг) узлам для нормальной скорости нужно иметь много пакетов "в полёте". это нормальный режим их работы
weko
Для этого окно имеется
Vort
"<weko> Да и сделаем искусственный лаг для всех коннектов" лаг во время атаки? это смотря как атака будет устроена. да и вообще не факт
weko
Vort: лаг когда мы упираемся в скорость транспорта
Vort
любой вариант будет лучше креша от переполнения памяти
weko
И узнаём через кучу времени об этом
weko
Vort: у многих 500 мегов найдётся. А вот терпение на такие стримы - не особо
Vort
почему через кучу времени? пинг сразу вверх пойдёт
Vort
и, как я понимаю, нормальный congestion control это и должен ловить
Vort
попёр пинг вверх - снижаем скорость
Vort
кстати, для медленных узлов при переполнении фиксированного буфера там лаг будет не 2 секунды, а намного больше
weko
Так уже снижаем
weko
Окно тр уменьшается
Vort
ну вот - и уменьшается нагрузка на транспорт
weko
Ну только может у меня UDP
weko
Где пофиг на потери, но не пофиг на задержку
Vort
в случае UDP задача congestion control ложится на юзерскую программу
weko
Ну да. Но может у меня UDP именно чтобы задержка минимальная былп
weko
И срать на потери
weko
А i2p будет при перегрузке делать сначала без потерь но с задержкой, а потом будет и задержка, и потери
Vort
особенность в том, что сейчас в i2p заметный уклон в сторону надёжности. к примеру, перепосылки пакетов в SSU2 по 5 раз
Vort
ну и TCP сам по себе в NTCP2 даёт надёжность
Vort
получается некоторый конфликт
weko
Но датаграммы то на уровне туннелей идут
Vort
надёжность и дропы - это противоположные требования
weko
А там перепосылки это куда более дорогое дело
weko
Vort: ну транспорты да. Но перепосылка в них не такая, дорогая, как лаг 2 секунды на уровне туннелей
weko
Почему бы просто не убрать этот буфер?
weko
Он же не нужен
weko
Точнее. Приведите аргументы, почему он нужен
weko
Кроме как кривая реализация стримов
weko
Которую можно исправить
Vort
так это мы про одну и ту же систему говорим - сообщения ждут в очереди, возможно дропаются как-то, но только их SSU2 "принял", он будет как дятел долбить по 5 раз эти пакеты
Vort
я тоже не знаю, зачем. может, если починить баги, то и убрать можно будет
Vort
у меня подозрение, что накопление пакетов в этой очереди - это признак каких-то багов. но я пока не полностью уверен
weko
Тут надо подумать
Vort
если вот посмотреть на вкладку транспорты, то очередей нету почти никогда
Vort
2-3 штуки на 2000-3000 транспортов
weko
Ну дак где трафик идёт, и другой узел - упор туннеля
Vort
это, кстати, ещё одна из причин, по которой я не сильно беспокоюсь за решение про буфер на 2 сек
Vort
"<weko> Кроме как кривая реализация стримов" - я же чуть покопался в них, чуть починил - они лага, по крайней мере, резкого вообще не терпят
weko
Так понятно что всплывает редко. Потому что большинство туннелей - а значит и транспортов пустые стоят
weko
Vort: они - лажа :)
Vort
мне кажется, что если транспорт залагает, то стрим просто прыгнет на другие туннели и всё
weko
Это если полностью залагает
weko
А так у него скорость может низкая
Vort
насчёт пустых туннелей/транспортов - не факт, есть же ещё пакеты в полёте. если их не много, то очереди не будет вообще
weko
Может очередей нету из-за кривых стримов
weko
Тоже вариант
weko
Vort: ну а их не много
weko
На большинстве транспортов
Vort
может, SSU2 просто не умеет нормально окно считать и пакеты выдавливает в очередь под нагрузкой, хотя они должны в полёт отправиться по хорошему?
weko
Ну может
Vort
кстати, проблема с переполнением очереди была в основном для SSU2. NTCP2 переполнял очередь намного реже
weko
В идеальном случае, я думаю, этот буфер не нужен. Сейчас я думаю, проводя аналогию с, например, реальной сетевой картой
Vort
и ещё надо учесть, что часть переполнений - это просто "вырубили электричество"
weko
Vort: это скорее исключительный случай
Vort
вот я и думаю, что переполнение очереди это 1. исключительные случаи + 2. баги
Vort
туда не RED пихать надо, а разбираться с проблемами
weko
До 500 не успевает просто потому что пинг вырастает сильно, и видимо стримы меняют туннель
weko
Короче я сейчас подумаю как в идеальном случае должно быть
Vort
ну вообще очередей мало. а когда есть, там не 500 и не 100 сообщений, а 5-10
Vort
надо бы в консоль ещё количество пакетов в полёте выводить )
Vort
да много что ещё туда надо. хотя бы пинг/RTT
weko
Vort: окно и текущий размер буфера окна?
Vort
ну да
Vort
кстати, вот сейчас на своём узле открыл вкладку транспортов - очередь всего одна на ~6 тыщ транспортов: [queue:8]
Vort
и то, на NTCP2
weko
На реальном интерфейсе есть всегда заданный лимит скорости - например, если на порту 100 Mbit/s, то всё, что превышает - дропается, верно?
Vort
буферы ещё есть
Vort
сколько - зависит от произодителя железки
Vort
ну и от ОС
Vort
но, если я правильно понял, буфер в железке общий на все пакеты
weko
Ну я делаю аналогию, что транспорт i2p = провод между железками
Vort
ну и у железки есть свои железячные причины, по которой она не может быть сильно умной
weko
Только у транспорта динамическая скорость, её можно посчитать в любой момент
Vort
ну вот в i2pd буферы на "проводах", а в реальных железках - на самой железке
weko
Ну провод в данном случае абстрагирован
Vort
и я думаю, что вариант i2pd лучше - более индивидуальный подход. жеоезка себе такое позволить, скорее всего, просто не может
weko
У железки CPU и память - она может всё позволить
weko
Но у неё есть плюс - скорость постоянная
weko
Всегда 10 Mbit/s, 100 Mbit/s и так далее
Vort
ну хз, я не видел информации об отдельных буферах для разных направлений в железках, а это важное отличие
Vort
железка выделила мегабайт и всё - переполняй, не переполняй - ей пофигу
weko
Есть важное отличие
weko
У железки нет окна
weko
У нас то есть и там, и там
Vort
и это, да
Vort
железка она более тупое устройство, по разным причинам
weko
Это важно
weko
Vort: просто что аналогия неверная
weko
У нас у транспортов уже есть congestion control
weko
Уже
Vort
этот вопрос я кстати задавал недавно - зачем в SSU2 перепосылки пакетов? :))
weko
Единственное что должно выправляться на уровне туннелей - упор в скорость на каком то транспорте
weko
Буфера при этом задача лишь усложняют
weko
Задачу.
Vort
а перепосылки не усложняют?
weko
Vort: ну в i2p в основном стримы, видимо потому так сделали
weko
Vort: для UDP да
Vort
я не предлагаю их убирать, просто странная система какая-то
weko
Для TCP они наоборот хорошо
Vort
я имею в виду в SSU2
Vort
"<weko> Vort: ну в i2p в основном стримы," - которые неадекватно реагируют на потери пакетов?
weko
При чём для некоторого UDP хорошо, а для некоторого плохо
weko
Вот например QUIC
weko
Там перепосылки на SSU2 - это хорошо
weko
Vort: это уже другой вопрос
weko
Что забагано всё
weko
Хорошо в том смысле, что задержка меньше
weko
При потери на сетевом уровне
Vort
это я просто уточнил логическую связь - перепосылки, чтобы стримы не глючило, потому что они кривые?
weko
Vort: чтобы меньше задержка была
weko
Чтобы не было пиков, когда реальная сетевая потеря
Vort
а, я понял - чтобы через всю цепочку информацию о потере не тащить
Vort
быстрее решить проблему "локально" на транспорте
weko
Да
Vort
значит, надёжность SSU2 - это хорошо, получается?
weko
Потому для TCP и условном QUIC ( который по UDP ) переотправка - хорошо
weko
Vort: не всегда
Vort
ну а в i2p вроде нету отметки "этот пакет не важный, можете выкидывать"
Vort
иначе можно было бы по разному потоки и датаграммы передавать
weko
Для игр, где игра сама решает приемлемый уровень потерь в угоду скорости, переотправки наоборот, вредят
weko
Vort: нету, и если сделать всплывёт вопрос анонимности
Vort
будет видно, кто в игру играет, а кто файл браузером качает, грубо говоря
Vort
вот поэтому вопрос "дропать или перепосылать" - не такой простой
weko
Vort: ну да, и при большом перевесе в как то сторону, будет для тех, кого меньше, сильный деанон
weko
Vort: но это уже не вопрос очереди
Vort
дропаем - гадим стримам, не дропаем - гадим датаграммам
weko
А вопрос реализации SSU2/I2NP (флаг "важный пакет" и флаг какой транспорт нужен)
weko
Vort: не обязательно гадим датаграммам
weko
Как я уже упомянул есть QUIC, которому как раз хорошо перепосылки
weko
Но он по UDP
Vort
"<weko> Vort: но это уже не вопрос очереди" - так сейчас мы не знаем, стоит в очереди важный пакет или не важный
Vort
и "в полёте" важный или не важный не знаем
weko
Очередь не нужна в обоих случаях
weko
А хотя
Vort
я считаю, что надо разбираться, в каких случаях она образуется и дальше уже решать исходя из полученных знаний
weko
Не знаю, может в ssu2 без переотправок и нужна
weko
Как в железке
weko
Потому что там буфера окна не будет
Vort
мне кажется, что i2p просто больше заточен под TCP-like трафик, поэтому и уклон в сторону надёжности
weko
Vort: ну это понятно
weko
Ещё важно где вреда больше
weko
Всё таки вреда от переотправки в UDP меньше чем от её отсутствия в TCP/QUIC
weko
Как мне кажется
Vort
похоже на то
weko
Ну потому что в первом случае добавился задержки только от одного транспорта. А во втором - от всех сразу
weko
При плохом варианте для случаен
weko
Случаев
Vort
tetrimer_: какой-то странный всплеск на графиках 666 около 3 часов ночи. транспортов и роутеров стало раза в 2 больше. есть идеи, что могло быть причиной?
Vort
похоже на вкючение атаки по расписанию (UTC+0), но почему тогда у меня не видно всплеска? есть, точнее, но маленький
Vort
маленький может быть из-за ежедневной смены структуры распределённой базы. но не в два раза же
`
Vort, чекал новость на опеннете за UDP? Есть потенция для ш2зв?
Vort
`: глянул только что статью: i2pd, по-моему, выкидывает пакеты с поддельными адресами
Vort
видел такие ошибки в логе? вот это оно: SSU2: Host mismatch between published address 75.72.29.35 and actual endpoint 149.88.17.130 from H~5p
relaybot
13apophis: вопрос:
relaybot
13apophis: есть 2 и2пд. Оба сервисуют один домен с один ключом, но на разных портах естественно. Короче, один из и2пд дает ДРУГОЙ домен ключ постоянно, хотя по идее долж <clipped message>
relaybot
13apophis: ен давать то, что ему прописали в туннелс.конф.
onon
Интересно, откуда он может брать этот другой ключ, если он берет только то что в конфиге.
onon
Там точно одинаковые ключи?
relaybot
13apophis: 100%
relaybot
13apophis: я бы не спрашивал
relaybot
13apophis: при каждом запуске 2ого роутера .. дает рандомнык ключ
relaybot
13apophis: не то, что прописано
onon
Ну такое поведение характерно, если ключ вообще не прописан
relaybot
13apophis: иначе я бы не спрашивал
onon
Может там очептка где в конфиле
relaybot
13apophis: если бы так... то и2пд не стал стартовать
onon
Права на чтение/запись клуча есть?
relaybot
13apophis: для меня это не большая проблема .. просто перенесу весь домен на один и2пд... но вот решил вам дать знать на всякий случай
onon
Может он его не читает, и создает новый?
onon
Ну просто у меня на мультихоуминге таких проблем нет.
onon
Ключи одинаковые, отдает все как надо.
relaybot
13apophis: ты знаешь ? я старый дурак без очков .. таки не поставил и2пд/и2пд владелец/группу на импортированный ключ :)))
relaybot
13apophis: спасибо :)
onon
Та не за что, обращайтесь.