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

not_bob Who runs shinobi.i2p/?

orignal not us

not_bob Ok, cool. Thank you.

onon orignal, тут?

orignal нет

onon Ну ладно, раз его нет, буду сам искать.

orignal че хотел?

onon Можешь коротко описать схему подключения к U узлу, если я R узел.

onon Через кого и как

orignal у U узла будут поля ih и itag

orignal по ih находим в netdb этот роутер цепляемся к нему

orignal шлем ему RelayRequest с этим itag

orignal он находит по этому itag-у сессию и кидает в нее RelayIntro с твоим IP и портом

orignal тот отправляет ответ RelayResponse а на твой адрес сообщение HolePunch

orignal как только ты получил ответ и/или HolePunch ты устанавливаешь с ним соединение

orignal потому что там приходит его IP и порт

onon ih это кто? он всегда одинаковый для этого роутера?

orignal это base64 адрес роутера интродьюсера

orignal обычно их публикуется 3 разных у U роутера

onon Они рандомные?

orignal это уже отдельный вопрос

orignal U ротуер выбираеет их из существующих сесиий с роутерами которые согласны быть интродьюсерами

onon А бывают несогласные?

orignal бывают

onon Надо чтобы не бывало

orignal это в caps SSU2 адреса публикуется

orignal если ты сам U ты можешь быть интродьюсером

onon Это странно.

onon Неправильная логика.

orignal согластие же быть интродьюсером выражается в ответ itag-ом если таковой запрошен

orignal *не можешь

orignal если ты U то у тебя в caps этого флага нет

onon Ага

orignal я все забываю кто есть кто

orignal то ли B то ли C

onon Это как-то включается в настройках, быть интродьюсером, или по умолчанию включен?

orignal в i2pd включен всегда когда может

orignal можно такую настройку добавить

orignal в секцию ssu2

onon Я примерно понял, есть идеи как улучшить этот механизм.

onon Могу сейчас накидать, могу завтра.

orignal первое что надо переделать

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

onon А слать сразу трём не вариант?

onon С одним ид, ответит на первый пришедший а дубли дропнет.

orignal не знаю

onon И вообще, должно быть так: твой интродьюсер - это несколько (7) самых бизких (или дальних) к твоему base64. Если кто-то хочет к тебе подключиться, ищет у себя в нетдб ближайщий (или дальний) роутер и пробует.

onon В ответ получает или коннект или список ещё более близких или дальних роутеров.

onon И ты сам, регулярно проверяешь у себя в нетдб более подходящие роутеры и перезжаешь.

onon Ещё пиртест у нас как-то очень странно устроен...

onon Должно хватать трёх запросов к разным узлам, ответили тебе одинаковой парой ип:порт - значит доступен. Если разные, ставим U.

onon Зачем нам определять тип ната, если мы не пытаемся коннектить U узлы между собой.

orignal у нас наоброт

orignal потому что сообщения могут теряться

onon Ну отправь ещё к другому запрос.

orignal и сколько отправлять?

onon Пока не определил, за натом ты или нет

orignal реально firewalled или просто пир тест не пришел?

orignal ну не пришел пир тест 5

onon Через промежутки времени слать

orignal это firewalled или потрелялся?

onon Я про простую схему с одним запросом.

Vort "<onon> ... Пакеты остальных пользователей встают в конец очереди и дропаются через некоторое время." нет, не так. во-первых, дроп сейчас с начала очереди, а не с конца, дропается старьё

Vort во-вторых, шанс дропа пропорционален скоростям узлов. если пришёл быстрый узел и занял 90% канала, то и дроп его данных будет с 90% шансом

Vort так как вероятность устаревания данных в очереди не зависит от того, кто эти данные в очередь поставил

Vort единственное, что может быть плохо - это дропы данных блоками. но разве кто-то проводил эксперименты и обнаруживал, что они таки блоками дропаются?

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

