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

orignal i2p::util::MemoryPool<I2NPMessageBuffer<I2NP_MAX_MESSAGE_SIZE> > m_I2NPMsgsPool;

orignal в Datagram.cpp

orignal интересно это кто такое написал там ))

orignal и в стримах та же хуета

orignal Vort так так что понятно ноги растут

Vort orignal: I2NP_MAX_MESSAGE_SIZE - это 62к. а утечка идёт 16к блоками. так что не совсем понятно

Vort вот блин. где-то в торренте баг. коннекты идут не туда, куда надо. вместо коннекта к трекеру, коннект идёт куда-то на левый адрес

Vort интересно, чья вина - i2pd или libtorrent. думаю, что торрента. но от этого не легче :(

Vort а ведь может быть и i2pd

polistern С каким торрент клиентом проверяешь?

Vort свежий qBittorrent + свежий libtorrent

Vort polistern: знаешь, как по-быстрому дестинейшен из base64 в base32 перевести?

Vort пытаюсь понять что тут происходит

Vort но если сложно, то буду сам разбираться

polistern Только в коде это делала, может в тулзах есть?

Vort :(

Vort в общем, вместо коннекта к трекеру идёт коннект фиг знает куда

Vort и я пытаюсь понять, кто виноват

polistern github.com/PurpleI2P/i2pd-tools#keyinfo

Vort так этой команде .dat бинарный нужен

polistern Ну уж б64 в байты проще перевести.

Vort ок, попробую

Vort хотя написано же Prints information about an I2P private key

Vort а, вижу, просто написано запутанно

polistern CLI с такими фичами давно напрашивается, вот только как всегда некому)

Vort в i2p ещё и кодировка base64 нетрадиционная

Vort что-то не так делаю. bad key file format

Vort видимо, в файле ещё что-то должно быть

Vort в общем, надо проверить вот этот ответ SAM`а:

Vort paste.i2pd.xyz/?c878c88c75758088#6Q2VrgYWAsuQRJy6ja3m7bf66s59YU4mJVBPSR5jciup

Vort коннект к этому дестинейшену вёл на ssr2jrqj2pxbjmuq2eopntbsbgiexu7zhgtkn4j4ysdo2tclmbka.b32.i2p

Vort хотя, судя по всему, должен был идти на 6a4kxkg5wp33p25qqhgwl6sj4yh4xuf5b3p3qldwgclebchm3eea.b32.i2p

Vort то-есть, надо понять - чей адрес в ответе SAM`а

Vort и, желательно, чей это адрес ssr2...

Vort небось, какого-то из пиров торрента :(

Vort вырисовывается картина очень неприятного бага в i2pd

Vort когда приватные данные могут пойти фиг знает куда

polistern Т.е. qBittorrent неправильно адрес трекера вывел через lookup? Или пока хз где проблема?

Vort надо понять, во что преобразуется lnQ6yoBTxQuQ...

Vort скорее всего, lookup верный, но когда идёт коннект по этому дестинейшену, то приходит он куда-то не туда

Vort торрент правильно выдаёт STREAM CONNECT ID=... DESTINATION=lnQ6yo...

Vort получает STREAM STATUS RESULT=OK

polistern reg.i2p говорит, что tracker2.postman.i2p это b32 6a4kxk... или b64 lnQ6yoBTxQuQU8E...

Vort шлёт GET /announce.php?info_hash=...

Vort а приходило это всё на ssr2jrqj...

Vort polistern: ок, спасибо. а найти чьё ssr2... можно?

polistern Смотрела, нету

polistern Получается надо узнать что придумал этот ssr2jrqj, клиент или роутер.

Vort клиент не мог придумать. он слал STREAM CONNECT ID=... DESTINATION=lnQ6yo...

Vort а как оно попало не туда куда надо - надо разбираться

Vort надо попробовать ещё раз воспроизвести

Vort paste.i2pd.xyz/?2eacd8d848d215a1#FGQAfEh9Wr3hz19LXxPN9ZQ25jwKkBUN4NRqAvWfurZ4

Vort это один из пиров

Vort вначале, кстати, коннект к трекеру идёт куда надо

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

Vort стал разбираться - и увидел, что данные идут не туда

Vort подожду пока лизсет 6a4kx уберётся из списка и ещё разок коннект сделаю к трекеру

Vort не воспроизвелось. пошёл коннект на трекер куда надо

Vort а вот со второй попытки получил зависание, как и в прошлый раз. хоть лизсет и есть

Vort в общем, сейчас я уже не уверен, что идёт не туда. но тормоза точно есть

Vort ещё бы торрент клиент не крешился :)

Vort со вторым воспроизведением проблемы получилось непонятность - креш помешал разобраться в том, что произошло

orignal Vort понятно что утечки там нет но аллокации все равно есть

Vort orignal: ну, то есть, образно говоря, получаем две проблемы

orignal а что с адесами то?

Vort есть подозрение, что коннект шёл не туда. но подтвердить пока что не могу

Vort то есть, клиент запрашивал коннект к трекеру, а в вебконсоли было множество записей с левым адресом

Vort я даже все раздачи остановил, чтобы убедиться

Vort все остальные адреса отвалились, а этот оставался висеть

orignal так ты логи смотри там же записываются сэм сообщения

Vort я и так их вижу, через Wireshark

orignal если к трекеру то должен быть name lookup что то типа того

Vort name lookup был правильный

Vort STREAM CONNECT был тоже правильный

Vort а вот результат - не правильный

orignal а что тогда неправильно?

orignal в каком смысле

orignal не тот b32 или что,

Vort ну то, что в списке консоли вместо 6a4kxkg5wp33p25qqhgwl6sj4yh4xuf5b3p3qldwgclebchm3eea.b32.i2p висели адреса ssr2jrqj2pxbjmuq2eopntbsbgiexu7zhgtkn4j4ysdo2tclmbka.b32.i2p

Vort и не коннектило к трекеру соответственно

orignal стримов?

Vort да, стримов

Vort может, конечно, ssr2jr... по какой-то левой прчине завис, а трекер 6a4kx по какой-то левой причине не приконнектился, но странное это совпадение

orignal tracker2.postman.i2p,6a4kxkg5wp33p25qqhgwl6sj4yh4xuf5b3p3qldwgclebchm3eea

orignal а в лизсетах что ты видел?

Vort ну да, а в списке были ssr2jrqj2pxbjmuq2eopntbsbgiexu7zhgtkn4j4ysdo2tclmbka.b32.i2p - видимо, адрес какого-то пира

orignal ну так может стрим с трекером просто закрылся

Vort много чего я там видел... уже и не припомню. скорее всего, только ssr.. был

Vort в общем, надо пробовать ещё воспроизводить. пока что ничего не понятно

orignal так если у тебя не было постмана в лизсетах скорее всего просто не нашел

Vort а пир завис сам по себе почему-то?

Vort потом, кстати, уше пошли реально коннекты к правильному адресу

orignal ну в стримах пиры часто виснут

orignal через несколько минут сдохнет

Vort была вот такая картина paste.i2pd.xyz/?396d4ff3650c130c#8rc9BxCQTeJ3DPB29zNb3yLs4JZwnYxRQJPxQLEEmRK1

Vort вначале только ssr2jrqj2

Vort потом появился 6a4kxk

Vort а потом крешнулся клиент )

