Anonymous
lol tz
Anonymous
classical rookie mistakes, I have had many of those myself
onon
Поэтому явароутер никогда и не будет быстрым, если не поменяет архитектуру
onon
У нас стандартная задержка на 6 хопах 1200мс
orignal
ты ппробовал тот параметр менять?
onon
Т.е. чтобы слать хотя бы 1 МБ/с нужно чтобы "в полёте" были одновременно 1200 пакетов
onon
В обычных сетях, конечно есть автосогласование буфера
onon
Его конечно нужно менять
onon
И мой код даже в общем позволяет хоть и не идеально но обработать ситуацию, когда мы налили в канал 3000 пакетов, а получили аск только на 2
orignal
а почему только 2?
onon
Потому что 2998 потеряли
orignal
ну так потому что сеть дропает
onon
Это я образно, вот мой третий тест завис на значениях m_SentPackets=3300 ackThrough=179282 nackCount=255 mindow=411
onon
и я пытаюсь переотправить 177673
onon
Но аска не получаю
onon
Последняя скрость была как раз около 1 мб/с
onon
И я за 3 rtt ожидания ответа, кспел налить в сеть 3к пакетов
onon
Потому что окно было около 1000
onon
Если бы клиент мне подтвердил получение 177673, я бы начал их переотправлять с этого места
onon
Но он постоянно отвечает ackThrough=179282 nackCount=255
orignal
ну а как ты предлагаешь отвечать?
onon1
Ну как дед сказал
orignal
так я так и делаю
orignal
отвечаю только старым
orignal
а ну понял
orignal
гляну в коде
onon1
С явой такая же херня. Она мне подтвердила пакет, который не получила.
onon
nackCount=1 а у меня в отправленных таких нет.
onon
Ну или на нашей стороне как-то неправильно обработался аск/наск
onon
Но 1 мб/с она таки смогла.
orignal
возможно что неправильно
onon
Вот сейчас поймал странную ситуацию. Ява роутер разогнал, и после обрыва связи он мне сообщает ackThrough=24238 nackCount=1 Packet 23851 NACK.
onon
Я пытаюсь делать resend 23851, на что он мне отвечает ackThrough=24238 nackCount=1 Packet 23851 NACK и так и висит стрим.
onon
Так что у явы похоже тоже с логикой что-то не то.
Vort
"<~orignal> вот такая логика" так куда поставится ackThrough в случае 1 - 500 - 1 ?
Vort
"<~orignal> ответ деда" - я считаю, что в i2pd дропать не надо, но делать вид, что свежих пакетов не было - надо
Vort
"<onon> Так что у явы похоже тоже с логикой что-то не то." - я так и думал - ни в i2pd ни в java быстрых стримов не было, поэтому не было и мотивации писать код с качественной поддержкой граничных случаев
Vort
отладить проблему, кстати, скорее всего, можно, искусственно занизив лимит на nack`и. поставить максимум не 256, а 4, допустим
Vort
если проблема таки в этом месте, то "дублей" насыпется дофига
Vort
точнее, не дублей, а неверно подтверждённых. проявления этого бага будут, в общем
X400
че за вакханалия в #ru
onon
Лось, выдай мне банхаммер.
X400
и как это поможет?
onon
Мут на канал дам
onon
И войс не только лишь всем
X400
так не интересно
X400
временно можно фильтрануть его в weechat /filter addreplace spam irc.ilita.#ru * ^http://r4sas.i2p/fuck-yandex.i2p *
X400
длину ников по хорошему тоже сделать рандомной, сообщение тоже рандомной длины и сами сообщения я бы сделал большими, символов по 500
orignal
говорю же это бесполезно
orignal
плаз придурок
hypn__
плаз теперь в KFC жарщиком пашет и тут редко
Guest44815
да
Guest44815
это кто-то другой
Vort
orignal: сможешь на мой вопрос про ackThrough ответить? надо понять, есть баг или нету бага. потом думать, что делать дальше
X400
ну в libera.chat он бы так смог?
orignal
погоди
orignal
так в чем вопрос то?
orignal
если после 1 сразу приходит 500 то ставим только 1
Vort
вопрос в том, как сейчас i2pd себя ведёт в ситуации 1 - 500 - 1
Vort
пошлёт ли он хоть какие-то nack?
Vort
и куда поставит ackThrough
orignal
вроде по коду поставит 1
Vort
а nack отправит?
orignal
нет
onon
Так может это мы их неправильно обрабатываем?
orignal
будет нулевом
orignal
но может там и бага
onon
И отмечаем полученным что-то не то
orignal
я еще не разобрался
orignal
возможно
orignal
там багов море
Vort
onon: давай разберём мой кейс до конца вначале
onon
Потому что я писал, что с явой возникла такая же проблема
orignal
Vort посмотри код SendQuickAck
orignal
там все ж понятно
Vort
так хреново понимаю, что там
Vort
m_LastReceivedSequenceNumber - это номер последнего пакета в блоке принятых без дырок (без nack`ов) пакетов?
Vort
допустим, приняли номер 1, не приняли 2..501, приняли 502
Vort
m_LastReceivedSequenceNumber будет = 1 ?
orignal
да
orignal
именно так
orignal
а 502 уйдет в сохраненные
Vort
auto nextSeqn = m_LastReceivedSequenceNumber + 1;
Vort
nextSeqn получается равным 2 ?
orignal
ну да
orignal
начинаем искать с 2
Vort
а дальше htobe32buf (packet + 12, nextSeqn); // change ack Through
Vort
получается ackThrough 2 похоже
orignal
возможно бага
orignal
я это видел но не было времени разобраться почему я так сделал
hypn__
<hypn__> я иссуй50 в и2пд-андроид ковыряю
hypn__
<hypn__> там jni выбрасываю и запускаю чисто процесс i2pd
hypn__
без jni надо, через официальные tcp api
orignal
поправил
Vort
я так и подумал :) en.wikipedia.org/wiki/Off-by-one_error
Vort
onon1: перетестируешь с последним коммитом?
onon1
Немного занят пока, поставил только на пересборку, чуть позже погоняю, отпишусь.
Guest42191
ок
orignal
ну так все как всегда ))