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

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 Та не за что, обращайтесь.