Vort пока что делаю вывод, что просто так совпало - пир по какой-то причине завис, а трекер по какой-то причине долго не коннектился. из-за чего я подумал, что зависший пир - это и есть коннекты трекера

orignal возмодно

orignal насечт 62K в стримах поменяю на 4

Vort хорошо. но это на утечку не должно повлиять?

orignal не должно

orignal просто для отптимизации

Vort понятно

orignal если у тебя олновременно тысячи стримов и каждый по 62K дергает

Vort нагрузка на кучу как я понимаю

orignal как например на кислице тема с сиськами

Vort стресс тест для i2pd :))

orignal и для джавы

orignal пару лет назад регулрыно проверяли работу на этой теме ))

Vort ну вот теперь и торренты добавятся

orignal в итоге админ кислицы ращнес по несколько адресам

orignal там 900 с чем то фоток на странице

Vort это же я с 2-3 раздачами сейчас тестирую

Vort а если 200 закинуть...

Vort если утечка пропорциональна количеству коннектов, то память так быстро кончится

Vort вот этот ssr2jrqj2pxb адрес кстати уникален тем, что отвечает по 86 байт

Vort надо бы разобраться что это значит

Vort видимо, это и есть причина того что он зависает

Vort Sent 511, Received 86

Vort вот сейчас 10 стримов с ним висит

