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

weko_ [19:52:36] <Vort> хорошо хоть код java опен сорс

weko_ Немного иронично. Потому что если бы i2p не был сводобным, то можно было бы подобный клиент сразу выкидывать на помойку

weko_ [17:24:24] <Vort> кстати, если кто хочет, то может попробовать два узла сделать на одном компе. один для транзита - флудфил и всё такое, а другой с минимальной нагрузкой - "для себя"

weko_ [17:24:37] <Vort> не уверен, что это хорошая идея, но на всяк случай написал

weko_ Плохая, так как второй будет иметь другой RI, и не будет иметь трафик. Хотя, я тут подумал: трафик - защита от тайминг атаки на стороне провайдера, а я сам без понятия, можно ли отличить разные RI на уровне провайдера, или только на уровне сети

weko_ [17:44:09] <orignal> Network status: Mesh

weko_ [17:44:09] <orignal> Tunnel creation success rate: 67%

weko_ Но там мало транзита вообще. Так что рейт выше от этого как минимум. Не знаю, какое влияние от mesh режима...

weko_ [11:38:57] <orignal> мне тут коспирологическая мысль в голову пришла

weko_ [11:39:40] <orignal> едва скорости в i2p становятся более или менее приличными джавовские узлы начинают банить транзит типа "атака"

weko_ [11:39:49] <orignal> совпадение? не думаю

weko_ Вопрос решается профилированием. Один раз и навсегда. Если джава специально так делает, то окажутся в бане, и не потому что джава - а потому что плохие узлы

weko_ [13:58:34] <ncop> Не знаю причин но то что иногда 2-4 недели скорость личных сервисов хорошая, но потом внезапно несколько месяцев скорости падают в 2-3 раза. И части при этом не вижу корреляцию с сообщениями об атаке. Может это и атаки

weko_ [13:58:34] <ncop> неустановленного типа, а может еще что.

weko_ [13:59:05] <ncop> И часто* при этом...

weko_ Личное наблюдение или есть график/статистика?

weko_ По поводу профилирования:

weko_ Сделать систему обязательств по скорости (примерно как я уже описывал), кто заявляет больше чем может - в бан (или в корректировку), пока не исправится.

weko_ А дальше по заданному уровню анонимности/качества пользователем выбирать первые N узлов из топа лучших узлов (уже отпрофилированных) и использовать для своих туннелей их

weko_ Уровень анонимности/качества: смысл в том, что чем больше узлов используется, тем выше анонимность, но тем больше плохих узлов, которые портят качество

weko_ Также профилирование должно фильтровать уже построенные туннели в реальном времени: перед использованием проверять, и постоянно (часто) тестировать туннели, которые используются сейчас. Дублирование по разным туннелям - вопрос спорный, но точно

weko_ поможем со стабильностью (не будет резких просадок, ведь хотя и проверка быстро обнаружит плохой туннель, посадка будет всё равно, а второй туннель может подменить. Вопрос только в скорости обнаружения проблемы)

weko_ Vort: как верно заметил ` : нужны лабораторные условия, в том числе без текущего профилировщика, чтобы видеть чистые данные "как есть". Собрать данные за, предположим, неделю, и дальше смотреть какие типы роутеров, с какими версиями влияют на tcsr,

weko_ стабильность и скорость

weko_ Тогда и можно будет сделать однозначные выводы

weko_ Ведь TCSR понизился - а значит что-то изменилось в какой-то реализации. Потому если увидим резкое изменение с какой-то версии, одной или возможно двух реализаций - это многое скажет

weko_ У меня подозрение, что это переход на ssu2 виноват. Но лишь подозрение

weko_ Можно сказать, что проще просто найти баг, или убедится, что его нет другим способом. Но: подобный инструмент упростит дальнейшие проверки на баги, позволит оценивать эффективность профилировщика (и улучшит его)

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

weko_ Да, согласен

weko_ Это нужно

weko_ Для того нужны чистые данные без него и данные с ним

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

ncop Личное наблюдение или есть график/статистика? - Наблюдение. Чтобы был график/статистика надо чтобы была построена система мониторинга(из нескольких роутеров и включающая много параметров), а также система очистки статистики,

ncop чтобы были учтены абсолютно факторы, например такие как 1) обновление версии i2pd, 2) обновление версии i2p Java, 3) доказанные атаки и ихвоздействие 4) приход/уход пользователей(всплеск торрентов, биткоин, дарк маркет и т.д.) 5) все

ncop манипуляции глобальных провайдеров влияющих на связность сетей в интернете. В общем сделать это невозможно в принципе. Когда то делали замеры и относительно достоверно фиксировали всплески транзита только при выходе целой

ncop пачки новых ожидаемых фильмов/сериалов на постмане.

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

orignal вчера деда спрашивал

orignal вот нахуя они все это лимитируют?

weko_ Ну на самом деле это отчасти оправдано

weko_ Вероятно они и правда специально

weko_ Но это защита от тайминг атак

weko_ Но нужна ли она, другой вопрос

weko_ И почему они решили за пользователя (вместо предоставления выбора) тоже другой вопрос

orignal вопрпос то не в этом

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

orignal что вообще оказывают влияние на нормальных потоках сравнимх с клирнеиовскими

weko_ Это они делают или "потому что"?)

orignal так дед вчера писал что у них да куча проверок

orignal и судя по нашим набдюдениям они низкие

weko_ Проверки это хорошо, но они должны быть согласованны и вообще иметь смысл, и главное - не вредить

weko_ Проверки на скорость?

weko_ Типо много транзита = ban?

orignal он сказал около десятка

orignal Vort до меня похоже дошло что происходит

Vort значит надо думать, как проверить гипотезу

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

orignal смотри

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

orignal и оно постоянно стоит

Vort да, иногда очень долго

Vort поэтому я про SSU2 и думал

orignal тот роутер в итоге забит под завязку

Vort может у него со временем крыша едет

orignal и он ставит E

orignal но мы этого не знаем и для первоого хопа продолжаем выбрать его

Vort так вроде же рассылаются обновлённые RI

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

orignal рассылаются

orignal но в соединениях у нас RI не хранится

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

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

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

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

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

orignal это как раз объясняет почему вначале рейт высокий а потом становитсч низким

orignal потому что мы первый хоп выбираем из существуюзих

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

Vort а таймауты это объясняет? у однохоповых кстати рейт около 95% был когда я измерял

Vort так что чинить оно хоть и надо, но, думаю, дело не в этом

orignal это только предположение

Vort orignal: и ещё одно: E узлов всего около 4% по всей netDb

orignal отличный вопрос

orignal надо спросить деда

orignal когда дропают они ставят E или нет?

orignal дед говорит что не всегда

` За 5 дней в среднем 50ГБ туды-сюды прогоняю, ожидал большего.

` А с другой стороны: "Да что вы такое качаете???"

orignal мало

` * в смысле каждый день по столько, но всё равно ожидал куда большего трафика

orignal а ну каждый день это нормально

Vort Uptime: 18 days, 15 hours, 41 minutes, 51 seconds

Vort Transit: 1087.61 GiB (577.54 KiB/s)

Vort так что может быть и больше

Vort (только дочитал, что речь о 50 GB в день. в таком случае совпадает)

whothefuckami 640 гб транзита за 4 дня

whothefuckami хехехе

whothefuckami Стоп что

whothefuckami По моему это слишком дохуя

whothefuckami А нет, нормально

whothefuckami В лимит интернета не упираюсь

orignal Transit: 2861.06 GiB (1912.99 KiB/s)

orignal за 2 недели