Vort теперь поясню, чем плох лимит по количеству - хоть с рандомом, хоть без

Vort с лимитом по количеству для медленных узлов очередь запросто может наполниться ненужным старьём - за десятки секунд

Vort в то же время, для быстрых узлов этого же самого лимита будет не хватать - лимит будет тормозить скорость. просто так

Vort "<~orignal> там можно же и по времени" - да. дроп может зависеть от наполненности очереди, но наполненность эту можно задать через время жизни самого старого пакета в очереди

Vort по тому же принципу, что onon сказал - от 1 до 2 сек лага для старых пакетов дают от 0% до 100% дропа новых пакетов (кроме своих [onDrop], для которых дроп идёт сразу же)

Vort но прежде, чем такое делать, всё же надо подтвердить наличие проблемы и убедиться, что предлагаемое изменение действительно что-то улучшает. отдельный вопрос - как это улучшение измерить

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

Vort попробую релизовать рандом дроп по времени. тем более, я в коде свою ошибку обнаружил, всё равно исправлять надо :(

Vort сделал вот как, тестирую теперь: github.com/Vort/i2pd/commit/4e7fede0f26c3c8d2f345a2823282589146cb1a2

Vort пока что балансирующего эффекта не вижу - если отправка залипает, то надолго. но буду наблюдать дальше

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

Vort пока что в основном тормозные узлы наблюдаю - дроп дошёл до 100%, а сообщения всё валят и валят, до 10 секунд лага доходило

Vort на более быстром узле один раз что-то похожее на баланс увидел - когда лаг балансировал между 1 и 2 секундами

Vort то есть, узел "понимал" такую индикацию перегрузки

orignal ну вот моя такая же мысль что если уже узел тормозной то все равно придется делать дисконнект

Vort явно есть несколько категорий узлов

orignal вот надо это писать в профилировщик

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

Vort так а просто отключение электричества не так ли разве будет выглядеть?

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

Vort подожду, пока быстрый узел попадётся на перегрузку - по-моему, они лучше поддаются балансировке

orignal так и не надо постоянно маркировать а только на время

Vort кстати, я много раз уже видел, что узел тащит по нескольку сообщений в секунду, но при этом транспорт живой - так по чуть-чуть с дропами кто-то качает на протяжении минут

Vort больше данных собрать надо по поведению узлов, в общем

orignal "по чуть чуть" это означает что очередь будет у тебя

Vort так там очередь обычно сообщений 10 получается

Vort с моим последним коммитом добавление в очередь блокируется при 2 секундном лаге

Vort не понял мысли. сейчас я сделал 0 сек - 0% дропа, 1 сек - 0% дропа, >2 сек - 100% дропа

orignal а если 5 сек?

Vort но дроп как onon говорил - при добавлении

Vort 100500% дроп :)

orignal ну да но вероятность должна зависить от времени

orignal чем больше время тем выше ветоятность

Vort она и зависит на промежутке от 1 до 2 секунд

Vort 1.5 секунды лаг - 50% дропа

Vort можно и другую функцию выбрать, но, думаю, и эта сойдёт

Vort при > 2 сек предполагаем, что с узлом задница и уже не пытаемся ему чем-то помочь - просто защищаем нашу очередь от бесполезного раздувания

Vort отлагает - молодец. не отлагает - ну и хрен с ним

orignal можно и так

Vort вообще, я думаю, под медленные узлы не стоит особо оптимизировать алгоритм. с ними постоянная задница

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

orignal то что я ниасилил в свое время

Vort мелкий косяк в прошлом коммите выловил. понадеюсь, что тут нету. тестирую дальше: github.com/Vort/i2pd/commit/b1a4845343edf48b226888978e091f41e37e8daa

onon1 Vort, arxiv.org/pdf/2109.11693.pdf

