~AreEnn
~R4SAS
~orignal
~villain
&N00B
+relaybot
DUHOVKIN
Most2
Nausicaa
Vort
Xeha
`
acetone_
anon2
b3t4f4c3
flumental
karamba_i2p
nemiga
not_bob_afk
onon
plap
poriori_
profetikla
silence
soos
teeth
tensor
un
weko
whothefuckami
onon
Vort, это я конечно ошибся. paste.i2pd.xyz/?75a4860ffc3bcdac#DtM5qoD1wW4wnERmV14hGkqDvYD2wG2TVoxLhUNMyjtn
onon
Поймал странный баг, клиент шлёт мне nack а у меня в sentPackets такого seqn нет...
Vort
все отправки, приёмы, перепосылки, переносы из одного массива в другой вывести в лог - и ситауция станет понятной
Vort
клиент то тоже "свой"
Vort
это тот случай, когда багу некуда бежать :)
Vort
разве что логированием можно "спугнуть", но это тоже решается
onon2
Ну я его пока только два раза ловил, я пока другим занимаюсь, потом может разберусь.
Vort
это может, кстати, быть связано с зависанием запросов к java серверам
Vort
тоже надо будет когда-то погонять. я видел такое на сайте notbob
onon2
Ну он только в одном месте стирается из списка, m_SentPackets.erase (it++);
onon2
Может он как-то неправильно инкремент считает
Vort
традиционно, может быть проблема с многопоточностью, надо смотреть, из одного ли треда все функции доступа к объекту вызываются
onon2
std::round () в какую сторону округляет?
onon2
Нашёл
onon2
С этим багом с пропадающими пакетами разбираться пока желания нету, но на всякий случай скину сюда информацию.
onon2
Я получил аск с ackThrough 21131, удалил его у себя из m_SentPackets потом получил еще один аск 21131 вроде дубль, ничего не делал.
onon2
Потом пришёл аск с ackThrough 21133 и nackCount=1 но у меня в m_SentPackets того пакета который nack, уже не было.
onon2
Мне думается проблема на стороне клиента.
onon2
Ну или тут чего то не то удаляется m_SentPackets.erase (it++);
Vort
мысль наугад: может, пакеты (ack / nack) местами поменялись, SSU2 такое умеет
Vort
"того пакета который nack" - ну вот поэтому все seqn надо выводить в консоль. будет понятнее
onon2
Это надо переписывать код и сидеть конкретно этот баг ловить, говорю же, пока другим занимаюсь.
onon2
Но в туду лист запишу, может займусь потом.
Vort
так как чётко баг определяется - пришёл NACK, а пакета нету?
Vort
могу на локалхосте погонять
onon2
Ну да
onon2
Ты лучше новый CC для стримов погоняй
onon2
Я код скидывал
Vort
а ты проблему с RTO исправлял?
onon2
Что за проблема рто?
Vort
ну RTO - это же время, через которое идёт перепосылка, если не пришло ACK, верно?
onon2
Ну
onon2
А что за проблема была?
Vort
так вот в твоём коде (в прошлой версии) я на самом первом пакете при неудачном туннеле видел перепосылку через 3 * RTO вместо 1 * RTO
Vort
вот и спрашиваю - в новой версии исправлено или нет
onon2
Даже не знаю что сказать
onon2
Вот это ты проблему нашёл
onon2
Прям баг из багов
onon2
Ну я там сделал константу на ретрансмит в 6 сек, но не похоже чтобы это сильно улучшило ситуацию
Vort
когда в коде написано одно, а подразумевается другое - это довольно важная проблема
Vort
дело даже не столько в том, какое влияние на работу кода это оказывает
Vort
иногда две таких проблемы компенсируют друг друга и вообще видимого эффекта нету (это просто пример)
onon2
Не надо метать бисер перед свиньями, я всё равно не понимаю о чём ты.
Vort
но понимать и дорабатывать такой код - очень сложно
onon2
Я тебе и скинул, что бы ты саму логику понял, как нужно сделать, и сделал правильно.
Vort
"я всё равно не понимаю о чём ты" - о теоретическом смысле RTO и том, как этот термин используется в коде на самом деле
onon2
Так всё правильно там используется
Vort
перепосылка через 1 * RTO идёт?
onon2
Если за три РТО не получили ни однога аска - ретрансмит
onon2
А если получили наск - проверяем "старые" пакеты
onon2
Старые те которые больше РТО
Vort
поэтому я и задал вопрос "RTO - это же время, через которое идёт перепосылка, если не пришло ACK, верно?"
Vort
а в коде - 3 * RTO
onon2
Или я не правильно объясняю, или у тебя сложности.
onon2
Ты имеешь в виду, почему там написано 3*РТО а не 3*РТТ?
onon2
Ну так чтобы уменьшить влияние джиттера
onon2
Можешь написать туда 3*(РТТ+jitter)
Vort
вопрос в определении RTO. "RTO - это ****"
onon2
Будет то же самое но тебе понятнее будет
orignal
я кстати так и не понял в чем между ними разница
Vort
сейчас же получается "RTO - это место, где хранится какое-то значение, которое потом как-то где-то используется"
onon2
Всё правильно, используется в перепосылках, при проверке "втарости" пакета
Vort
"RTO - значение, которое используется при перепосылках. то так, то сяк"
onon2
Ну и да, то что у меня там названо джиттером, это не совсем джиттер
orignal
кстати я тут себе макось 12 поставил в виртуалбокс
onon2
На самом деле джиттер не так считается
orignal
так что след релиз соберу более новым шлангом
onon2
Ну и назови это как хочешь
onon2
Я сейчас ещё пару фильтров добавил, окно растянул, и он теперь может 1мб/сек через 6 хопов гнать с минимальным пингом.
orignal
а хопы то потянут это?
onon2
Ну он выжимает максимум, что дают.
onon2
Некоторые позволяют только около 20 кб/с он так и работает.
onon2
Хотя не правду написал, он на данный момент может максимум 1000 пакетов в секунду, даже если ему разрешат больше.
onon2
Всё потому что я не знаю как сделать boost::posix_time::milliseconds(1) меньше единицы
onon2
Но может быть пока и не нужно больше тысячи пакетов в секунду...
orignal
надо использовать boost::posix_time::microseconds
orignal
разве не лошично?
onon2
А надо больше одного мб/с на один стрим?
orignal
а чего нет то?
orignal
у меня в клирнете бывает и по 50 мегабайт в секунду файл качается
onon2
Ну я тогда как с фильтрами разберусь, попробую переписать, вроде должно быть не сложно.
orignal
ну я счас проверю твой код локально
orignal
у меня и клиент и сервер там
Vort
onon2: вопрос про RTO можно и по-другому переформулировать: через какой интервал времени должна идти перепосылка пакета? "через 3 * RTO"? "через 1 * RTO"? "иногда через 3 * RTO, иногда через 1 * RTO"? ещё какой-то вариант?
onon2
Ты спрашиваешь, чтобы получить ответ, или чтобы выебнуться?
onon2
Мне как-то похер, я хочу чтобы итупи быстро работал, а не пытаться писать правильный код, который не умею.
Vort
чтобы понять, соответствует ли идея кода (теория) практике (тому, что написано)
onon2
Идея в том, чтобы слать ретрансмиты только если получили наск
onon2
А через 3*РТО мы шлём по одному пакету что бы восстановить связь
Vort
получили nack - шлём через 1RTO, не получили - шлём через 3RTO. так что ли?
onon2
Потому что нам никто не отвечает
onon2
Вообще лучше через 2*RTO
Vort
ну общую мысль я правильно уловил?
onon2
Но с такими проблемами с лизсетами лучше туннель часто не менять
onon2
Правильно уловил
Vort
окей
Vort
и через 3RTO перепосылка уже в другой туннель пойдёт что ли?
Vort
подозреваю, что у этого алгоритма будут проблемы с редким ping-подобным обменом данными наподобие IRC
onon2
Ну да, если нам никто не ответил через 3 rtt подозреваем, что с туннелем что-то не так
Vort
один просранный пакет - и уже ищем новые туннели
onon2
не один а три
orignal
надо не три а тридцать
onon2
почему
Vort
гляну позже код получше, где там это "три" прописано
onon2
я бы сделал два
Vort
ещё одна проблема кстати (которую я толком не проверил) - новый код, похоже, будет пытаться отправить SYN полчаса
Vort
юзеры обычно столько не ждут
onon2
Ну и что, памяти вроде не ест
Vort
я думаю, больше 1-2 минуты ждать восстановления связи не стоит
onon2
Бывает и через пять минут у меня стрим оживает
onon2
Я же говорю какая-то херня с лизсетами
onon2
Или с чем-то ещё
Vort
"<onon2> не один а три" - всё же спрошу - где это указывается?
Vort
боюсь не найти в коде, лучше сразу спросить
onon2
Ну три аска не получили
Vort
так где это число прописано?
onon2
Нет такого числа
Vort
значит не три
Vort
а как получится
onon2
Ну и не один
Vort
если по стриму ничего не идёт несколько минут
Vort
а затем отправляется ровно 1 байт
Vort
если будет потеря - забракуется туннель
Vort
надо будет потом над этим подумать
onon2
Я же спрашивал, ты информацию хочешь или выебнуться, я подозреваю что второе
Vort
onon2: не хотелось, чтобы с какой-то из групп юзерских протоколов новый алгоритм работал хуже старого
Vort
паттерн "долго ничего не происходит, а потом отправляется один байт" - довольно распространён
Vort
не каждый стрим - это скачка файла. надо учитывать это при разработке алгоритма
Vort
ну и просить посмотреть алгоритм, а затем при появлении критики и просьб уточнений обвинять в выёбывании - неконструктивно
onon2
Я пока критики не увидел, а на все уточнения стараюсь отвечать подробно насколько могу.
onon2
А смена туннеля не должна вообще вызывать проблем с точки зрения архитектуры итупи
onon2
Если это создаёт проблемы, нужно не избегать таких ситуаций а пытаться исправить проблему с туннелями.
onon2
Но если ты считаешь, что будет лучше не менять туннель на первый таймаут - сделай так, как было с кейсами
Vort
дополнительные ресурсы сети расходуются - на поиск RI. может, это и мелочь, не знаю
onon2
У нас задача сделать двигатель для ракеты, а не уменьшать ракету под имеющийся двигатель.
Vort
я предполагаю, что вариант "с кейсами" был реализован не просто так, была какая-то причина сделать именно так
Vort
и прежде чем его выкидывать, лучше с этой причиной ознакомиться (порасспрашивать, к примеру, да)
Vort
может, он и плох. вполне допускаю. но это неочевидно
onon2
Там другой момент плох, что смена туннеля, по всей видимости, задевает другие стримы к этому же дестинейшену.
onon2
И так быть вообще не должно
onon2
Поэтому всё так плохо работает.
onon2
Т.е. алгоритм со сменой туннеля - сам по себе адекватный, но в текущей реализации это создаёт проблемы. Поэтому я не могу сказать что плохо а что хорошо.
proxy
пасха - закрыто всё, даже продуктовые
proxy
а, не сюда, сорян
Vort
onon: вопрос нагрузки на сеть обдумать надо независимо от других свойств
Vort
про другие стримы: у меня тоже подобное подозрение возникло когда я расспрашивал про работу GarlicRoutingPath
Vort
не хотел сейчас разводить это обсуждение, но, видимо, придётся. сейчас буду вопрос формулировать
Vort
orignal: допустим, отправляющая сторона имеет 5 хороших исходящих туннелей, принимающая сторона имеет 5 хороших входящих туннелей. всего получается 25 пар
Vort
позволяет ли сеть i2p одновременно отправить один и тот же пакет через все 25 пар и успешно получить ответы (в случае, если никаких помех этому не будет)?
Vort
имею в виду ситуацию с единственным активным стримом
orignal
пакет это что? Сообщение Data или Garlic?
Vort
такие, которые стримы делают. точно не знаю. SYN стримовый, допустим
orignal
тут как говорится две большие разницы
orignal
одно и то же Data несколько раз без проблем
orignal
второй Garlic пройдет потому что таг одноразовый
Vort
ок, SYN стрима как отправляется?
Vort
ну и не столь важна одинаковость. допустим, разные пакеты. seqn 1 в одну пару, seqn 2 во вторую пару и так далее
orignal
через выбранную пару
Vort
не помешает ли одна отправка другой?
orignal
или наугад или если уже есть то через нее
orignal
не помешает но как считать RTT?
Vort
я имел в виду вопрос "Data или Garlic" - не помню, что стримы шлют просто
orignal
стрим сначала делает Data потом оборачивает в Gralic
Vort
а, ну значит Garlic
orignal
ну он может быть только один
orignal
дважды ты его отправить то можешь
orignal
но второй не расщифруется
Vort
окей, значит проблем, о которых я думаю, в теории быть не должно
Vort
а вот что там на практике - надо разбираться
Vort
onon: в теории и если не учитывать нагрузку на сеть получается, что прыгать можно по туннелям сколько и как угодно и ничего при этом ломаться не должно
Vort
но я по структурам данных сомневался
Vort
там есть общие объекты для нескольких пар и они у меня вызывают сомнения
onon
Может они лизсеты помечают как плохие или что-то в этом роде
onon
Другие стримы имею в виду
onon
Вот у меня стрим завис, я открываю новый параллельный стрим и - чудо старый стрим оживает
Vort
говорю же, в коде есть объекты сессий и их надо хорошенько рассмотреть
onon
А новый стрим может берёт с флудфила
onon
А старые уже все протухли
Vort
но можно и просто "с нуля" погонять проблему
onon
а бывает наоборот стрим работает нормально, запускаешь ещё несколько, и всё ломается.
Vort
m_RoutingSession посмотри
Vort
я пока ещё не понял, как он работает, но смотрю на него с подозрением :)
onon
Не, я не разберусь. Мне придется код стримов из головы выгрузить.
Vort
"<onon> А новый стрим может берёт с флудфила" - надо разобраться, как вообще лизсеты обновляются. я пока что без понятия
onon
Я тебе давно говорил что это одна из самых противных проблем, и её решение должно быть в приоритете.
Vort
решил я опять сделать тесты с 3 узлами, половить nack проблему. а попал на лизсетовую хрень, похоже
Vort
отправка с узла 1 на узел 2 через узел 3
Vort
поставил запускаться узлы, отошёл. когда возвращаюсь - вижу, что 3 узел вывалил ошибку про занятый порт
Vort
закрываю ошибку, вижу что и 1 и 2 узлы смогли уже через 3 построить туннели
Vort
да вот только связи между 1 и 2 узлом не было и довольно долго
Vort
минут 5 наверно
Vort
похоже, раз лизсет сразу опубликоваться не смог, то последующие попытки были очень не сразу
Vort
ещё и тесты туннелей сфейлились. ппц. на локалхосте
Vort
и не один раз. вообще на 1 узле тесты перестали проходить
Vort
ещё и два стрима дохлых висят бесконечно
Vort
пытаюсь закрыть дохлые стримы - получаю сообщение Stream closed, но стрим остаётся на месте
Vort
конкретно я узел заглючил. не пойму только, как
Vort
возможно, в баг с часами вляпался. перезагружаю всю эту конструкцию
Vort
это я просто криво логирование NACK`ов сделал. ппц )
Vort
точнее, зависание - из-за кривого логирования. а вот почему связи не было - вопрос интересный
Vort
добавил вот такой код к версии из основной ветки: paste.i2pd.xyz/?6de4853285d8b0ce#8CEr6CPTAVP3BBX2XSDb5Ne1Zqf5MxV2CZ4sStGj31q1
Vort
при тесте на локалхосте проблема не попалась
Vort
а вот при тесте с рандомными хопами (1+1) - словилась где-то через минуту
Vort
при втором 2хминутном тесте ни разу не вылезла
Vort
при третьем - вылезла два раза
Vort
даже не два, а три
Vort
в некоторых случаях ситуация кажется довольно простой:
Vort
это просто дубли пакетов
Vort
в некоторых сложнее
Vort
но, скорее всего, это происходит из-за поменянных местами пакетов
Vort
onon: вот более делальный лог по NACK`ам: paste.i2pd.xyz/?6a78d0a850cccd18#EhRcyKARigkxWf2Pi9mHQFEaghT52518DDh15ezgVWGQ
Vort
идут ackThrough ... 38523 38552 38557 38576 38400 (бесполезный) 38491 (проблемный) 38589 38617 38618 ...
Vort
то есть, ackThrough 38400 и 38491 просто задержались
Vort
фича SSU2 в действии :))
orignal
не понял
Vort
onon удивлялся, почему приходят nack`и на несуществующие в m_SentPackets пакеты
Vort
я и разобрался, почему - потому что SSU2 переставляет местами пакеты
Vort
и эти nack`и просто старьё
orignal
ну так там же диапазоны