Vort может, и утечку он генерирует

orignal возмодно

orignal кстати стримы сами по себе реализованы крайне неэффективно

Vort оптимизации - это хорошо, но для начала баги бы поубирать

orignal для ачала их надо найти ))

Vort да вот собирался искать утечку, а зависший адрес отвлёк :/

Vort к адресу ssr2jrqj2pxb уже 31 стрим

orignal думаешь зависишие?

Vort ну я вижу, что этот эффект ненормален

Vort а вот кто в нём виновен - надо разбираться

Vort однако сейчас попробую просто найти, откуда идут висящие 16к блоки

Vort хотя для начала проверю, не исчезла ли утечка

Vort надо ещё сделать тест с остановкой раздач

Vort после остановки раздач ssr2jrqj2pxb никуда уходить не собирается

Vort да и SAM коннекты для него висят

Vort это явно имеет признаки утечки. хотя, может, это и не главная проблема

orignal подожди несколько минут

Vort скорее всего, вот этот ответ на 86 байт - это ошибка, которая должна приводить к закрытию стрима, но не приводит

Vort и торрент ждёт ответа вечно

Vort ну это только предположение. проверять надо

orignal возможно

orignal надо бы посмотреть что там приходит

Vort я сейчас через прокси этот адрес ткну

Vort агаа, те же 86 байт

Vort ssr2jrqj2pxbjmuq2eopntbsbgiexu7zhgtkn4j4ysdo2tclmbka.b32.i2p

Vort ещё наблюдение - стримов к нему на вкладке с адресами 32 штуки

Vort а на вкладке SAM-а раза в 2 меньше

Vort наверно торрент начал догадываться, что пора закрывать эти коннекты

Vort только вот будет ли толк от этого

Vort прокси тоже пока не закрыл

Vort хотя вкладки браузера уже давно нету

Vort похоже, что 16к блоки связаны с этим ssr2jrqj2pxb

Vort делаю перезапуск, попробую стеков насобирать

weko orignal: по моему мнению очень важно обеспечить стабильность передачи данных - чтобы не было зависаний. ещё я заметил такое, что через SAM уже вернулся статус ок для серверного деста, а по факту лиссет не опубликован - через клиентский туннель лиссет не находит

weko хотя роутер один и тот же - фактор случайности минимален. тем более это не раз уже было

weko ещё вопрос - раз в сколько времени i2pd обновляет лиссет не флудфилах?

orignal раз в 10 минут или при смене тоннелец

orignal *** ушел ***

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

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

weko ну это в ллюбом случае раньше чем 10 минут

weko потому что туннели по 10 минут

weko orignal: а по поводу сэма что?

weko ещё вопрос по поводу сэма - как i2pd определяет, что для дестинейшена нужно публиковать лиссет? если есть acceptor?

Vort не получилось у меня словить стеки. и я, похоже, догадываюсь почему. не каждый объект "чуть жирнее 16к" является I2NP сообщением :)

Vort это какие-то другие объекты

R4SAS Vort: а может тот адрес был b33?

Vort я пока что не знаком с этой особенностью i2p

R4SAS а ты попробуй присосаться к тому адресу напрямую, и с тем что ты ожидаешь

R4SAS через http proxy

Vort ну и почему "был"?

Vort он онлайн

Vort по той ссылке что я кидал

