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

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