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

Vort orignal: тут? можешь подсказать по поводу классификации i2pd-java ?

Vort вот этот вот RI: paste.i2pd.xyz/?a2f31587391708ee#4JtiVE8F1NzRhWd2dympZ5mJVAcLHi9gNnZNknZn6KGR

Vort он от java или от i2pd? по специфичному ключу можно сделать вывод, что java, по cost`ам и по "SSU2" - что i2pd. может юзер перенёс ключ с джавы в i2pd? или я что-то не понимаю

Vort ещё один пример: paste.i2pd.xyz/?0e55efabdb9cbfe3#2jkjgy3mXcLMYgPMUEcYpt1pvLE5sHV77jAv68CBzp1Z

orignal SSU2 бывает только в i2pd

orignal дед так его и не сделал

Vort orignal: почему ключ нетрадиционный есть идеи? может это ещё RI-клоны гуляют по сети?

orignal а что там с ключом? я еще не смотрел

orignal а главное с каким

Vort больбшим бинарным в начале файла

orignal и что с ним не так?

Vort ну периодичность

orignal ну

orignal так это нормально

Vort вроде ж разбирались, что это фича java

Vort или уже и в i2pd такое есть?

orignal давным давно есть

orignal смотри

orignal сам ключ то 32 байта

orignal остальное там паддинг

orignal потому и далается повторяющимся

orignal чтобы сжимался лучше

Vort так от чего зависит, будет он повторяющимся или не будет? вот в лично моём ri не повторяется. почему у кого-то с i2pd может повторяться?

orignal потому что у тебя router.info старый

Vort ага, понял

orignal сгенери новый и будет повторяться

Vort окей, спасибо

Vort две необычных особенности обнаружил

Vort первое уже замечал и раньше, но сейчас рассмотрел получше:

orignal *** алушает ***

Vort после перезапуска узла довольно сильно вырос TCSR. был около 15-20%, теперь 30-35%. аптайм - 6 часов

orignal ну это логично

Vort второе: за эти 6 часов я собрал статистику по фейлам туннелей. выбрал фейлы 3х хоповых и построил график. по графику получается, что i2pd туннели ломает чаще, чем java

orignal потому что там строятся совершенно новые тоннели

orignal а не отстраиваются старые

orignal а как i2pd в приципе может сломать тоннель

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

orignal только если линка дальше нет

orignal это в общем то единственная причина

Vort а если в транспорте где-то баг?

orignal то есть сообщение есть а дальше отправить не получается

orignal ну давай искать

Vort я тоже думал, что у i2pd нету фичи ломания туннелей

orignal но дджависты любят банить i2pd узла когда от них большой поток идет

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

Vort короч данные у меня пока что "мутноватые"

Vort надо ещё собирать и ещё думать

Vort пока что покажу промежуточный график (или диаграму - хз)

Vort paste.i2pd.xyz/?23d722b5436d69d8#DbEC8v6Uv2GUTbu5kWsBJdJELYFuap7ZcfbLhSzrasB5

Vort только первые два столбца более-менее надёжны

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

Vort видимо он считает по какой-то причине, что узел хороший и даёт ему приоритет

Vort а узел не такой уж и хороший по сути

orignal так говорю же нету этого в профилях еще

Vort ещё что странно. по одному из узлов

orignal не написал код

Vort почему-то всё время узел 1м хопом идёт

Vort сейчас сырые данные скину

orignal ну так очведино почему

orignal потому что с ним линк есть

Vort paste.i2pd.xyz/?f9690e78919d3dea#A5cdWgr6A33BCwfjo1yjdH125CNXEHdgAWeNLFoUn2fZ

Vort именно транспортный линк есть?

Vort а логический (с туннелями) глюченый?

Vort vHlxATOYBIVDorP-B-eHn3zsXe~GruZLj8ZzDKiWHJA=

Vort вот этот "пример"

Vort 7 фейлов на весь файл

orignal именно транспртнрый

orignal иначе чего бы он долюался

Vort ну и вот этот vHlx - это i2pd

Vort vHlx: 45.85.93.2:36702 ⇒ [4955683:29746289]

Vort ⇒ vHlx: 45.85.93.2:8792 [407:1508]

orignal может у него дальше не уходит

segfault orignal: я осознаю, что раскурить такой объемный проект, его функции, архитектуру, а потом написать код для бинарной иницилазации SOCKS5 мне слабо

segfault Есть что-то почитать по проекту?

orignal почитай статьи ацетона

orignal на хабре

segfault Ок.

segfault orignal: Кстати, как настроить i2pd, если я выхожу в интернет через SOCKS5 prxoy?

orignal Vort кстати может он просто отлуп дает а теряется дальше?

orignal никак

acetone segfault: это было в какой-то статье (вроде) и в видео (точно). Скорее всего видео про настройку i2pd на компе (Linux/Windows). ntcp2.proxy или что-то вроде такого параметр.

orignal потому что не сделано

orignal о чем и речь

orignal acetone проблема в том что выход через локальный тор не пашет

orignal потому что sock5 не сделан там

acetone orignal: занятно. Я уже не помню деталей, но на зоне у меня i2pd бегал через прокси-сервер в локальной сети. Правда, может быть я через HTTP-прокси его гонял, а не сокс

segfault Так получилось, что я в очень "демократичной" стране сейчас... Я сейчас чатюсь через ssh, которой проходит через прокси, где запущен i2pd и weechat.

orignal acetone старые версии тора работали через socks4

orignal новые перестали

segfault orignal: У тебя есть функции подписи и проверки подписи по ГОСТ Р 34.10-2012 на С?

orignal Gost.cpp

orignal считай там код на си

orignal обернутый в плюсовый класс

orignal поверх openssl сделано

segfault Я вдохновился статьей acetone про капчи без БД. Хочу попробовать. SHA256 это скучно. Хочу экзотики)

orignal ну вот возьми оттуда там все есть

segfault А без openssl можно? Это очень сомнительная зависимость.

orignal тебе придется написать свою реализацию жллиптической кривой

orignal я когда то написал свою реализацию 25519

segfault Функция ГОСТ Р 34.11-2012 (стрибог, которая) уже есть в интернете

segfault А вот для подписи -- нет

segfault origanl: а что значит "25519" ?

orignal так эллиптическая кривая как раз это подпись

orignal стрибог это хэш

orignal но похоже для тебя нет разницы

orignal 25519 это curve25519 кривая такая

orignal EdDSA и x25519

segfault origanl: > но похоже для тебя нет разницы

segfault В смысле нет?

segfault Я же говорю. Функции хэша есть.

segfault Функции подписи нет.

orignal ну тебе не повезло значит

orignal придется самому ))

relaybot 13trus: R4SAS тут? баннер сменить нужно

relaybot 13trus: R4SAS privatebin.i2p/?3a8b8a1dadeef60d#J5rd5HBK8xRXw4HJZFiVdJG3jDtePdbyhWsjc1sUYK7p

segfault Угу :(

Vort orignal: я, к сожалению, плохо понимаю, из чего фейл туннеля состоит. так что пока просто наблюдаю за данными

Vort кстати, набралось ещё данных и показатели i2pd и java почти выравнялись

Vort моё предсказание: как только через мой узел пройдёт жирный поток данных, упадёт TCSR и пропорция фейлов начнёт склоняться к java

Vort посмортим. если ничего не помешает

orignal думаб что да

Vort показатели, точнее, не совсем ровные. я пока не понимаю, что происходит. сейчас ещё картинку скину

Vort paste.i2pd.xyz/?6a58a68f9a218c53#9yZzVK7oo9WBoVRH1Jmu1CCJ8PSTxCm2z92cPmWohyX7

Vort на всякий случай пояснение: x - количество фейлов, y - распределение по типам узлов (проценты)

Vort конкретно эта картинка сделана чисто по 3х хоповым туннелям

Vort но данные собираются по 1, 2 и 3 хопам

Vort пурпурный цвет - i2pd, желтый - java

orignal это я догадался ))

Vort промежуточный вывод: за 9 часов аптайма узел имеет TCSR 30% и практически отсутствующую зависимость фейлов от типа узла

Vort paste.i2pd.xyz/?04dad09e999874d1#BfoUBz6R6h2fyd4CBkiwmBJLicQrLfnMd81fsTQ47om4

Vort кое-какая загадочность остаётся, но мне сейчас кажется, что она малозначительна

orignal типа узла первого или любого

orignal тогда вопрос второй

orignal фейл какого рода?

orignal код 30 или нет ответа?

Vort 1. я не различал первый-не первый

Vort 2. фейл такой, при котором туннель удаляется. сейчас закоммичу код

orignal это понятно

orignal но бывает 2 причины

orignal или мы получили отлуп явно или не получили ответа

orignal это более инетресно что происходит

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

orignal но джава к сожалению просто дропает

orignal если большой поток

Vort github.com/Vort/i2pd/commit/1981f1e64d92507132aecad14b059b4930d4429e

Vort я логирую if (it.second.first->GetState () == eTunnelStateTestFailed) и if (it.second.second->GetState () == eTunnelStateTestFailed)

orignal так ты не постоение меряешь а тесты

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

orignal а сам говорит про TCSR

orignal а тогда TCSR причем?

Vort как я понимаю, если джава банит, то и при построении и при уже готовом туннеле. или нет?

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

orignal может в обоих случаях

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

Vort был же вопрос о том, что грубо говоря вся сеть перегружена

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

weko сеть не перегружена однако.

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

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

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

orignal конечно не перегружена

weko Vort: не знаю что ты хоченшь узнать, но мне кажется нужно мерять падение туннелей под нагрузкой трафиков. средние скорости и процент "сломанных" туннелей для i2pd-only туннелей и java-only туннелей

Vort ну я понимаю юзер может узел перегрузить. но не 10 раз в день же

orignal фейлы происходит потому что у кого то гнапример UDP лагает

orignal и SSU2 линк теряет пакеты

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

orignal такие потери UDP что по телефону было говорить невозможно

weko это локальная проблема и далеко не у всех она есть

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

weko подобные ситуации статистически должны быть в одинаковом процентном соотшение и у java и у i2pd

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

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

orignal фейлятся ли они из-за ошибки или из-за того что нет ответа

Vort понятно, надо будет и туда логирование втыкать

Vort но пока что подожду пока у меня TCSR упадёт и посмотрю, есть ли связь с фейлами "посредине"

orignal и более понятно

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

weko при создании код 30 это норма

Vort это когда узел в лимит упирается?

weko условно говоря при профилировании можно так делать: -1 балл если код 30, -3 балла если без ответа и -10 баллов если туннель сломан во время работы

orignal weko код 30 норма но результат то же

orignal -1 если код 30 и ны выставил E

weko наверное даже так

weko есть над чем подумать

Vort а народ то обновляется понемногу

orignal для того же и придумали E

weko тут важно насколько часто узел кидает 30

orignal чтобы не нарываться на 30 без нужды

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

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

weko orignal: ну лучше просто E роутеры реже использовать, чем вообще не использовать

weko или какой там код

weko E, D

Vort weko: смотря сколько их

Vort если несколько процентов, то лучше вообще не трогать

Vort если половина, тогда да, надо рандом применять

weko кстати да тоже хорошее замечание

weko частота использования E роутеров должна зависеть от того, сколько у нас таковых в базе

orignal это про D

weko чтобы слабые узлы грузились в последную очередь

orignal насчет E там однозначно не слдует в течение 10 минут

weko Vort: хотя думаю нет. не нужно менять. она сама по себе увеличиться профилированием

weko узлы без E будут чаще кидать 30, и мы будем чаще использовать E узлы

weko ну или D

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

Vort то есть, он фоново говняный. когда атака - ещё говнянее. когда баны - тоже говнянее

Vort и это условно 3 разных проблемы

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

user На андроиде, на мобильном интернете, с неправильно выставленным конфигом и под атакой. Комбо.

orignal Vort кстати да еще вариант с фейлами

orignal что народ с андроида сидит

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

weko Vort: я вообше считаю что смотреть на TCSR нужно в последнюю очередь

orignal вывод: надо таки публиковать D там

weko orignal: скорее само ведро закрывают

weko закрывает*

orignal тоже возможно

orignal так что D это выход

Vort orignal: не 10 раз в день

orignal а почему нет?

Vort а вот если ОС чудит - это другое дело

orignal остановил/запустил

Vort и ждать каждый раз пока туннели построятся?

orignal так они вообще не думают

Vort :)

orignal если бы ты читал нв группу то знал бы что они делают

orignal запускают i2pd запускают браузер и тут же ломатся на нв пока не просрется

orignal потом все закрывают

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

Vort я даже не догадался ещё что такое "нв" )

orignal nvspc.i2p

orignal площадка

weko orignal: и вообще я думаю может сделать возможность сделать туннели подольше? минут 20 например.

Vort сомневаюсь что это поможет

weko в данной ситуации - нет

weko в перспективе - да, так как хороший туннель будет жить дольше

weko а плохой должен отсеиваться как можно раньше

orignal вообще то счас 11 минут реально

weko да понятно

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

weko orignal: в чём преимущество от них?

orignal и тогда если сам узел уходит в даун или сосед не отвечает то сразу сообщать

orignal в том что всегда можно отослать сообщение концу тоннеля будет

Vort второй канал не для данных, а для метаданных?

orignal для одноправленных только для входящих

weko так участник не сможет этого знать. и есть вероянтость что сообщить не сможет

orignal почему? данные ходят в обе стороны

weko orignal: дли исходящих тоже можно

orignal ну и что с этим сообщением сделает OBEP?

weko пришлёт на наш туннель

orignal надо же чтобы оно достигло владельца

weko входящий

orignal ты не понял о чем я

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

orignal я пошлю сообщение зашифровав своим layer key по тоннелю

orignal в итоге оно дойдет до владельца частично зашифрованным

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

weko ну да он поймёт что от транзита и будет знать от какого

orignal но это только для входящих

weko для исходящий будет OBEP слать в туннель владельца

weko не?

orignal для исходящего оно дойдет только до OBEP

orignal а откуда он этот тоннель возьмет?

weko так владелец ему и скажет

weko уже говорит

weko но можно и нужно обновлять

orignal тот что в момент построения был уже протух

weko ну значит обновлять

orignal разве что так

Vort у меня такое ощущение, что фейлы из-за рестартов - это незначительный процент. скорее, виноваты или потери пакетов (перегруз физической сети) или где-то баг

weko Vort: скорее баг

orignal ну и в чем состоит баг?

weko да вообще я не согласен что щас это большая проблема

weko щас проблема скорее в трафике

weko что потенциал есть а скорости нет

Vort weko: происходит непонятная хрень. это всегда проблема

weko тоесть сеть не нагружается на полную

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

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

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

orignal так у нас в тестовой сети скорости нормальные

weko orignal: сколько?

orignal когда у меня и R4SAS-а только

Vort weko: я думаю, что нужны методы для того, чтобы гонять данные по чётко определённой цепочке узлов

weko Vort: ага

orignal 20 мбс без проблем перло

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

orignal больше просто не пробовали

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

weko Vort: думаю может сделать какой протокол чтобы статистику в "live" режиме слать, а дальше кто захочет будет писать свои программы для анализа. но ещё нужны наверняка какие то модификациии....

weko потому и была затея на питоне роутер сделать ))

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

weko чтобы можно было всякие штуки тестировать с профилированием и отладкой

Vort а как баг выловлен, то специфичная статистика уже не особо и нужна

Vort ну то есть, оно то в целом может и надо такое сделать

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

Vort и зараннее неизвестно, какие

weko Vort: может это и не совсем верно, но как мне кажется текущая архитектура i2pd плохо подходит под эксперементы. либо я тупой))

Vort ну вот я логирование фейлов добавил наверно минут за 20

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

weko но с другой стороны это просто логирование

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

weko поэтому предлагаю начать с того, что понять количество узлов с низкой скоростью трафика

weko ну или хотя бы статистику

Vort weko: хочешь понять насколько соответствуют "буквы" реальности?

weko толчнее лучше статистку

weko Vort: буквы можно будет потом соотнести. но интереснее соотнести с типом роутера

weko ну и в принципи понять количественно

Vort можно ведь "петлю" сделать 1 + 0 хопов? то есть, качать данные по цепочке свой узел->тестовый узел-> свой узел ?

Vort просто если брать 3+3 хопа, хрен что поймешь

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

weko если таких много и кореляции с реализацией нету - значит либо баг и там и там, либо ещё какая то причина

Vort вопрос в том, что ожидать. упор в свою "букву"? ну если не X

Vort так i2pd "буквы" только так пробивает. а java я думаю этого делать не будет. вот тебе и корреляция. даже тестировать не надо

weko Vort: можно конечно. так будет быстрее всего выявить. но и при этом будет проверяться 1 узел за раз, вместо 6. при 6 статистически выявить можно, а потом если верхнуюю планку узла не сможем найти - значит нужно проверить на 0-1

Vort weko: кстати, помнишь же о связи скорости и пинга? я вот только не пойму, как оно работает при нескольких хопах

weko Vort: я тож ХЗ

weko давай сформулирую проблему

Vort ты лучше скажи, какая скорость - это нормально, а какая - не нормально

Vort собрать данные то можно. но как понять по ним - всё нормально или есть проблемы?

weko ну меньше 1 мбит - мало, больше - хорошо

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

Vort weko: то есть, предлагешь L вообще не тестировать?

weko надо среднюю найти и от неё плясать

weko смотреть разброс

weko Vort: L этож не лимит на один туннель. это лимит когда перестаются новые туннели приниматься

Vort это в i2pd так. а в java я думал, что не так

Vort я думал, что это общий лимит на все туннели

weko на туннель в протоколе лимита нету

Vort на сумму скоростей по всем туннелям я имею в виду

Vort ну и это не в протоколе, а в реализации

weko да понятно

weko удалить лишнее из статистики всегда же можно

weko главное - собрать

weko нужно смотреть в статиске на узлы, которые заявляют себя как быстрые

Vort ну то есть, можно узнать какая средняя скорость у X узлов

weko ну например

Vort и поймём что ожидать от среднестатистического X узла

weko узнаем насколько много узлов ниже среднего

weko соотнесём с реализацией

weko как я писал

weko вдруг проблема в i2pd?

weko просто опять же java должна же давать полную скорость когда есть ресурсы

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

weko и в таком случае решение - профилирование

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

weko Vort: понимаешь, хочется знать фактические данные а не догадки "java виновата"

orignal да запросто

weko Vort: вот я щас пишу формулировку

weko Проблема: малая средняя скорость, при том что некоторые туннели работают сильно быстрее других. Потенциал есть, а использования нет (почти уверен, что большинство узлов нагружено далеко не на 100%)

weko Возможные причины:

weko 1) плохое профилирование

weko 2) слишком большое количество плохих узлов (не решается профилированием)

weko 3) баг/проблема в java i2p

weko 4) баг/проблема в i2pd

weko Vort: вот твой узел на 100% нагружен по трафику или CPU?

weko мой вот нет

weko а если бы всё работало правильно, сеть старалась бы выжимать максимум ресурсов с меня, потому что потребность явно выше чем текущие скорости

Vort мой узел сейчас "заклинило" на 500 килобайтах/сек

weko вот. а лимит у тебя 2000 вроде

Vort такое ощущение, что это не данные юзеров, а какой-то служебный фон

Vort лимит у меня 6 мегабайт/сек

weko а ну вот даже так

Vort weko: по поводу разброса скоростей: тут ещё важно, 1 хоп или 3

weko и сколько вот таких узлов стоит без нагрузки пока те кто качает что-то сидят на <1mbit/s

weko нам нужно это узнать

Vort на 3х хопах разброс будет просто потому что иначе быть не может

Vort а вот если и на 1 хопе большой разброс - тогда загадка

weko пока есть N узлов которые гарантированно могут дать больше

weko и нужно узнать это число N

Vort достаточно одного "тормоза" в цепочке из 3+3 узлов - и тормозить будет вся цепочка

weko верно

weko поэтому статистически легко составить картинку

segfault Надо потестить локально

segfault Взять 20 виртуальных машин

segfault И посмотреть, как оно будет работать с i2p, i2pd

orignal у болгарина такое было

segfault Это кто?

orignal пока крышей не съехал

orignal zlatinb

user А можно как-то по белым спискам работать? Т.е. заставить подключаться только к проверенным скоростным узлам?

user В экспериментальных целях, конечно.

orignal угу

orignal есть параметр у тоннеля такой

orignal explicitPeers=

orignal и да идея сделать белые списки была

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

orignal чтобы они соединялись только с теми с кем связь есть

segfault orignal: а ты socks5 додел что ли?

segfault github.com/PurpleI2P/i2pd/issues/1598

segfault А это можно сделать?

segfault Это вроде просто

segfault Просто проврить, если этот b32 в std::set перед подключением

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

orignal мне просто лень

segfault Я попробую?

orignal попробуй

orignal только имей ввиду что надо и входящшие проверять

segfault угу

segfault а проверку ip отсавим на iptables?

orignal это отдельная тема

orignal тоже по уму надо