IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#dev
/2024/07/30
~AreEnn
~R4SAS
~acetone
~orignal
~villain
@onon
&N00B
+Xeha
+relaybot
+whothefuckami
Most2
Nausicaa
Vort
`
b3t4f4c3
fujifilm
nemiga
not_bob_afk
poriori
profetikla
segfault
soos
teeth
un
orignal ну так это большая проблема
orignal считаю надо откатить а его код в отделный бранч
orignal работает такая сборка
R4SAS какая?
orignal 2.53 с мордой для адроида он 2.52
orignal точнее это 2.52 у которого i2pd ссылается на 2.53
R4SAS когда будешь .1 делать?
R4SAS я там откатид
R4SAS откатил*
orignal да хоть сейчас
orignal сделать?
R4SAS а у вас там более ничего не найдется?
orignal изменения в I2CP
orignal больше вроде ничего
R4SAS ну, если уже всё обкатали, то можно. только я думаю лучше подождать результаты?
orignal я 2 дня гонял торренты на разных режимах
orignal так что пишу
R4SAS пиши
orignal написал
relaybot 13R4SAS: тегай и пушь
orignal ты посмотрел?
orignal опять забыл как тег писать ))
relaybot 13R4SAS: да там нечего смотреть
relaybot 13R4SAS: могу и я тегнуть
relaybot 13R4SAS: а так: git tag -a 2.53.1 -m "2.53.1"
weko orignal: ты написал что стримы пофикисил, а в чём дело то было?
orignal где ты нашел про стримы?
weko Ты ж писал
weko В #ru
weko Или я напутал что-то?
orignal тэгнул
orignal со стримами ничего не чинил
weko Ты писал про то, что i2cp слишком медленный
orignal сттримы onon ускорил
orignal так это в 2.53.0
weko Я ж не следил ничего не знаю
weko Так в чём дело было?
onon Пэйсера не было
weko А можно сразу термин чтобы я прошёл читать
weko Ну на англ
orignal это onon скажет
onon pacer
onon pacing
weko Спасибо
weko Так я об этом сразу говорил
weko Одно из первых на что обратил внимание когда сел за изучение
orignal дык вы все таки умные ))
onon А про размер окна тоже сразу говорил?
weko onon: да
weko Я говорил что мало
weko И делал тесты с увеличинным
onon Ну вот, а почему не сделали?
onon А, ну если просто увеличить, ничего хорошего не выйдет.
weko onon: потому что были проблемы с зависаниями. Точнее были чаще чем когда меньше
weko Ну условно до 256 увеличил и скорость в тестнете максимальная выросла
onon Вот смотри новые стримы, что я скидывал выше
onon Там я до 1024 окно поднял
onon На 16+16 хопов 450 кБ/с работает
onon Если нормальные туннели.
onon Основная проблема - это контроль перегрузки
weko onon: так я понимаю, просто ты сделал что пачками не шлются пакеты в туннель и оно сразу нормально стало работать
weko Я лося пытался запрячь сделать этл
onon Так как сейчас у нас loss-based СС, а на i2pd не реализован RED, промежкточные узлы перегружаются
weko RED это типо обратная связь? Или лимит по скорости на туннель?
onon Поэтому в новой версии сделан loss-delay
onon Но есть нюанс.
onon Предыдущий CC без delay control будет его пережимать при конкуренции
onon RED это дропы пакетов роутером при перегрузке
onon Ява это умеет
onon В тестах через один хоп яву сразу видно
onon Там срабатывает почти исключительно loss-control
onon И скорость всегда почти одинаковая 150-200 кб/с
onon А на i2pd loss не работает и остаётся полагаться только на delay
orignal лось занят
weko [01:02:55] <onon> RED это дропы пакетов роутером при перегрузке
weko У нас сейчас отключаются создание новых транзитов
weko [01:05:28] <orignal> лось занят
weko Верю, а я сам не знаю как это делать.
weko Да это штуку тоже смотрел
weko Сначала сам понял, потом нашёл как называется
weko То есть при перегрузке мы увеличиваем шанс дропа пакета? Верно?
onon Да
weko И на всех идёт равное распределение
weko Но дропать логично именно там, где самая большая нагрузка. Лучше дать больше средних туннелей, чем мало жирных
onon Если пакеты пэйсятся и соответственно перемешиваются, то рандом дроп будет в равной степени касаться всех и они будут сбрасывать скорость
onon Если кто-то перегружает сильнее, его пакетов в очереди будет больше и их с большей вероятностью дропнет
weko Бля, точно. У жирных туннелей больше пакетов, а значит и больше скорость
weko И больше дропов*
weko onon: ага
weko onon: а что по поводу очереди на транспортах?
onon При нынешних скоростях - достаточно
onon Переделать SSU2, добавить RED
weko Кстати про ssu2
weko А там pacing уже есть?
onon Нету, но Лось обещал сделать.
weko Ясно
orignal маньяна ))
weko onon: несколько помню, Vort хотел поменять механизм очереди, не знаю сделал ли.
weko Моё предположение, I2NP стоит в очереди и проходит много времени (а он стоит, если какой то из транспортов в туннелей перегружен). Тут всё таки 500 сообщений по килобайту. И пока 500 не накопится, не будет дропа. А значит мы не узнаем, что есть перегрузка, а узнаем очень
weko поздно
weko В итоге пакетов дропается очень много
onon Я где-то с месяц назад скидывал RED для NTCP2
onon Там не совсем правильно сделано, но даже он работает.
onon Нужно у деда константы уточнить, какие он использует.
orignal да лежит твой код
orignal еще не смотрел
weko onon: вопрос с очередями тот всё равно остаётся
weko Потому что транспорт это не только мы но ещн и вторая сторона. Она может не вывозить
onon Там WRED был, т.е. если очередь импульсно появилась и исчезла - это норм
onon А если постоянно растёт - нужно дропать
weko onon: а когда она может импульсивно расти? При UDP?
onon Нет, при старте любого стрима идёт импульс
onon Иначе как ты пропускную способность туннеля определишь?
onon Только немного его перегрузив
onon Получаешь обратную связь в виде дропа или выросшей задержки
weko Ага, понимаб
onon И уже от этого уровня можно отталкиваться
weko Чтобы этого достичь, надо переделать
weko Текущий механизм так не может
weko Наверное
weko Тут надо подумать, я давно это не трогпл
onon Те стримы, что я последние скинул, неплохо справляются
onon Там на delay срабатывает
weko Ну это надо садится за кол
weko Код
weko Это в релизе новом теперь?
weko Я так понимаю, теперь нагрузка на сеть вырастет
onon Нет, я тут ссылки скидывал, в ветку пока не пошло
weko А pacing?
onon Там ещё круче всё сделано чем в релизе
onon Скачай, погоняй
onon Я, правда, там уже нашёл что нужно подправить, но это мелочи. Не сильно влияет.
onon Если больше ничего не найду, потом обновлю
orignal weko лучше бы торренты попробовал
weko Это оч круто
weko Возвращаясь у вопросу. Стоит ожидать повышенной нагрузки, выходит?
onon Да
weko Открытие кота в мешке
onon Где раньше было 150 кб/с будет 800 кб/с
weko Что будет - не ясно
weko Вытянут ли все остальные элементв
onon Можно так резко не увеличивать
onon Сначала сделать 256
weko Ну типо поставить окно 256 например?
weko Дааа
onon Потом в след релизе 512
weko Вручную менять мало кто станет
onon И каждый релиз все будут радоваться, что мол скорость выросла
weko onon: гениально, как в том приколе
onon Я с окном вплоть до 9192 тестил
onon 8192*
onon Но у меня в проц упиралось
weko onon: я такое тоже ставил. Стрим зависел очень быстро, тогда. Но там вроде ещё другой баг был
weko В ntcp2
weko Но его мы поймалт
onon Кстати про зависания
weko onon: да у меня из-за проца только 20 MB/s работало
onon Проблема с лизсетами даёт о себе знать
weko А что там?
onon Их нужно будет фиксить параллельно с внедрением ускоренных стримов
onon Почему-то сервер не получает от клиента лизсет и шлёт в пустоту
weko Не видел такого
onon Точно не разбирался
onon Нужно где-то у себя найти код, который лизсеты показывает в консоли
weko А он уже есть
weko Просто нужно вставить куда нужно
onon На больших скоростях обычно вылазит
weko Там кстати баг есть, шифрованные он не умеет показывать
weko onon: не хватает места для лиссета?
onon Хз
onon Лось сказал, что это старый баг
onon И он его пофиксит
onon Поэтому я особо не рвусь разбираться
weko Понятно
weko Там вечно какая то залупа вылазит
onon А насчёт онлайн игр через i2p, основная проблема это holb
weko holb?
onon Это нужно делать для I2NP сообщений пометку специальную или новый тип сообщений вводить
weko А, да точно мы с лосём разбирались
weko Я подробностей не помню
onon Чтобы дропнутый пакет не перепосылался
onon И поверх стримов этого делать точно не стоит
weko Так конечно
weko Потому и есть датаграммы
weko Там мы с лосём обсуждали что нужно что-то с датаграмами сделать, чтобы добавить шифрованный лиссет. Точно
onon Слать такие сообщения только через SSU2
weko А, ты про транспорт
weko Ну тут уже надо подумать можно сделать
weko Первое это поставить максимальный приоритет ssu2, чтобы использовался ntcp2 только когда нельзя иначе. Далее, выбирать такие роутеры, у которых есть ssu2. У теории будет чисто ssu2 туннель
orignal там просто надо это сделать
onon Ну и RED придётся сделать
weko orignal: но сначала убедится что ssu2 не вызывает проблем
weko Далее, в ssu2 есть переотправка. А так ли она она нужна?
weko Если мы используем UDP, зачем тянем что-то из TCP?
onon Ну там же служебные сообщения передаются
onon Вроде запросов на туннели
weko И вот вроде их надо пересылать
weko А остальное зачем?
orignal weko потому что ....
orignal мы используем UDP но мы стараемся гарантировать доставку
orignal но в отличие от TCP порядок сообщений не важен
orignal потому и нужны перепосылки
weko Я кое что вспомнил
weko Почему это полезно
onon Так вот нужен тип сообщений, которым не нужна перепосылка
weko Быстрее потеря найдётся
orignal а ну это можно сделать
weko onon: такого нет, я понял
onon Если целостность контролируется уровнем выше
weko Если идёт потеря на сетевом уровне, то она быстрее восстановиться (в идеале, если всё ок в коде), чем это будет делать стрим на уровне выше с большой задержкой
weko Но вот если мы шлём датаграммы, то это не нужно.
onon Да, но для игры компьютерной, если ты получил состояние 1, потом состояние 2, потом состояние 4, то состояние 3 тебя не интересует
weko Ага
weko Но это всё дело будет выдавать тип подключения транзитному роутеру.
onon Да
orignal для датаграм да перепосылку на ндо
onon Поэтому это нужно продумывать и обсуждать
weko Хотя, думаю и сейчас по характеру трафику можно примерно понять что там
weko onon: с другой стороны, это проблема не сильно критичная. Да, снижает пропускную способность, но премущество UDP остаётся
onon Да, если бы SSU нормально работал
weko onon: ssu2 уже тестил. По сравнению с NTCP2 был хуже
weko Но это на тех стримах
weko Я кстати не помню дошли у меня руки до теста скорости датаграм...
orignal ты снова постеируй
orignal он с тех пор сильно переделан
weko Да надо бы тестнет раскрутить
Vort "<onon> Ну и когда ты его сделаешь?" - глупый вопрос. если это регрессия, то автору изменений её и чинить. если же и старый алгоритм был неуниверсален, так вообще проблем нету. но мне кажется, что это маловероятно
Vort R4SAS: одного узла для базовых тестов стримов должно быть достаточно. но, как я понимаю, публиковать адреса тут в чате не собираешься?
Vort "<weko> ... Тут всё таки 500 сообщений по килобайту ..." я лимит в 500 сообщений выкинул нахрен давным давно, по крайней мере из SSU2. там уже давно другой алгоритм
Vort RED я пробовал сделать - никакой регулировки не обнаружил. скорости меняются быстрее, чем проходит RED сигнал о перегрузке через секундный пинг трёх хопов
Vort перед тем, как внедрять какой-либо механизм, нужно убеждаться, что он действительно работает. почему об этом говорить приходится.. писец
Vort общие же тесты без контроллируемых условий могут дать только намёк на правильную работу. и то, если разработчик знает про наличие confirmation bias и старается минимизировать его влияние
Vort для гарантированного обнаружения эффекта нужны графики с показателями скоростей, потерь и других переменных алгоритма "до" и "после" изменения
Vort orignal: как я понял, коммитом 37d3d9e ты вместе с поддержкой openssl 1.0.2 грохнул и поддержку LibreSSL. случайно или специально?
Vort "<onon> Вот я сейчас через 1 хоп iperf3 гоняю, меньше 1мБ/с не получается" прогнал сейчас точно такой же тест, как вчера (через 2RRY), результат: 11.5 Mbits/sec
onon Vort, я уже выше объяснил, почему использовать iperf для теста стримов - очень плохая идея.
Vort onon: любой паттерн трафика, который работает в чистом TCP, должен работать и в I2P, так что нормальный это тест. особенно полезен он для вычисления регрессий
Vort если просто "не стало лучше" - то это не проблема, писал об этом выше. проблема - когда стало хуже
Vort onon: 250 килобайт/сек файл твой качается через 2RRY сейчас. через iperf3 скорость была выше
onon Там на сервере 2+2
onon Так что через 3 хопа получается, наверное
Vort у меня 1+1 хоп, да. 2RRY
Vort я по-прежнему не могу получить 5 мегабайт/сек, чтобы проверить упор в ядро процессора ))
Vort алгоритм то, может, и неплох, но с организацией воспроизводимых тестов беда
onon А если мне не веришь, найди опытного сетевика и скажи ему "У меня гениальная идея: я буду делать TCP-over-TCP-over-TCP"
onon Если в ответ не услышишь мат - значит плохой твой сетевик
onon Локально файл качай
onon Или через 1 быстрый хоп
Vort я смотрю с точки зрения юзера. юзер хочет, чтобы его обычные программы работали в i2p так же хорошо, как и без i2p
onon Такие программы нужно в udp туннель заворачивать
Vort onon: локально твой алгоритм больше 2 мегабайт/сек не выдаёт
onon А никак не поверх стримов пускать
onon У меня выдаёт
onon Ты неправильно его используешь
Vort "через 1 быстрый хоп" - пока что никто не выложил адреса
Titlacahuan эсть много вариантов ТСР и некоторых из них можно пригодить за работу в I2P
onon А локально файл качать - не получается?
Vort я локально с iperf3 тесты делал, сейчас попробую через примитивный веб сервер
Vort сложно поверить, что будет быстрее. но а вдруг
Titlacahuan в точности congestion контролья можно настраивать до безконечности
Vort onon: всё, как я и ожидал: 1700 KB/s через веб сервер
Vort через локальный узел
onon И как долго тестировал?
Vort 2 минуты
onon Возможно тебе не повезло, и на старте сработала защита, он тогда медленно разгоняется
onon Пробуй ещё
Vort а, может, мой сервер, как и iperf3, неправильный? :))
Vort или curl не такой
onon Нет, сервер должен быть правильный, если там лимитов нет
onon Не выёбывайся
Vort раз 5 запускал - всё время стабильные 1700 KB/s. при этом загрузка процессора у i2pd около 1%
onon Через 2RRY файл качай
Vort по ошибке сейчас запустил скачку твоего файла вместо своего - и тоже заметил значение 1700. не такое стабильное, правда
Vort сейчас и через 2RRY попробую
orignal Vort я проверял libressl
orignal все нормально с ней
orignal разумеется новые версии
Vort orignal: там же нету нужных констант
Vort EVP_PKEY_CTRL_SET_DIGEST_SIZE
Vort libressl-3.9.2.tar - искомые файлы не найдены
weko [11:10:02] <Vort> я по-прежнему не могу получить 5 мегабайт/сек, чтобы проверить упор в ядро процессора ))
weko Ну, если запустить тестнет, то наверное вщ изи.
orignal ладно посмотрю
Vort weko: если сможешь, то сделай сравнение последних нескольких версий. чтобы понять вектор развития так сказать
orignal ты че хочешь сказать что там нету нормально релизации EdDSA?
weko [11:10:35] <onon> А если мне не веришь, найди опытного сетевика и скажи ему "У меня гениальная идея: я буду делать TCP-over-TCP-over-TCP"
weko Я тебе говорю, тут максимум TCP over TCP, из-за i2p. В обычной же сети iperf не TCP-over-TCP? i2p не делает два раза это, только один из-за ntcp2
onon В iperf3 встроен CC
onon cubic или bbr на выбор
Vort конкретной константы нету, что это значит - мне сказать сложно. я вообще этот код не смотрел
onon Кубик не шлёт новые данные, пока не получит подтверждение предыдущих
onon Понятно, нет?
weko Ну как и любой TCP работает
weko В чём проблема то?
onon В том, что iperf3 не шлёт новые данные
weko Между iperf и i2pd TCP соединение, но оно не должно делать проблем
orignal Vort это оказывается siphash
orignal счас починю
Vort #if наверно подшаманить надо
weko onon: так не шлёт тогда, когда буфер у i2pd забит. Логично
weko [11:34:51] <Vort> weko: если сможешь, то сделай сравнение последних нескольких версий. чтобы понять вектор развития так сказать
weko Это можно и нужно
orignal да там легко
weko onon: TCP over TCP есть, не спорю, но оно внутри i2p, iperf тут не при чём
orignal починил LibreSSL
Titlacahuan об ТСР, в жава I2P пользуется Westwood+ CC
Titlacahuan я сам писал, дед помогал
orignal не факт что он лучше чем то что счас
Vort проверил скачку с локального веб сервера через 2RRY, скорость - 500 KB/s. опять узел перегружен, видимо
orignal Titlacahuan у тебя muwire раюотает нормально?
orignal 2RRY?
Vort ну через него протянул туннели
Vort а концы (серв и клиент - у меня)
Titlacahuan да, без проблемов
orignal счас скажу что с ним
orignal 170% CPU )))
orignal Transit: 2541.70 GiB (3957.30 KiB/s)
orignal Transit Tunnels: 15856
Vort отменил скачку. небось транзит теперь -1 мег ? )
Vort ну то есть 4 -> 3
orignal Transit: 2541.94 GiB (2595.12 KiB/s)
orignal ага
Titlacahuan проблем с muwire когда I2CP связь пропадёт из за выключения рутера, но это мой баг
Titlacahuan снарк автоматически восстоновляет связи а muwire пока нет
orignal снарк да работает хорошо
Vort orignal: может, фикс LibreSSL стоит включить в точка-релиз ? хз, двигаете ли вы теги, но, вроде, было уже такое
orignal а зачем?
orignal кому надо те сами разберутся
Vort может у них сборка по тегам, хз
orignal ну и я знаб как тег дивгать
orignal вот R4SAS придет
Vort разобрался я, почему алгоритм стримов от onon тормозит
orignal рассказывай
Vort для того таймера, который он выбрал, микросекундные пожелания - это слишком
Vort он вытягивает только один-два вызова в миллисекунду
Vort или таймер надо менять или таки отправлять по нескольку пакетов за раз
Vort я сейчас собираю оптимизированную версию с патчем для отправки 6 пакетов за раз. скоро скажу результаты
orignal микросекундный таймер у него разрешения в сотни только
Vort скорее всего, на винде ещё грубее
orignal я знаю это из практики
orignal линукс
Vort ну вот, а у меня win 7
Vort примерно в 6 раз быстрее и стало: 62.4 Mbits/sec
Vort то есть, 8 мегабайт/сек
relaybot 13apophis: а что там ? std::chrono::high_resolution ?
Vort и я начинаю наблюдать упор в CPU
Vort но что самое интересное - упор идёт на стороне промежуточного узла и сервера (который скачивает)
Vort а отправляющий клиент не сильно то и грузит проц - раза в 3 меньше, чем другие узлы (то есть, в сумме, в 6 раз меньше)
Vort m_SendTimer.expires_from_now (boost::posix_time::microseconds(m_PacingTime));
Vort boost::asio::deadline_timer m_SendTimer
relaybot 13apophis: если надо микросекундная точность и легкая имплементация то посмотрите plf::nanotimer
Vort сейчас скажу загрузку на стороне сервера
relaybot 13apophis: боост посих обычно сильно медленный в сравнении с std::chrono. по краййней мере это известная проблема
Vort 17% i2p::garlic::GarlicDestination::HandleGarlicMessage
Vort 17% i2p::transport::SSU2Server::HandleReceivedPacket
Vort 6% i2p::transport::SSU2Server::HandleReceivedFrom
Vort 19% i2p::tunnel::InboundTunnel::HandleTunnelDataMsg
Vort 12% sha256_block_data_order
Vort остальное мелочи
orignal давай тогда PR
Vort ха. это просто хак. размер отправляемого блока должен быть динамическим в зависимости от нагрузки
Vort и вот если onon это сделает, тогда уже можно будет алгоритм нагружать, следить, не повылазят ли глюки и заниматься оптимизацией
orignal даже хак всет равно же улучшает ситуацию
orignal ты сколько посавил?
Vort упрощённо, моё предложение такое: измерять, сколько реально прошло времени с прошлого вызова таймера и если заметно больше, чем надо, то докидывать дополнительные пакеты в блок. не знаю, насколько эта идея реальна, но на всякий случ
Vort ай пишу
Vort "<~orignal> даже хак всет равно же улучшает ситуацию" улучшает при локалхостовых больших скоростях, но при этом, насколько я понимаю, ухудшает, уменьшая эффект от пейсинга на скоростях поменьше
Vort если вдруг окажется, что по-нормальному сделать нельзя, тогда нужен хак, да. но я надеюсь, что по-нормальному сделать всё-таки можно
orignal понял
orignal передлелал 2.53.1
orignal я предлагаю m_PacingTime огрничивать снизу 250
orignal onon твое мнение?
Vort сейчас m_PacingTime - это по сути другое название для ограничения максимальной скорости
Vort если его ограничить снизу - то ограничится скорость сверху
orignal ну вот где таймер заводится надо чтобы минимум 250 было
orignal иначе херня будети
Vort это надо делать только в комбинации с группировкой пакетов в блоки при большой скорости
Vort ну и у меня, скорее всего, даже 250мкс таймер не вытянет
orignal занчит #ifdef win32
Vort или 500мкс или 1000мкс. можно измерить, наверное. но точные моменты времени ещё и прыгают, похоже
Vort ну допустим для константы, да. но всё равно динамическая группировка нужна, хоть 250мкс, хоть 1000мкс
Vort orignal: скажу даже чуть иначе - ограничивать таймер надо по двум причинам. первая - windows 7 (а, может, и другие) и вторая - чтобы не тратить ресурсы на лишнюю дёргатню/вызовы
orignal вот у меня вторая
orignal пойду 2RRY перестартую
orignal минут 15 будет недоступен
orignal все
relaybot 13apophis: вы в курсе, что dealine_timer нестабилен про external system time updates ? типа НТП и .т.д
orignal не ссы
relaybot 13apophis: steady_timer betetr
orignal мы на работе используем и срабатывает весьма точно
orignal ты спутал
orignal steady_timer это часы
orignal а dedline_timer это будильник грубо говоря
orignal разные вещи
relaybot 13apophis: нет
relaybot 13apophis: взаимозаменяемые
orignal ссылку в студию
orignal как завести евент скажем через секунду
relaybot 13apophis: интеревал
orignal с помощью steady_timer
orignal понимаешь у deadline_timer под капотому timerfd
orignal и где тут место для monotonic?
relaybot 13apophis: я не буду с тобой спорить
relaybot 13apophis: я нма код смотрел
orignal точнее я полагаю он реально и сидит на monotonic
relaybot 13apophis: и на статьи, где именно про это говорилось
relaybot 13apophis: про боост::микросекондс я молчу вообще
relaybot 13apophis: оно медленнее стд::кронос
orignal man timerfd_create
orignal ты путаешь часы с будильником я же тебе говорю
orignal для часов естественно std::chrono
orignal файл Timestamp.cpp
relaybot 13apophis: ты не читаешь
orignal читаю
orignal можно поменять там я думаю на std::chrono
orignal но тут вопрос с какой верисии буста это можно
orignal да steady_timer есть но с какой версии?
orignal а так спасибо за подсказку
relaybot 13apophis: timer.expires_from_now(boost::chrono::milliseconds(ххх));
relaybot 13apophis: ???
orignal попробую заменить
relaybot 13apophis: так нел;ьзя ?
relaybot 13apophis: это 1й вариант
orignal а он есть
relaybot 13apophis: 2ч это сам таймер бооста
orignal или там std::chrono
relaybot 13apophis: у меня цчроно
relaybot 13apophis: у вас писих
orignal надо попробовать steady_timer
relaybot 13apophis: у вадс посих
relaybot 13apophis: но !!!!
orignal вот там в стримах где разрешение высокое
relaybot 13apophis: стеади только с 11 плюсов
orignal i2pd всегда 11
orignal буст тоже не ниже 1.62 надо
relaybot 13apophis: посмотри еще std::chrono::high_resolution_clock
relaybot 13apophis: этот гарантирует интервал .. якобы
orignal а там рутовые права не нужны?
orignal для его запуска
relaybot 13apophis: кстати, вот гоогл что пишет
relaybot 13apophis: There is excellent responce to similar problem here: stackoverflow.com/a/16364002/3491378
relaybot 13apophis:
relaybot 13apophis: Basically, the main difference is that if you expect any external changes to the system clock, you should rather use steady_timer - deadline_timer delay will be affected by those changes
orignal ага
orignal попобую
weko Что думаете по поводу обфускации транспортов?
orignal во что? в https?
orignal счас трафик и так хорошо спрятан
weko ну можно во что угодно
weko orignal: да не спорю
orignal под что ты хочешь маскировать?
orignal надо вопрос ставить так
weko Но тут вопрос что если включат DPI в режим бана всего не знакомого, то i2p работать не будет
orignal ну вот я тебя и спрашиваю что предлагаешь ты
weko orignal: ну вот https вполне да
orignal да это старая идея
orignal миожно наверное
weko Ну как в Китае делают щас
weko orignal: если ssu2 то мб dtls или же просто tcp + tls
weko То есть сдать пакеты который выглядат как tcp + tls, но фактически там ssu2
weko Слать*
orignal ну надо еще в адресе какие то тогда флаги добавлять чтобы обе строны понимали
weko Есть ещё всякие торренты, что более правдоподобно выглядит, чем обращение к тысяче сайтов
weko orignal: да конечнр
orignal а вооще ssu2 надо маскировать под quic
weko Ну как вариант
weko Правда могут его забанить
weko Тоже
weko tcp меньше шанс...
weko Тут надо подробно тему изучить чтобы выбрать
orignal так как ты собираешься маскрировать UDP трефик под TCP?
weko orignal: через raw сокеты
orignal ага и запускать везде от рута
weko А, ну да
weko Тогда видимо никак
weko SRTP, uTP, DTLS
weko QUIC
orignal о чем я тебе сразу и сказал
weko Но QUIC то именно транспорт, DPI могут смотреть что именно передаётся
orignal так он шифрованный
orignal можно добавить заголовок а что внутри фиг определишь
weko orignal: так понятно, но tls вот например себя выдаёт, и DPI в режим вайтлиста протоколов пропускает
weko А i2p он не понимает и пускать не будет
orignal потому что там заголовки характерные есть
weko orignal: да заголовок, но всё равно нужно будет сделать tls с фингерпринтом браузера
orignal мой страый труд ))
orignal нет
orignal браузер сидит внутри шифрованного
weko orignal: да но он шлёт отпечаток открытым текстом
orignal никогда
weko orignal: ну а зачем тогда для обхода блокировки делают фингепринты как в браузерах?
orignal ты путешь
orignal с протколом установки соединения
weko GFW банит если отпечаток не похож на знакомый
orignal GFW банит всякий tls
orignal а пропускает только нешифрованный
orignal не говори чего не знаешь
weko orignal: нет там tls работает
weko Иначе бы там пиздец был совсем
orignal кроме того от браузера приходит запрос CONNECT
orignal вот его то и смотрят
orignal еще раз: не знаешь не говори
weko orignal: ну и есть fingerprint, в котором например какие версии поддерживаются
weko Какое шифрование
orignal CONNECT нужен чтобы знать к какому адресу на IP обращение
orignal это уже tls
weko Так речь про tls
orignal еще раз для непонятливых
orignal браузер сначала шлет CONNECT с адресом в нем
orignal дальше сервер понимает и начинает tls сессиию
orignal что идет внутри tls никакому dpi понять не дано
weko Так это понятно
weko Я ж говорю именно про отпечаток
orignal ну а если понятно то про какой фигерпиринт ты говоришь?
orignal нет такого
orignal толкьо установка соединения
weko Typically clients' first approach here would be the hello message, in which they declare the set of TLS parameters it supports. Some of these include:
weko The max TLS version it supports (TLS 1.0–TLS 1.3).
weko A list of cipher suites, that is, the cryptographic algorithm to be used for encryption.
weko A list of supported extensions.
weko Суть в том чтобы использовать параметры как у популярных браузеров, чтобы не банили
orignal ну так это TLS а не браузер
orignal ну так вот с UDP проще потому что там нет сессии
orignal а набор разрозненных пакетов
weko orignal: это да
weko Но если брать quic, то там сессии есть
weko А по quic уже типо передаётся tls
orignal да но в UDP не гаратирован порядок доставки