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
просто объявление типа
orignal
да пох
orignal
просто в старых gcc не было