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

onon Действительно, есть странности, открыл 5 вкладок спортлото, долго искал лизсет, когда нашёл, в первой открытой вкладке отдал Proxy error: Host is down , во второй и четвётрой открылся, в остальных завис.

orignal вот надо переделать это

orignal счас для RI так сделано

onon Я обычно по несколько вкладок одного и того же не открываю, поэтому не замечал.

orignal ну это реедко нужно

orignal а вот для приложений может быть надо

onon Если прокси пользуются много юзеров, то нужно

orignal все эти ваши микросервисы начинаю. запрашивать какой то адрес однвременно

onon На гейтах так работает

orignal ну так вот надо переделать

orignal переделаю сегодня

колдоёбина хех. nginx я замучал до коре дампов

колдоёбина умею я фатальные баги везде находить

колдоёбина нечаянно

Vort но связано это с лизсетами или нет - не знаю

orignal попробую переделать запрос лизсетов для начала

` > умею я фатальные баги везде находить

` м-м-м, как быдлокодингпозитивненько ^_^

Vort хотя если бы лизсет не нашёлся для второго стрима, то он бы, наверно, вообще в списке не появился

Vort а я всегда их парой наблюдаю

Vort или два создаются или ни одного

orignal не уверен как там делает

orignal ся

orignal вопрос повисания второго надо бы поизучать

orignal что ему мешает

