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