onon
Ну так если бы это были единичные перестановки, я бы и внимания не обратил. Там были сотни насков, и счетчик увеличивался с каджым аском, вплоть до полного заполнения 255.
onon
И у меня как-то логика начинала криво работать, и стрим тормозил.
orignal
хочешь сказать в SSU2 с аками бага?
orignal
ну давай разбираться
onon
SSU умеет менять seqn в нумерации стримовых пакетов? Или я чего не понял?
onon1
Похоже вы мне обычный реордеринг пытаетесь выдать за причину.
onon
Попытаюсь сформулировать ещё раз я отправляю seqn 1000 получаю ack 1000 и nackcount=18, отправляю seqn 1001 получаю ack 1001 и nackcount=18 и так далее. Что там в наках не знаю, логов нет. Но получается на эти 18 пакетов я ранее получил ackи раз их нет в отправленны
onon
Ну вот в 42:53 я получаю ackThrough=89133 nackCount=173 потом я переотправляю неподтверждённые пакеты, количество nackCount уменьшается, последний ackThrough=89133 nackCount=89 получаю в 44:40
onon
И дальше уже в 44:44 идёт ackThrough=89700 nackCount=254 и там в списке nack'ов идёт 89133
onon
Ну и до принудительной остановки стрима в 46:55 он с другим таким же потеряшкой висят в списке nackCount, а все остальные нормально отправляются и подтверждаются.
onon
На клиентской стороне данные наверх естественно не отдаются из-за двух пропущенных пакетов
onon
Через некоторое время такой стрим принудительно закрывается, похоже что клиентской стороной
onon
Это происходит во время смены туннелей, предположу что функция updateleaseset делает quickack и тем самым подтверждает не полученные пакеты, но разбираться пока желания нет.
Vort|2
"<onon1> Похоже вы мне обычный реордеринг пытаетесь выдать за причину." - потому, что это соответствует описанию проблемы (nack без пакета)
Vort
возможно, причин несколько, в таком случае нужно с более подробным описанием уже работать
Vort
"<onon> Ну вот в 42:53 я получаю ackThrough=89133", "ackThrough=89700 nackCount=254 и там в списке nack'ов идёт 89133" - вот это похоже на более точное описание проблемы
Vort
ackThrough означает, что пакет уже был принят. отказаться от этого заявления уже нельзя
Vort
nack же пытается отказаться
Vort
подозреваю, что ветка кода с 256 nack`ами ("// change ack Through") может быть плохо протестирована
Vort
нашёл, где в коде лизсеты обновляются: github.com/PurpleI2P/i2pd/blob/835c48026906bd0ce32f310d6e1cc0db1cbb4987/libi2pd/ECIESX25519AEADRatchetSession.cpp#L872-L884
Vort
вот туда надо логирование дотыкивать чтобы понять где проблема
Vort
нашёл кое что странное в коде: github.com/PurpleI2P/i2pd/blob/835c48026906bd0ce32f310d6e1cc0db1cbb4987/libi2pd/Streaming.cpp#L1075
Vort
ну NonConfirmed и что? допустим, только что отправлен был
Vort
может, там надо LEASET_CONFIRMATION_TIMEOUT проверять, а потом только туннели сбрасывать ?
Vort
onon: хочешь попробовать добавить туда проверку по аналогии с вот этой? github.com/PurpleI2P/i2pd/blob/835c48026906bd0ce32f310d6e1cc0db1cbb4987/libi2pd/Streaming.cpp#L953
Vort
кстати, если в этом месте действительно проблема, то становится понятно, почему она в IRC проявляется реже - меньше пакетов - меньше ack-ов, больше шансов успеть с подтверждением лизсета
Anonymous
Vort: OpenBSD has ktrace included in base install which is similar to valgrind and maybe even dbg or whatever it's called
Anonymous
c trace system calls
Anonymous
i trace I/O
Anonymous
n trace namei translations
Vort
Anonymous: you keep trying to do anything except what is needed
Anonymous
Not really, I'm getting there, I can't use computers as you can, but I'm slowly getting there
Anonymous
I though ktrace might be good for development
Anonymous
for debugging
Vort
I'm talking about approach. You need to do X, but you are trying to do Y and Z instead
Anonymous
I'm just postponing X because I don't have eye-time, I'm doing X slowly
orignal
да SSU2 может отослать стримнговые пакеты в другом порядке
Vort
orignal: проверь, пожалуйста, Streaming.cpp строку 1075. суть сомнений я описал выше
orignal
ну смотрю
Vort
должна ли там быть проверка LEASET_CONFIRMATION_TIMEOUT и если нет, то почему?
orignal
должна конечно
orignal
почему нету? ну потому что как всегда
Vort
так может это и есть тот баг, о котором onon говорит уже наверно неделю?
orignal
"хуяк хуяк и продакшен"
orignal
так я не понял о чем он говорит
orignal
он внятно не смог объявнить
Vort
ну можно просто починить эту проблему (только хорошо убедиться, что это таки проблема) и пусть он перетестирует
Vort
если уйдут "его" симптомы, значит оно. если не уйдут - надо будет искать дальше
orignal
оно похоже вообще не используется
orignal
разобрался
orignal
попровил
orignal
давайте пробовать
Vort
хорошо. сейчас на основном узле тут в IRC просто потестирую
orignal
лучше пусть onon
orignal
у него же проблема
Vort
ну да, у него более нагруженные тесты. а я же просто проверю, чтобы ничего не сломалось
Vort
но когда бинарник соберётся
orignal
не ну сломаться то не сломается
onon
Сейчас соберу, потестирую.
onon
И это не у меня проблемы, это у вас проблемы.
orignal
ну так оно там годами
Vort
_симптомы_ проблемы у тебя; наиболее явные. а проблема в коде, понятное дело
orignal
и проблем в коде много
orignal
ну и как тесты?
onon
Обломался мой первый долгий тест из-за ошибочно подтверждённых пакетов.
onon
Пока вроде быстрее оживает после смены туннеля, но всё равно иногда висит по две минуты
onon
Но ещё ни разу не завис намертво
onon
Ну и смена туннеля из-за отсутствия ответа стала происходить реже, поэтому стрим дольше остаётся "разогнанным" пока по объёму переданных за единицу времени пакетов обгоняет предыдущие тесты.
onon
Вот только что на 5 минут завис, но ожил.
orignal
может там число надо поменять?
orignal
4 секунды счас
orignal
const int LEASESET_CONFIRMATION_TIMEOUT = 4000; // in milliseconds
orignal
я его имею ввиду
orignal
4 секунды это многовато
Vort
про ошибочно подтверждённые пакеты у меня есть подозрение
Vort
orignal: один и тот же seqn пакета в ack пакете не может же быть одновременно и nack и ackThrough ?
orignal
в SSU2?
Vort
в стримах
orignal
может конечно
orignal
скажем у тебя ackTrough 10 а nack 5
orignal
то есть подвреждение всех пакетов до 10 ого исключая 5
Vort
я имею в виду nack 8 9 10 ackThrough 10
Vort
такого быть не должно?
orignal
нет конечно
orignal
должно быть ackTrough 7
orignal
без всяких nack
Vort
тогда мне интересно, как i2pd обрабатывает ситуацию "1 подтверждённый, 500 неподтверждённых, 1 подтверждённый"
Vort
учитывая что лимит на nack`и 256 штук
orignal
интересный вопрос
orignal
думаю никак
Vort
ну вот и у меня сомнения
Vort
там какой-то код есть
Vort
но правильно ли он работает - большой вопрос
orignal
я думаю вываливает пачку nack -ов
Vort
orignal: так нельзя же 500 nack`ов разбить на два куска
Vort
так как в средину поставить ackTrough не получится
Vort
единственное что можно - это не слать их вообще. ну если я правильно понял
Vort
то есть, если алгоритм таки шлёт nack`и, то он ставит ackThrough куда-то не туда
Vort
вполне вероятно что поверх на nack
Vort
собственно, почему я свой изначальный вопрос и задал
orignal
возможно
orignal
надо смотреть по коду
orignal
if (numNacks + (seqn - nextSeqn) >= 256)
orignal
htobe32buf (packet + 12, nextSeqn); // change ack Through
orignal
и ниебет
orignal
вот такая логика
orignal
у деда спросил что они делают
orignal
<zzz> 2) if it does happen, we will drop #500, and ack 1, and pretend we didn't receive 500, because our receive buffer is 128 messages max, so we don't have "room" for a message 499 ahead
orignal
ответ деда
tz
yo, im having a small problem with the sam protocol. my setup is just a generic server tunnel + netcat listener to catch the message and sam enabled for my test app. the app uses i2p-rs, a rust sam library. now, when i intercept the traffic between my app and i2p, it looks ok to me, no issue, heres the truncated traffic:
tz
From CLIENT [3]:
tz
00000000 7e 4b 6c 50 31 42 6d 41 5a 45 59 72 65 6e 7a 6d |~KlP1BmAZEYrenzm|
tz
00000010 57 36 7e 4a 51 68 73 72 63 76 33 37 75 4c 75 35 |W6~JQhsrcv37uLu5|
tz
00000020 62 4e 62 47 30 4c 67 2d 42 51 41 45 41 41 63 41 |bNbG0Lg-BQAEAAcA|
tz
00000030 41 41 3d 3d 20 53 49 4c 45 4e 54 3d 66 61 6c 73 |AA== SILENT=fals|
tz
00000040 65 0a 0a |e..|
tz
From SERVER [3]:
tz
00000000 53 54 52 45 41 4d 20 53 54 41 54 55 53 20 52 45 |STREAM STATUS RE|
tz
00000010 53 55 4c 54 3d 4f 4b 0a |SULT=OK.|
tz
From CLIENT [3]:
tz
00000000 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 30 0d 0a |GET / HTTP/1.0..|
tz
00000010 0d 0a |..|
tz
now, the issue is on the other side, the server side, where netcet outputs the foloowing:
tz
nc -v -k -l 127.0.1.1 8888
tz
Listening on computer 8888
tz
Connection received on 127.140.89.183 58037
tz
nGET / HTTP/1.0
tz
any ideas where the "n" is coming from?
tz
it has to come somehwere from i2pd itself right?
orignal
no
orignal
i2pd knows nothing about payload
orignal
but it sends remote address first
orignal
before data
orignal
if not SILET
orignal
*SILENT
tz
thanks, found the issue. the library has a bug
tz
it appends one extra newline before sending the payload