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

orignal нашел таки косяк в том коде

onon Для запроса к фф нам же сессия не нужна?

onon Или как это работает?

onon Мы ему пакет - он нам пакет

orignal там нету сесии

orignal одноразовое шифрование

onon А через туннель как запрос идёт?

orignal для запроса гифрование по x25519

orignal для ответа таг

orignal через тоннель как сообщение типа Garlic

orignal но это если лизсет

orignal роутеры вообще напрмяую

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

onon Нужно это менять

onon Это критическое место в архитектуре сети

onon Скорость ответа фф

orignal у нас они не поэтому медленные

onon А почему

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

orignal а может например после 4 ого запроса только найти

onon Не находит флудфила? Или кого?

orignal адрес

orignal запросил ближайщший к нему фудфил а там нету

orignal а вот с флудфила найдет сразу

onon Так я про то, что время на опрос этих всех фф много времени занимает

orignal потому что их самих еще надо найти

onon Если мы делаем запрос к фф, он возвращает нам список ближайших известных к искомому

onon А у нас, например нет их в NetDB

onon Мы полезем их RI искать?

orignal угу

orignal мы начинаем их запрашивать

onon Безобразие

orignal предожи другой способ

onon А может фф сразу нам RI отдавать этих флудфилов?

onon Или там атака возможна какая

orignal спроси у деда

orignal почему так нельзя

orignal в ответ вставлять в качестве блоков

onon Оптимально нам конечно просто уже иметь всех фф в базе

orignal это если ты сам фулфдил

onon Если ты конец туннеля, то тоже все нужны

orignal так оно обычно так и бывает

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

onon А запросы к фф у нас ретрансмитятся, если потерялись?

onon Если они вне сессии?

orignal нет

onon Так вот почему они все теряются

orignal да верное замечание

onon А флудфилы из нетдб выбрасываются, если мы ответ не получили?

orignal надо продумать как перепосылать запрос

orignal для лизсетов нет

orignal для роутеров думаю да

onon Вот тебе на выходные занятие, сделать ретрансмиты.

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

Vort "<~orignal> у нас они не поэтому медленные" забыл что ли что у нас около 100 флудфилов постоянно в бане болтаются потому что тупят?

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

Vort запросы по цепочке - это не так страшно, если каждый узел в цепочке отвечает за 100-300мс. проблема же когда лаги достигают 5-10 секунд

Vort это уже цепочкой не объяснишь

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

onon Как минимум ответ получается больше чем запрос. А это вектор для атаки.

orignal в чем?

onon Я шлю 100 кб запросов, получаю мегабайт ответов

orignal на самом деле не совсем так

orignal потмоу что у тебя идет пакетами по 1K

onon RI в 1 кб влезает?

orignal как правило да

onon Тогда можно подумать

orignal вот теперь соотношение NTCP2/SSU2 стало ньрмальным

onon Меня с IRC2P за ночь 5 раз дисконнектило, а с илиты - ни разу.

onon Нужно деду предложить перевести IRC2P на i2pd

Vort лагающий флудфил с любым ответом может тупить

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

orignal думаешь нормальные i2pd флудфилы лагают? сомневаюсь

orignal onon ты сначала RN уговори

Vort я думаю, что надо проверить распределение по версиям, да (номер и i2pd/java). но ещё не помешает проверить распределение по странам

Vort может это вообще атака

Vort даже если это и не i2pd лагает, а java, то тоже решать как-то надо

Vort но может вообще быть всё что угодно. угадать тут сложно

Vort и если бы это были единичные случаи, то и ладно

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

Vort а это около 20% и это дохрена

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