Vort ssr2jrqj2pxbjmuq2eopntbsbgiexu7zhgtkn4j4ysdo2tclmbka.b32.i2p

Vort ну... как онлайн... 86 байт выдаёт

R4SAS по идее если это трекер, то /stats должен отвечать статистикой тренера

R4SAS трекера*

Vort да нет, то я ошибся, не трекер это

Vort а какой-то странный пир

Vort который даёт зависания

R4SAS а ты пытался отловить соединения?

Vort какие? SAM?

R4SAS так, ssr2 ты ожидаешь, а какой по факту?

Vort говорю же - то была моя ошибка, я уже от него ожидаю только одного - чтобы из-за него не глючил i2pd

R4SAS да, SAM тоже отследить можно

R4SAS а, ясн

Vort попробуй сам подключиться к нему

R4SAS ERR_EMPTY_RESPONSE

Vort это браузер выдаёт?

R4SAS он чего то отвечает, но не знаю чего

R4SAS да

Vort хм. надо его как-то понизкоуровневее опросить

Vort неужели эти 86 байт - это реальный его ответ? я думал, может, какие-то метаданные i2p

Vort но самое важное - почему он не исчезает со вкладки дестинейшена

Vort не знаю, висит ли он там бесконечно, но уж явно очень долго

weko стрим то?

Vort да

weko висящие стримы уже известная хрень

weko я ж писал даже

R4SAS значит та сторона не отвечает

Vort да я помню, у тебя с адресной книгой такое было

Vort ну многие которые не отвечали - у них было принято 0 байт

R4SAS не не

Vort а этот неответ почему-то 86 байт

R4SAS смотри, есть такая вероятность что i2p ответ в стриме дает

R4SAS но вот сам сокет приложения с той стороны не отвечает

Vort а, вот как

weko ну это понятно, но вот не понятно почему таймаут не срабатывает

R4SAS т.е. соединение до сокета установилось, но приложение не отвечает и держит соединение открытым

weko Vort: ну да с адресной книгой, но причина явно таже

Vort таких стримов набирается довольно много

Vort да, вопрос в таймауте

R4SAS крч чем то похоже на tarpit, но не он сам

Vort особенно в случае когда клиент уже дропнул локальный коннект

R4SAS а вот видишь в чем дело

R4SAS закрывать соединения по какому либо таймауту тоже плохо

Vort ну допустим клиент локальный закрыл, не дождался

weko <Vort> особенно в случае когда клиент уже дропнул локальный коннект

weko ну да вот это основнре

weko по сути так и должно быть

R4SAS значит где то блокировка проихсходит

weko <~R4SAS> закрывать соединения по какому либо таймауту тоже плохо

weko у клиентских программ обычно есть таймаут, после которого они закрывают сокет

R4SAS обычно если клиент по нормальному FIN шлет то i2pd закрывает его

Vort в общем, пока глюченый пир в сети, советую его "подопрашивать"

Vort R4SAS: браузер - не нормальный клиент?

Vort надо найти эталонный клиент ) и им ткнуть

Vort в прокси допустим

R4SAS ты же говоришь что у тебя это в торрент клиенте происходит

Vort я уже и через браузер+прокси проверил

Vort ситуация примерно та же

Vort вкладку закрыл, а стрим висит

R4SAS кстати, если смотреть на ответы при отсылке браузером FIN,ACK, то от прокси прилетает в ответ ACK

Vort то ли браузер жадничает и не закрывает, то ли баг

Vort прокси не хочет закрывать несмотря на просьбу браузера? )

Vort или как это понимать?

R4SAS а это происходит потому что при FINACK ш2зв отсылает его на другую сторону и ждет ответа оттуда

weko Vort: а ты закрой браузер и проверь

Vort "ждет ответа оттуда" - долго ждёт

R4SAS там есть алгоритм ожидания

weko R4SAS: ну дак если ответа нету то чего жждать то

R4SAS таймаут с автоинкрементом

Vort weko: да ну алгоритм в целом логичен

Vort но i2pd ждёт какое-то нереальное количество времени