Vort ну да, то, что я и сказал: "if a router buffer is too small, it can cause high packet loss and link under-utilization. If a buffer is too large, packets may have to wait an unnecessarily long time in the buffer during congested periods"

onon1 ¯\_(ツ)_/¯ В, общем делайте как хотите, я сдаюсь.

orignal ты обещал про интродьюсеры

onon1 Я же вчера всё расписал

Vort я тоже много чего расписал, почитай выше

orignal а ну тогда ладно

onon1 > И вообще, должно быть так: твой интродьюсер - это несколько (7) самых бизких (или дальних) к твоему base64. Если кто-то хочет к тебе подключиться, ищет у себя в нетдб ближайщий (или дальний) роутер и пробует.

onon1 > В ответ получает или коннект или список ещё более близких или дальних роутеров.

onon1 > И ты сам, регулярно проверяешь у себя в нетдб более подходящие роутеры и перезжаешь.

orignal а ко мне пытается по моему base64?

orignal в надежде что у меня с тем узлом есть сессия что ли?

Vort это предложение вообще выкинуть интродьюсеры с RouterInfo что ли?

onon1 У меня всегда есть непрерывная сессия с моими интродбюсерами

onon1 Кто хочет ко мне подключиться, шлёт на интродьюсер сообщение, мол передай этому Васе, чтобы соединился со мно, вот, кстати мой порт и адрес.

onon1 И Вася, получив сообщение, сам через нат устанавливает коннект с нами

orignal а как тот узнает что у тебя сессия именно с этим интредьюсером?

Vort ближайший в чьей-то netdb - не значит ближайший в нашей

onon1 Он близкий по DHT

onon1 Ну так я и говорю, что их 7

Vort а долго пробовать - времени нету

orignal нетдб же у всех разный

onon1 И если нет всесссии, возвращает список ещё более близких

onon1 И так за Несколько раундов находит интродьюсера

orignal определенная разуность есть только не будет ли тут возможность для атаки?

orignal слишком много пустых запросов же будет

onon1 Ну как и сейчас на флудфиле, если он не знает, отдает более близкие роутеры

orignal так на то он и флудфил

orignal у него особая роль

orignal и флудфилов мало относительно остальных узлов

onon1 Ну двай это всё на флудфилы и повесим, раз они вызвались

orignal это можно да

orignal но тогда у них же будет вообще море сессий

onon1 Ну они в основном простаивать будут, но будет много да

onon1 Тут или крестик или трусы

Vort onon1: какие-то тесты для вероятностного дропа сообщений придумывал?

onon1 Не совсем понял вопрос

Vort ну вот я сделал коммит (ссылку выше кидал). как понять, улучшил ли его вероятностный характер работу congestion control?

Vort то есть, интересует эксперимент, который позволяет получить измерение, показывающее, улучшилось ли что-либо

onon1 Забей буфер непрерывным потоком и поробуй через другой стрим скачать что-нибудь

onon1 Или пусти туда десять потоков и посмотри на равномерность распределения скоростей.

Vort ок, спасибо. на локалхосте, правда, наверно, не получится проверить

onon1 Если прям совсем заморочиться, можно на каждый поток считать RTT, jitter, bw и потом всё сравнивать.

Vort так как у меня стримы упираются в CPU, а не в сеть (которая локалхостовая)

onon1 А ты исследование что я скинул, дальше заголовка не прочитал?

Vort ну я увидел, что там речь о железках и выборе размера микросхемы памяти для них по сути. в i2pd не тот случай

onon1 Ну ладно, ¯\_(ツ)_/¯

Vort почитал ещё и в конце :) "To someone working on congestion control, this paper may feel a bit backwards... instead of sizing buffers based on unintended artifacts... we could instead design congestion control algorithms that work well for all queue sizes"

Vort для i2p такой вариант ещё хорош тем, что достаточно обновить два узла - сервер и клиент и получать преимущества обновлённого алгоритма стримов (если его кто-то обновит, конечно)

