~AreEnn_
~R4SAS
~acetone
~orignal
~villain
@onon
&N00B
+Xeha
CreateEnergyDecreaseEntropy
DsecT
Guest98878
Hypnosis
KabaOS
Most
Nos4-Group
Opax
SOS
ahiru
ananas
anontor
avele
ch
duanin2
entity
equinoxe
fidoid
ice_juice
justaperson
karamba_i2p
laugh4me
lilith
luvme
mareki2p
n1
nissarmeows
pinotto
poriori
profetikla
ps
qend
rumpelstilzchen
shaye
sonya
tensor
un
urist_
vade
void
плаZскуф
orignal
что думаете по поводу увеличения числа тагов в тагсете до 16K?
onon
Наверное частая смена тагсета сделана для затруднения взлома шифра?
orignal
а x3
onon
Надо у деда спросить =)
orignal
тут главное чтобы новый тагсет согласовался раньше чем в старом дойет до 64K
orignal
а дед ответит что у сигнала так ))
orignal
и что он не помнит уже почему
onon1
Разобрался почему иногда на коротких туннелях стримы очень плохо работают
orignal
и почему?
onon1
На клиенте RTT рассчитывается только один раз в начале. И если он посчитался неправильно и получился слишком большим возникает проблема
onon1
Получается что на клиенте RTT/10 > RTO на сервере
onon1
И постоянно ретрансмит срабатывает
orignal
и что делать?
orignal
именно так
orignal
я это тоже видел
onon1
Нужно как-то пересчитывать RTT на клиенте
onon1
Слать на сервер что-нибудь, чтобы он отвечал
onon1
Или может на уровне сессии можно что вымутить
onon1
routingPath->rtt это что такое?
onon1
m_RoutingSession->GetSharedRoutingPath ()->rtt
orignal
это просто сохраняет с других стримов
onon1
А, понятно
orignal
сессия не даст точное число а
onon1
Насколько неточное
orignal
вот что даст так это флаг PACKET_FLAG_DELAY_REQUESTED
orignal
с нулем
orignal
ну смотри ты посылаешь пакет ack request
onon1
Если RTT будет +10% то ничего страшного
orignal
так сторона получит но просто пример к сведению
onon1
Проблема когда он в несколько раз больше
orignal
но ответ придет только тогда когда кто то пошлет
orignal
а он x3 когда пошелт
onon1
Как в ирке например?
orignal
нет когда стрим соизволит отправить акк
orignal
на той стороне
orignal
а вот если послать DELAY_REQUEST с нулем
onon1
Ну так акк максимум через 1/10 RTT
orignal
тогда та сторона будет обяазна страз ответить аком
orignal
и мы узнаем точный RTT
onon1
Так нам не надо точный
orignal
если хочешь я на уровне сессии добавлю подсчет RTT
onon1
Логику объясни, как это будет работать
orignal
ты говоришь сессии что надо бы послать акк реквест
orignal
посылаешь какой то пакет
orignal
сессиия записывает впемя
orignal
когда на этот пакет прилетел акк на уровне сесии
orignal
берется время снова и вычисляется разница
orignal
так обычно акк посылается только если ничего не приходит с той стороны в ответ
orignal
и мы думаем что у нас тоннели сдохли
orignal
но я могу сделать чтобы он отсылался принудительно
orignal
но по моему с DELAY_REQUESTD прошел
orignal
когда ничего не шлется от нас кроме акков
orignal
мы шлем такой пакет и немедленно прилетает ответ
onon1
акк реквест - это та штука, которая мне на каждый пакет лиз начинает менять?
orignal
нет
orignal
смотри
orignal
я добавлю в стрим метод RequestImmediateAck
orignal
ты когда надо его вызываешь
orignal
потом кода получаешь акк меряешь RTT
orignal
пойдет такой?
onon1
Сейчас подумаю, когда его можно вызывать
orignal
пока думай если что вечером сделаю
onon1
Но это будет сразу палево наверное, что клиент на i2pd
orignal
да оно и так палево
onon1
Хотя мы уже и так логику отправки акков переделывали
orignal
так что пох
onon1
А как там у явы я даже не знаю
orignal
мы считаем что обе стороны i2pd
onon1
Можно запрашивать раз в 10 сек + рандом
onon1
И обработчик вставить куда-нибудь в получение пакета
onon1
Если нам ничего не шлют так и не будем запрашивать
orignal
если мы ничего не остылаем кроме аков то раз в 5 секунд + veriance
onon1
А получили пакет - проверяем таймер и запрашиваем если нужно
orignal
нет надо когда мы ничего не шлем полезного
orignal
на что нужен ответ
orignal
*** отошел ***
onon1
Если SendBuffer emty && SentPackets empty
orignal
ну типа да
onon1
Ок
orignal
короче я добавлю метод
onon1
А я потестирую