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

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 paste.i2pd.xyz/?212a9876c6ff4f27#A4uyCKX9fA1r1ha7JVNcqoUT4owCzGn5iiE4H3jaENWF

Vort в некоторых случаях ситуация кажется довольно простой:

Vort это просто дубли пакетов

Vort paste.i2pd.xyz/?96fecc93f960c629#21253EVihoQ8PX21XU9zBv99jsQUw4pEmuLLJ11RbEFz

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 ну так там же диапазоны