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

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 ускорил

weko А

orignal так это в 2.53.0

weko Я ж не следил ничего не знаю

weko Так в чём дело было?

onon Пэйсера не было

weko А можно сразу термин чтобы я прошёл читать

weko Ну на англ

orignal это onon скажет

onon pacer

onon pacing

onon en.wikipedia.org/wiki/TCP_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 Верю, а я сам не знаю как это делать.

onon en.wikipedia.org/wiki/Random_early_detection

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 en.wikipedia.org/wiki/Head-of-line_blocking

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 потому что там заголовки характерные есть

orignal habr.com/ru/articles/251143

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 не гаратирован порядок доставки