Vort а вот для того, чтобы подогнать буферы под глюченые стримы - это уже надо обновить значительную часть сети

Vort поэтому лимитами буферов стоит ловить лишь явные проблемы наподобие лагов > 1 сек и атак на переполнение буферов и не мешать улучшению стримов

Anonymous Vort too bad you weren't in #en lol

Anonymous We were discussing SAM a little bit, and the max tunnel quantity of 16 per session

Vort are there problems with this limit?

orignal no it's right. nothing useful

orignal Anonymous has another "genious" idea

Anonymous I was told by at least 2 people that more tunnel quantity would be beneficial to torrenting

Anonymous It's not just "my genius idea"

Vort nice to know this. but problems are not with limit itself if I understand correctly

Vort problem is that tunnels are often "weak"

Vort they can't handle required load

Anonymous qbittorrent has issues that are reproducible, not sure if it's related to SAM, but besides that, I was wondering if more SAM sessions would help, and how difficult it'd be for say qbittorrent to use multiple of them, Vort.. but I guess I'm too big of an asshole and people don't like me, they act as-if I'l doing something selfish just for myself lmao

Anonymous Hmmm Vort are you referencing some other issue that's currenting ongoing?

Anonymous Becaues I'm not referencing any existing issue, just so we're clear

Vort I'm basically saying that if each tunnel can handle ~16KiB/s, even 16 of them is not enough

Anonymous What is also bad is that 1. qbittorrent doesn't offer documentation for i2p, and 2. there's no #dev channel for qbittorrent on oftc where I am, so that's bad too and can't mail them.. this isn't I2P dev, but I think it would benefit I2P a lot, indirectly and perhaps directly if we were to change anything SAM-related.

Anonymous Vort: so you're saying more = better?

Anonymous 100x~16kb/s = good?

Vort not overloaded network is better. how to achieve this is mystery

Anonymous orignal: I'm also laughing at you at some thing, like thinking that knowing English is not important, you fool

Anonymous not overloaded network?

Anonymous So this is outside of SAM issue?

Anonymous Or application-specific solution perhaps

Vort yeah. right now network is under attack or very similar abuse

Anonymous or outside of application-specific solution, perhaps*

Vort it just can't handle high speeds

Anonymous Vort: I noticed something about that (discussions)

Vort also some bugs preventing network from working correctly

Anonymous So ongoing resolve should deal with this, too?

Anonymous I see

Anonymous That's because orignal is developer and doesn't know English well

Anonymous (:

Vort I think community should find people abusing network and tell them how to use it properly

Anonymous I'm so sad because I can't prove how stupid he is, as much as I'd like

Anonymous I like proving myself :P

Anonymous What do you mean?

Anonymous Accidental abuse or something?

Vort I suspect that some applications may overload network with lots of unneded tunnels

Vort like creating 1000 SAM sessions per user :)

Anonymous I see

Anonymous Vort: 1 application 1000 SAM sessions, you mean?

Anonymous qbittorrent has only 1 SAM session, and 3 tunnel quantity by default

Vort yeah. instead of 1 session with 1000 streams

Anonymous wow

Anonymous I have a solution for that...

Anonymous well

Anonymous kind-of

Anonymous So maybe I will write a proposal

Anonymous not sure if it solves problem entirely

Vort also some people can't understand that if they create lots of tunnels, they should try to handle similar amount with their nodes. but instead they put limits like 20 tunnels on node. while creating thousands

Vort it is possible to clarify documentation (if it is not clear yet)

Vort other than that I think it is more social problem to solve

Anonymous basically my idea was having SAM with 2 ports, 1 for trusted users/computers, 1 for untrusted users/computers, and have options like SAM.untrusted.tunnel.quantity and SAM.untrusted.sessions_max for example

Anonymous tihs is sketch-talk

Anonymous this*

Vort you can't prevent people from being assholes by writing better software :)

