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

orignal реализовал choking как дед делает

orignal может const int MAX_WINDOW_SIZE = 128; поднять до 256 или хотя бы до 200?

onon А почему бы и нет.

orignal потому что число NACK-ов орграничено 256

onon А какая разница, пришлёт он нам аск 200 наск 2-199, или просто аск 1

orignal а x3

orignal ты пробовал с 256?

onon Я же тебе говорил, у меня в тестах окно больше тысячи

orignal я просто счас госткойн сихнонизировал и у меня упиралось в 128

orignal попробуй последнее

onon Потому что это искусственный лимит скорости

orignal это с времен диал апа идет

orignal да и подтверждения бы надо сделать как в SSU2

orignal с диапазонами

onon Нет, это просто вы взяли алгоритм, который не подходит под нашу сеть.

orignal я тут непримчем

orignal я думаю его взял jrandom

orignal в другую эпоху

onon Я же скидывал код, как примерно надо.

orignal ну это потом

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

onon Даже если 2500 поставишь, особо не заметишь разницы

orignal тогда оставим 128 ))

onon Только если хороший туннель поймаешь, через некоторое длительное время может и разгонишься до ~5мб/с

onon Просто у нас трафик в основном импульсный

onon На текущем cc мы не успеваем окно разогнать

orignal ну я радио гонять на 128 кбс

orignal койны стабильно много тянут

onon Ну так сделй хотя бы 256

onon Окно, это количество пакетов, которые "в полёте", т. е. отправлены и ещё не подтверждены.

onon Если у тебя RTT секунда

orignal занаю

onon Посчитай, какая скорость будет

orignal так понятное дело

onon максимум 256 пакетов в секунду

onon пакет вроде 1700

orignal примерно 400 килобайт

onon мту

onon Странно, в доках было про MTU

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

onon Да, это я путаюсь всё время.

onon Случаев с неправильно подтверждёнными пакетами пока не поймал, продолжаю гонять тесты.

Vort "<onon> На текущем cc мы не успеваем окно разогнать" - смотря какая нагрузка и смотря сколько хопов

Vort "<~orignal> меня интересут что будет счас если поставить максимальный размер в 256" - изредка будет выше скорость. но не вляпаемся ли так в лимит очереди на 500 пакетов у старых версий в транспортах?

Vort я понимаю, что там ещё и окно есть, но всё же

Vort учитывая информацию о глюках java при тестах с большим окном, то ещё и этот риск есть

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

Vort "<~orignal> реализовал choking как дед делает" - большое количество NACK`ов - это вполне congestion сигнал, так что логично. надо и этот параметр в регуляции учитывать

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

weko orignal: ты писал, что у джавистов проблема с тем, что у них то, что в Crypto.cpp реализовано на джаве, тоесть слишком медленное. Пока вопрос такой - что именно там? Особенные для i2p моменты или оптимизация?

orignal то же шифрование тоннельного сообщения чего стоит

weko На asm

orignal у меня да для интела

orignal но у низ понимаешь все это через JNI

orignal их реализация EdDSA и x25519 это вообще бред

orignal все эти кучи HKDF

weko Окей, а почему этого всего нету в openssl? Или в другой библиотеке?

weko Для чего этот код

orignal это все есть

orignal просто в openssl функции более общего назщначания

orignal а у нас в Crypto.cpp уже нужные именно нам

weko Понятно. А что тогда там можно запороть, чтоб было медленно?

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

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

orignal или же вызывается медленная реализация на джаве

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

universalpunk_ о, я бинарник executable под андроидом из апк запустил

universalpunk_ i2pd

universalpunk_ jni теперь не будет

universalpunk_ и должен жить вечно, как в InviZ Pro

universalpunk_ и не убиваться системой

universalpunk_ умаялся ковырять gradle

universalpunk_ как обычно

universalpunk_ теперь базовый UnixDaemon с обычным юниксовым main() запускается

universalpunk_ на андроиде

universalpunk_ готовлю PR

Guest3971 :~$ file i2pd/i2pd

Guest3971 i2pd/i2pd: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=*, with debug_info, not stripped

orignal так можно просто так его собрать на голом NDK

orignal есть же

universalpunk_ ну вот я в апк упаковал

universalpunk_ и запускаю из апк его

universalpunk_ и юзается именно поделие unknown'a

universalpunk_ а не старый jni .so

universalpunk_ в апк щас есть строчка

universalpunk_ Runtime.getRuntime().exec(new String[] {

universalpunk_ ctx.getApplicationInfo().nativeLibraryDir+"/libi2pd.so",

universalpunk_ "--datadir="+dataDir

universalpunk_ });

universalpunk_ это i2pd на самом деле

universalpunk_ просто переименован в .so

universalpunk_ иначе Gradle не хочет в апк пихать

universalpunk_ в InviZ Pro такой же трюк с переименованием

onon const int ROUTING_PATH_MAX_NUM_TIMES_USED = 100; // how many times might be used

onon Это что такое

orignal не помню

orignal оно вообще используется?

onon if (m_SharedRoutingPath->numTimesUsed >= ROUTING_PATH_MAX_NUM_TIMES_USED ||

onon !m_SharedRoutingPath->outboundTunnel->IsEstablished () ||

onon ts*1000LL > m_SharedRoutingPath->remoteLease->endDate ||

onon ts > m_SharedRoutingPath->updateTime + ROUTING_PATH_EXPIRATION_TIMEOUT)

onon m_SharedRoutingPath = nullptr;

orignal вижу

orignal ясен пень надо помнять на 1000 хотя бы

Vort|2 а RoutingPath меняется что ли где-то? он вроде пересоздаётся каждый раз с новым пингом

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

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

Vort прыжки SharedRoutingPath зануляют, а вот создают их только первые пакеты в стриме

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

Vort пропущенный по RTO ACK - это, хоть, и плохо, но не означает, что путь однозначно негоден

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

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

orignal все под одному пути

Vort но если один стрим глюканул, то он при прыжках по туннелям зачистит информацию о всех путях

Vort в основном, думаю о новом алгоритме (прыгательном), но и старый тоже имеет похожие свойства

orignal ну да есть такое дело

onon //using GarlicRoutingSessionPtr = std::shared_ptr<GarlicRoutingSession>;

onon typedef std::shared_ptr<GarlicRoutingSession> GarlicRoutingSessionPtr; // TODO: replace to using after switch to 4.8

onon Это что такое

orignal просто объявление типа

Vort en.cppreference.com/w/cpp/language/type_alias похоже

orignal да пох

orignal просто в старых gcc не было