Vort за это время торрент клиент успевает хренову тучу свежих коннектов нарожать

R4SAS он ждет столько, сколько описано по какому то RFC

R4SAS не помню какому

weko тут ещё вопрос - а зачем нам ответ. типо чтобы убедится, что другая сторона закрыла сокет или как?

R4SAS я этот момент тоже обсуждал с лосем

R4SAS weko: TCP же

Vort при чём тут TCP ?

Vort это внутри i2p происходит

weko Streaming

R4SAS github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/Streaming.h#L55

R4SAS вот тебе и ответ

R4SAS отсылается FIN ACK

R4SAS но ответа нет

R4SAS и вот так 6 раз

Vort MAX_RECEIVE_TIMEOUT = 20; // in seconds

weko 6 раз, но всё равно почему так долгл

Vort 6 * 20 что ли?

weko 2 минуты должно быть

weko а оно явно большн

Vort вот поэтому я и спрашиваю, как должно быть

Vort а потом измерю

Vort как есть

R4SAS нет, где то еще есть

R4SAS какой то таймер

R4SAS не оно ли это: m_RTO *= 2;

Vort кстати, у меня есть кандидат на утекающие 16к блоки - std::make_shared<SAMSocket>(*this)

R4SAS сейчас еще раз глянул

R4SAS оно действительно ждет

R4SAS Out: 1

weko вот и нет смысла если ответа нет

R4SAS вероятно что оттуда ответ не приходит

R4SAS точнее с той стороны если и прилетает ответ, то либо на то стороне флаги не ставятся

R4SAS либо они теряются

R4SAS и там вероятно уже стрим закрыт

weko ну да

weko anyway

R4SAS из-за этого наш FIN не доходит

R4SAS надо дебаг логи врубать и смотреть

Vort выходит две проблемы - 1. почему "та сторона" так себя ведёт 2. как бы защититься от такого поведения

Vort просто если ту сторону починить, то может прийти хакер и сделать то же самое

Vort так что надо с двух сторон чинить

Vort ещё кое что - я когда заметил утечку, то она длилась в той же поре на протяжении 6 часов

Vort так что если такой стрим и закрывается, то это происходит оочень долго

Vort R4SAS: у тебя с дестинейшена прокси уже ssr2jrqj2pxb отвалился или ещё висит? у меня висит

Vort точнее, у меня их было два. один за несколко минут ушёл, а второй остался

R4SAS давно ушли

orignal weko так параметр есть в констрекуторе публиковать или нет

weko SSESSION CREATE ? не видел такой, щас гляну

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

weko не вижу в доках

weko orignal: как называется параметр ?

R4SAS orignal: libi2pd/Tunnel.h:141:9: warning: 'i2p::tunnel::OutboundTunnel::SendTunnelDataMsg' hides overloaded virtual function

R4SAS в классе Tunnel идет void SendTunnelDataMsg (std::shared_ptr<i2p::I2NPMessage> msg);

R4SAS затем в class OutboundTunnel: public Tunnel

R4SAS void SendTunnelDataMsg (const uint8_t * gwHash, uint32_t gwTunnel, std::shared_ptr<i2p::I2NPMessage> msg);

R4SAS virtual void SendTunnelDataMsg (const std::vector<TunnelMessageBlock>& msgs); // multiple messages

Vort интересно, что когда я добавил код для того, чтобы следить за утечкой SAMSocket, то они перестали утекать. загадка )

Vort ну или подождать дольше надо

orignal R4SAS слово oveeride

R4SAS в обеих строках?

orignal weko да ты прав в сэме нету только в тоннелях етсть

orignal R4SAS в базовом классе virtual

orignal в унаследованных oveeride

R4SAS libi2pd/Tunnel.h:141:110: error: non-virtual member function marked 'override' hides virtual member function

R4SAS void SendTunnelDataMsg (const uint8_t * gwHash, uint32_t gwTunnel, std::shared_ptr<i2p::I2NPMessage> msg) override;

R4SAS ^