Anonymous Vort: social problem? You mean "orignal not knowing English well" problem?

Anonymous Vort: you can, you should

Anonymous every user should be treated as malicious

Anonymous until they gain enough trust over period of time and/or successful interaction

Vort you are right (partially), but such approach is not always possible

Anonymous I know

Anonymous For example the peer initialization or something like that?

Anonymous You connect to a bunch of peers and discover more trough them, no? what if the intial peers are bad? IDK

Anonymous I don't know how I2P works, all I know is that I excell in criticial thinking and planning, and will prove to orignal this one day

Anonymous I'm shit because I have shit eyes, right now

Anonymous Anyways I'm glad there are English speakers in here.. who would have thought that language barrier would be an obsticle in developemnt of such scale?

orignal короче если по простому чувак не понимает что ограничение в 16 тоннелей это не блажь

onon1 Ну пускай строит больше - быстрее построит туннель из майорских узлов.

orignal строить то можно хоть миллион но в лизсет ты можешь пихнуть тольо 16

orignal иначе такой лизсет флудфилы выкинут

Anonymous Помогает ли больше сеансов SAM?

Anonymous qbittorrent = 1 SAM session

Anonymous maybe it's auto

orignal возможно

Vort проблема более общая, я её даже в этом чате много раз видел: люди думают, что если не лезет, то надо пихать посильнее

Anonymous (:

Anonymous lol Vort

Anonymous ЛОЛ

Anonymous Vort: was my Russian good right now?

orignal Vort ага еще любят ставить X )))

Anonymous The translation RU->EN is good enough, is EN->RU?

Vort orignal: если у кого-то действительно есть ресурсы, то пусть ставят

orignal но с торрентами будет проблема

orignal они могут начать качать друг с друга ))

Vort вот хрен кто скажет - а какие реально возможности у среднестатистического юзера?

Vort может, всё же ближе к X, чем к L ?

Anonymous многие люди используют i2p для торрентов, и многие другие будут, когда он станет лучше

Vort orignal: и что - увидят нагрузку и испугаются? не понимаю проблемы

orignal я про несколько сэмов

Vort а...

orignal насчет X просто придурки его ставят а у самих не тянет

orignal Anonymous нихуя

orignal мало кто использует торренты через i2p ибо смысла нет

Anonymous есть много точек, чтобы использовать торренты через i2p!

orignal wrong translation

Anonymous :d

Anonymous I said "there are many points to use torrents over i2p!"

orignal I know what you said

orignal есть много случаев использования торрентов через i2p

Anonymous Your translation was wrong?

Anonymous oh

orignal that's correct translation

Anonymous "few people use torrents trough i2p because there is no point"

Vort и это не совсем

Vort есть много причин* скорее

orignal ну близко по смыслу

Vort Anonymous: "many reasons", right?

Anonymous yes yes :)

orignal Anonymous "мало кто использует торренты через i2p потому им это на хуй не вперлось"))

Anonymous 'point' is argumental terminology for 'my reason to say/do this', something like that

onon1 мало кто использует торренты через i2p потому что мало кто использует i2p

onon1 =)

orignal так и кто использует тоже

orignal кроме тех самых магнитов смысла нет

orignal я все скачаю торрентом через клир

Anonymous translating Russian is too much pain in my ass -_-

Anonymous too slow

Anonymous takes 1 minute to copy text

Anonymous I could argue with orignal for hours about how he's wrong right now

Anonymous I2P will be popular and good

Anonymous I2P torrenting will be good

Anonymous I promise you

Anonymous Translation is shit

onon1 SAM использует наши туннели для передачи данных или строит свои как I2CP? Я просто не знаю...

orignal а нас сэм напрямую со стримуми работает

orignal но дестинейшин он создает собственный по запросу

onon1 Короче, если он транк накатит, у него скорость вырастет?

onon1 Если так, скажи ему, пусть занимается и не отвлекает тебя от дел.

