IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#dev
/2025/04/29
~AreEnn
~AreEnn_
~R4SAS
~acetone
~orignal
~villain
@onon
&N00B
+Xeha
GFW
Komap
Most2
Nikat
Opax
Vort
`
anon
b3t4f4c3
duck
grimreaper
iiii
karamba_i2p
meowking
not_bob_afk
osoznayka
poriori
profetikla
qend
r3medi7z
rc13
segfault
slfd
soos
spider
teeth
tensor
un
weko
whothefuckami
woodwose
orignal может быть сделать размер буфера для тоннеля конфигурируемым?
Vort самый лучший вариант - когда программа работает оптимально без дополнительных шаманств с конфигами
Vort стоит прикинуть, сколько обычно туннелей у юзера и сколько обычно RAM доступно
orignal ну давай тогда твои предложения
Vort если запас есть, то просто поднять чуть размер и всё
orignal мы читаем из сокета в некий буфер потом передаем его в стрим и стрим пытается отправить
orignal смотри
orignal если ты сделаешь буфер скажем мегабайт
orignal тогда это клиенсткое приложения будет с толку сбивать
Vort стрим будет хомячить данные и тупить с отправкой?
Vort тогда стоит прикинуть обычные размеры буферов у сокетов
Vort сейчас погуглю, не так давно с этим разбирались вроде
orignal или размер буфер должен считаться исходя из размера окна
Vort ну это понятно, самый лучший вариант. но самый рискованный
Vort может стоит вначале починить неравномерное наполнение? а там будет видно
Vort "<~orignal> тогда это клиенсткое приложения будет с толку сбивать" мегабайт может и собьёт с толку. а 64 килобайта, допустим?
orignal 64K тоже плохо потому и надо бы это менять
Vort погуглил про буферы и вспомнил что они динамические пока программист туда не полез с настройками
orignal а то клиентскио заполняет 64K думает что скорость высоквая
orignal заполнени то починю
orignal но мне не нравится что оно основано на размере буфера
Vort надо бы понять, от чего (мгновенный) размер буфера сокета зависит
Vort но я когда прошлый раз пытался понять, то нифига не вышло
Vort то есть, скорее всего, надо прорабатывать эту систему исходя из того, как именно работают сокеты
Vort поэтому и предлагаю вначале бесспорный (надеюсь) вопрос решить
orignal счас попробую
orignal вообще я рассматриваю модель что с сокета идет большой поток и затык на стримах
orignal то есть всякий раз когда мы читаем из сокета там что нибудь да есть
Vort если брать обычный сценарий, то, видимо, да. а так вообще есть же IRC и прочее
Vort но меня беспокоит кое что другое
Vort что от того, как именно мы читаем из сокета, может зависеть динамический размер буфера сокета в конкретный момент времени
Vort то есть, стоит попробовать решить заодно и проблему забивания буфера у сокета
Vort ведь если в сокет напиахалось 256 килобайт, то что там за буфер на стриме уже как бы примерно пофигу
orignal для ирка размер буфера без разницы
orignal не так
orignal мы считаем что можем читать из сокета сколь угодно быстро
orignal если нужно
orignal то есть это зависит только от нас
orignal читаем мы сокет или не читаем
orignal если не читаем тогда и набивается
orignal и счас мы не читаем пока предыдщие данные не отправили
orignal сделал
orignal буду пробовать
Vort тоже потестирую, просто на стабильность. давно не обновлялся
orignal может поломал чего
orignal если работать будет то и для сэма такую же логику запилю
qlkef PQ уже запилили?
orignal давно уже все работает
orignal если openssl 3.5 естественно
qlkef для активации что-то включать нужно?
orignal включаешь поддрежку тиап ширования 5 для дестинейшина
orignal и пробуешь с теми кто его поддерживает
orignal i2cp.leaseSetEncType=5,4
orignal вот так например
orignal вроде радио работает по новому алгоритму
qlkef i2cp.leaseSetEncType=5,4 это типа если роутер не поддерживает 5, то свалится на 4?
orignal типа да
orignal сначала пробует 5 а если нет то 4
qlkef ок