R4SAS libi2pd/Tunnel.h:106:17: note: hidden overloaded virtual function 'i2p::tunnel::Tunnel::SendTunnelDataMsg' declared here: different number of parameters (1 vs 3)

R4SAS virtual void SendTunnelDataMsg (std::shared_ptr<i2p::I2NPMessage> msg);

R4SAS ^

orignal так надо разбтраться с логикой

orignal мне прям счас некогда позже посмотрю

R4SAS ок

Vort по поводу SAMSocket: такой сильной течи, как в прошлые разы в дебаг сборке я не вижу. но расхождения есть. к примеру, на вкладке SAM отображаются 128 коннектов к 127.0.0.1, но при этом у меня в логе набралось 138 объектов

Vort при этом, ssr2jrqj2pxb на вкладке дестинейшена - 10 штук. опять совпадения что ли

Vort в общем, похоже, проблему можно словить по-простому - сравнив количество стримов на странице SAM и на странице дестинейшена в вебконсоли

Vort к примеру, сделав поиск в браузере по "stream [" в одном списке и "b32.i2p" в другом

Vort на всякий случай отмечу, что прошлый глюченый пир не одинок. вот ещё один с таким же поведением: tnnroqx6ayqquyjoeg5otqghgj75c5badfe7as37x7oi2ki7me6a.b32.i2p

orignal ты бы лог записал что там в пакетах от него проходит

Vort кстати, глюк вполне может проявляться когда есть несколько коннектов к таким адресам - первый коннект отваливается нормально, а остальные зависаюь навсегда

orignal ух ты

orignal это посмоорим

Vort orignal: обычный лог что ли?

orignal нет в коде распечатать

orignal прямо где приходит пакет

orignal ладно потом

Vort потом юзер уйдёт. надо сейчас

Vort можно наверно даже не печатать, а через отладчик посмотреть

Vort но мне надо знать куда точку остановки тыкать

orignal void Stream::ProcessPacket (Packet * packet)

Vort ок, гляну

orignal flags

orignal if (flags & PACKET_FLAG_CLOSE)

orignal вот это

Vort а, так флаги и в обычный лог идут. ну да не важно, сейчас попробую словить

orignal мне интересно с каким флагами ответ

Vort такое ощущение, что брекпоинт не ловит

Vort точнее, ловит, но не то

orignal тогда void StreamingDestination::HandleNextPacket (Packet * packet)

Vort а вот этот словил

Vort и размер правильный

orignal ну вот смотри что у него в буфере

Vort paste.i2pd.xyz/?b12d77e34e892ef3#5Aww6hzTDrUiKuXRaZEuSvSr2ZTgRoXRsdq5zsD5icEG

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

Vort пошёл в if (m_LastStream) m_LastStream->HandleNextPacket (packet);

orignal нули это явно новый пакет

Vort теперь пошёл в ProcessAck (packet);

orignal смотри

orignal а плчему в handleNextPacket не остановился.

Vort из странностей - rtt = 336065

Vort ну оно из handle пошло в ack

orignal непонятно почему receivestreamid нули

orignal ладно позже

Vort "Streaming: Plain ACK received"

Vort собственно, на этом Plain ACK обработка по сути и заканчивается

orignal странные какие то флаги 0x0c00

Vort это кстати был пакет от ssr2jrqj2pxb. tnnroqx6ayqq, похоже, свалил до того как я смог ответ словить

orignal чушь какая то получается

orignal const uint16_t PACKET_FLAG_NO_ACK = 0x0400;

orignal const uint16_t PACKET_FLAG_OFFLINE_SIGNATURE = 0x0800;

orignal эта пара флагов

Vort ещё один адрес с "86 байтами". на всякий случай. ma3zmgs7qoqjtjqenjiqzp5jwrpjttjrulk6orw3bumhb3buakba.b32.i2p

orignal так объясни еще раз что с ними не так

Vort зависают в дестинейшенах навсегда

Vort по крайней мере, если несколько стримов сделать

orignal сколько их штук?

Vort с одним может и не зависнуть

orignal и что с номерами стримов?