orignal да он пиздабол в принципе

onon1 Я заметил...

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

orignal я так понимаю ацетон так и не появлялся

Vort paste.i2pd.xyz/?da79e4129b7f8e37#7rFX5qujKAJhQ6r6P8EYGnoKZLKem6QXG8RpJSsEP7Mx

Vort вот пример более-менее успешной регуляции с помощью рандомных дропов

Vort по оси x - количество дропнутых пакетов (примерно время)

Vort вверху - лаг, внизу - размер очереди

Vort но такая ситуация редкая, чаще лаг ползет вверх пока сообщение уже по основному таймауту не грохнется. не уверен, правда, в правильности понимания

Vort вопрос, почему SSU2 не рвёт соединение раньше. там же есть макс. количество перепосылок

orignal разве?

orignal елси он этого не делает то бага

Vort ну я имею в виду SSU2_MAX_NUM_RESENDS

Vort но я пока плохо разобрался с этим механизмом

orignal ну я думал когда мы достигаем этот значения то должны закрывать сессию

Vort может, для него 10 секунд подождать - это норма

orignal возможно не сразу

orignal возможно он снчала шлет сообщение о завершении

Vort а, может и в этом дело быть

orignal а уже потом рвет

Vort разбираться надо

Vort а помнишь баг с логикой завершения?

orignal там довольно сложно

orignal уже нет

Vort "Требуемый адрес для своего контекста неверен to 0.0.0.0:0"

Vort там из-за логики состояний SSU2 проблема

Vort может он и тут гадит

orignal я эту проблема пока так и не понял

Vort я пояснял, сейчас найду в логах

orignal ты хочешь сказать что мы где то зануляем endpoint?

Vort major.i2p/ilita/dev/2024/01/07#msg161

orignal счас гляну

Vort Closing ставим даже если не было Established

Vort хотя сейчас уже понимаю, что это разные проблемы

Vort но близкие по месту расположения

Vort пытаемся закрыть не уставноленную сессию. оттуда и адрес 0.0.0.0

orignal я так и не починил

Vort ну надо же ничего и не поломать ещё в процессе починки )

orignal я просто забыл ))

Vort хорошо, что логи чата есть, а то и я бы забыл )

Vort помнил только что где-то в логах объяснение есть

orignal ну я попробую починить

Vort смотрю логи узла с рандомизированным дропом сообщений - и попался случай, когда один пакет провисел в очереди 20 секунд (был единственным с 8 по 20ю секунду)

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

Vort чтобы хотя бы понять, с чем имеем дело

orignal потери пакетов

orignal ты не помнишь почему я эту хень с заврещением не починил?

Vort не знаю, могу только гадать

orignal похоже опять потому что был чем то занят а потом забыл

Vort надо особо вредные баги относить на GitHub, потому что и я умею забывать

Vort если не получилось за месяц починить, то пусть там висит (ну примерная идея, понятно)

Vort "<~orignal> потери пакетов" возможно. но ~10 секунд на то, чтобы 5 раз переотправить сообщения - это как-то дофига

Vort небось, проблемы с окнами и оценкой RTT

orignal наверное

orignal нууу у тебя память лучше ты не такой старый дед ))

orignal закоммитил

Vort хорошо, но тестировать буду потом. сейчас буду продолжать наблюдения за рандомизированным дропом

onon На локалхосте тестируешь? Без эмуляции задержек и случайных дропов, как в реальной сети?

Vort я сейчас просто смотрю на параметры транзита на реальном узле в реальной сети

Vort и пытаюсь найти случаи, похожие на успешное регулирование нагрузки

orignal я счас сам запущу

pinter бегом никто не занимается?

pinter недорогие беговые кроссовки можно купить в рф?

pinter в дешевых кедах наверное суставы убью

pinter бля сорян, не перепутал с ru)

onon Ты комнатой не ошибся?