Vort пока ни одного ack`а не пришло, то все стримы по рандомным путям идут?

Vort может, одному стриму "повезло" с туннелями сразу, а второму - нет

Vort но второй не знает, что у первого "хороший" путь выпал и продолжает долбиться рандомно

orignal скорее всего

orignal посмотрил там все нормально

orignal там список есть коллбэков

onon std::shared_ptr<InboundTunnel> Tunnels::GetNextInboundTunnel ()

onon {

onon std::shared_ptr<InboundTunnel> tunnel;

onon size_t minReceived = 0;

onon for (const auto& it : m_InboundTunnels)

onon {

onon if (!it->IsEstablished ()) continue;

onon if (!tunnel || it->GetNumReceivedBytes () < minReceived)

onon {

onon tunnel = it;

onon minReceived = it->GetNumReceivedBytes ();

onon }

onon return tunnel;

onon }

onon Может мне кто объяснить как это работает, зачем нужен GetNumReceivedBytes

orignal выбирается наименее загруженный

orignal логично же

onon1 Бред

onon Выбирается нерабочий, через который данные не пролазят

orignal ну а как ты знаешь рабочий он или нет

onon Там в Tunnels::GetNextOutboundTunnel () вроде рандом выбирается

onon Если я оттуда код скопирую, работать будет?

orignal будет

orignal вопрос в том для чего мы его вообще выбираем

orignal надо начинать с этого

onon void TunnelPool::CreateOutboundTunnel ()

onon Я там вижу, выбирается

orignal ну да это только для запроса

orignal ты посмотри еще для чего

orignal вообще то тут надо бы транспорную совместимость проверять

orignal и как раз выбирать тот через которые данные идут

onon Ну так сделай

onon Если более важных дел нет

orignal так ты скажи если вызывается только для этого

orignal этот код который ты привел изначально не хорош

orignal лучше выбирать не где меньше получено а кто новее

onon Я вообще с лизсетами пытался разобраться там в гарлике нашёл

orignal чем старше тоннель тем больге вероятность что он протух

orignal ладно гляну

orignal но не думаю что оно сильно влияет

onon Но там вроде только для эль гамаля

onon А где выбирается для лизсетов в стриме, я не нашёл

orignal ну тогда тем более пох

orignal входящий выбирется для построния любого исходяшего

orignal для запроса лизсета должен

orignal auto inbound = pool->GetNextInboundTunnel ();

onon входящий выбирется для построния любого исходяшего - ну так поэтому ткср такой низкий

onon Если неправильно выбирается

orignal возможно

orignal и кстати да

orignal ты замеча что входящий строятся лучше чем исходящие?

onon Есть такое

orignal так что твоя находка довольно верная

orignal надо это проверить

orignal auto inboundTunnel = GetNextInboundTunnel (nullptr, path.farEndTransports);

orignal да не нормально там выбирается

orignal с проверкой

orignal <onon> std::shared_ptr<InboundTunnel> Tunnels::GetNextInboundTunnel ()

orignal откуда вообще этот код?

orignal его нет в Tunnel.cpp

orignal *TunnelPool.cpp

orignal а все понял

orignal тот код почти никогда не вызывается

orignal только при старте

onon Значит хрен с ним. Лучше покажи мне место, где собираются свои исходящие туннели для лизсета

onon Входящие*

onon И где они отправляются в стриме

orignal void LeaseSetDestination::UpdateLeaseSet ()

onon Что-то мне эта тема с slowTunnel кажется сомнительной.

orignal тем не менее она привела к резкому улучшению работы

onon А тебе не показалось?

onon Метрики проверяли?

onon Он же через летенси измеряется

onon а летенси у тебя под нагрузкой будет расти

onon Потому что сс nfrjq

onon такой*

orignal возможно

orignal ну не найдет быстрый тоннель возьмет какой есть

onon Так он что только один медленный вставляет, если они допустим все медленные? if (it->IsSlow () && !slowTunnel)

orignal не помню

orignal сачс некогда смотреть

onon Я думал выпилить эту проверку на медленный туннели, но меня смущает при сборке лизсета эта строка int numTunnels = m_Pool->GetNumInboundTunnels () + 2; // 2 backup tunnels

onon Он просит на два туннеля больше, чем есть

onon Зачем, понять не могу.

orignal уменьшил число попыток до 5

orignal сделал пул для запрлсов

onon Думаю это какой-то хак

orignal какой то хак да

orignal зачем тоже не помню

orignal надо разбираться

orignal я вот думаю а не вынести ли запросы в отдельный тред?

onon Ты мне лучше объясни как работает логика со стримами и лизсетами, я не могу найти где, когда и куда они отправляются. И как работает GarlicRoutingSession и m_RoutingSession

onon Я уже весь мозг себе сломал, несколько часов пытаюсь разобраться.

orignal что именно?

orignal как они публикуются? как они запрашиваются? как они обновляются?

onon Я правильно ищу код отправки лизсета в Garlic.cpp?

orignal нет надо в ECIESX25519AEADRatchetSession.cpp

onon Где на флудфил публикуется, вроде нашёл

orignal там его блок добавляется

onon А почему GarlicRoutingSession

onon Это легаси?

orignal да

onon А что в стриме они запрашиваются?

orignal это для эль гамаля

onon Я думал сами отправляем по необходимости

orignal естественно сами

orignal вот ECIES сессия сама знает когда надо прицепить

orignal но она сама не отправляет пакеты

orignal потому в стриме если надо отправить лизсет то отправляют Ack принудительно

orignal если больше ничего нет

orignal или вообще пустой я уже не помню

onon Стрим делает SendQuickAck ();

onon Перед этим сбросив m_RoutingSession->SetSharedRoutingPath (nullptr);

orignal возможно

orignal а можно просто пустой пакет послать

onon Я правильно понял, к нему цепляется таймстемп const unsigned int I2NP_MESSAGE_EXPIRATION_TIMEOUT = 8000; // in milliseconds (as initial RTT)

onon А это всё шифрованное или нет?

onon На пальцах можешь объяснить? Алиса хоче скачать картинку с сайта, с флудфила получила лизсет, открывает стрим, как она сообщает бобу, куда слать ответ.

onon Формирует I2NP сообщение со своим лизсетом, и куда отправляет?

onon И как часто

orignal в общем да

onon Если логику объяснишь, я возможно найду, где проблема. А когда я пытаюсь в этом разобраться по коду, не зная синтаксиса и структуры, желание забить на это всё обычно перевешивает.

onon И я начинаю заниматься чем-то другим.

orignal алиса находит лизсет боба

orignal и с первым пакетом уходит ее лизсет

orignal она форимуетс SYN пакет выбирает свой исходяший и входящий боба

orignal когда отправляет к нему прицепляется лизсет

onon А на каком уровне он "отцепляется" и обрабатывается?

orignal приходил чеснок расшифровывается и обрабатываются блоки

orignal Data идет дальше в стрим

orignal а лизсет в локальный netdb

onon А потом, во время работы стрима, как обновляется лизсет и как часто

orignal когда получаем новый или когда у нас новый

orignal и там подиверждение есть

orignal отправили пришло подтверждение больше не шлем

onon И тоже цепляются к стримовому пакету?

orignal есественно

orignal сеееия без понятия как отправлять

orignal это стрим знает

onon Если боб получил новый лизсет, он старый удаляет, а новый вставляет, или добавляет поверх старого

orignal если более новый то обновляет

onon1 Я к тому, что если у алисы туннель сфейлился, она его в лизсет не вставляет

onon1 Не пытается ли боб туда слать

onon1 А более новый это по какому признаку

orignal а как боб узнает лизсеты адисы пока не получит?

orignal более новый там в лизсете таймстамп есть

orignal отдельный

onon1 Expires: 05/05/2024 16:56:59.000

onon1 Такой?

orignal да

onon1 Так он вроде равен экспирации самого молодого из туннелей EndDate: 05/05/2024 16:56:59.000

orignal это надо проверить как формируется

orignal ну я понял твою мысль

orignal если тоннельь сфейлился а новый лизсет идет со старым таймстампом

orignal да так и есть

orignal надо чинить

orignal счас спрошу деда

onon У меня тоже была идея просто добавлять к текущему времени 10 мин и записывать в Expiration

onon Если лизсет обновится, то и время обновится.

onon Но как такое будут обрабатывать клиенты хз

orignal короче порядок там

onon Если Expiration больше чем у последнего лиза

orignal тем есть published time

orignal и expiration time

onon А, понятно.

orignal published ставим текущее а expit=ration последнего тоннеля

onon Тогда следующий вопрос, как часто мы отправляем свой лизсет

orignal как только обновился

onon Новый туннель построился - сразу отправляем обновлённый?

onon Ещё туннель сфейлился - тоже переотправляем

orignal не сразу а со след сообдщением

orignal просто флаг стами

orignal ставим

onon Блин, вроде всё логично. Чего ж нихрена не работает.

orignal вот разбирайся

onon Как мне сделать чтобы в логи писалось: Получен лизсет от destination, список лизов: 1, 2, 3....

onon Стандартный нешифрованный лизсет Store type: 3 в коде у нас проходит под псевдонимом LeaseSet2 ?