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

uwjjdahijdadquw Продублирую сюда наверное, в i2pd-dev пусто оказалось.

uwjjdahijdadquw Привет всем! Такой вопрос по внутренней работе i2pd. Разрабатываю в ��елях интереса свой клиент i2cp. Реализовал все сообщения по спецификации, роутер их принимает: создаётся сессия, запрашивается LeaseSet2 и принимается нормально,

uwjjdahijdadquw Destination определяется извне через HostLookup, в роутере определяются созданные тунели, LeaseSet публикуется. Вообщем, сессия настроена корректно. Но отправка непосредственно сообщений (MessageSend) происходит как будто с дропами. В цикле

uwjjdahijdadquw отправляю сообщения раз в секунду с одного клиента на другой (локально), но доходят сообщения раз в 100-120 секунд, т.е. +-100 сообщений не доходят до точки. Поотлаживал i2pd, вижу, что роутер принимает все сообщения: во-первых, получаю

uwjjdahijdadquw 2 статуса Accepted и GuaranteeSuccess, во-вторых из роутера вижу, что каждое сообщение заворачивается в I2NP обёртку и пушится в очередь для отправки. В логах ничего подозрительного не обнаружил. Свой код пересмотрел, уверен, что дело не в

uwjjdahijdadquw приёме сообщений, т.к. всё остальное принимается нормально. Уже не знаю куда смотреть, и что делаю не так, может у разработчиков будет идея или намёк, в чём может быть дело. Если надо приложу код, но думаю он будет вам не

uwjjdahijdadquw интересен, больше интересует можно ли по этим симптомам узнать, куда копать

uu2 uwjjdahijdadquw мы сидим еще в #ru

orignal I2CP в принципе кривой

orignal он только для снарка

orignal зачем ты на нем стал делать?

orignal второй прекрати этот дебильный перевод

orignal ты все равно не по русски говоришь

uwjjdahijdadquw Почитал про назначение протокола, думал он в рабочем состоянии и можно его использовать для отправки сообщений peer-to-peer

orignal ну снарк раблотает

orignal конкретно в чем проблема?

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

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

uwjjdahijdadquw До конечной точки долетает 1 из 120 сообщений, причём с завидной регулярностью раз в 120 секунд

uwjjdahijdadquw Нет, с тунелями 0 длины не пробовал

uwjjdahijdadquw Попробую, спасибо

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

orignal если где то там теряется расскажешь

orignal если в тоннель уходит что просиходяит дальше

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

orignal не срабатывает ли OnDrop

orignal нет надо именно когда в тоннель пишется

uwjjdahijdadquw Окей, подебажу это, спасибо за наводку

orignal в bool I2CPDestination::SendMsg

orignal outboundTunnel->SendTunnelDataMsg

orignal вот здесь чтобы уходил

uwjjdahijdadquw Да, там уходил

uwjjdahijdadquw Туда логи и добавлял

orignal а остальное все нормально работает?

orignal так там нет очережт это сразу отвправка в транспорты

uwjjdahijdadquw Остальное да, хосты лукапятся, сессия работает, лиз сеты публикуются

orignal вот этому std::shared_ptr<I2NPMessage> garlic

uwjjdahijdadquw Там же OutboundTunnel, m_Gateway.PutTunnelDataMsg

orignal добавь метод OnDrop

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

orignal и печатай в нем

orignal да?

orignal ой бля

uwjjdahijdadquw Кстати, пробовал добавлять в него лямбду без capture скоупа, для принта логов, но i2pd крашился)

uwjjdahijdadquw Мб чё то не досмотрел

orignal Flush сделай

orignal счас починю минут через 15

orignal спрасибо за инфрмацию

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

orignal void OutboundTunnel::SendTunnelDataMsgs (const std::vector<TunnelMessageBlock>& msgs)

orignal {

orignal std::unique_lock<std::mutex> l(m_SendMutex);

orignal for (auto& it : msgs)

orignal m_Gateway.PutTunnelDataMsg (it);

orignal m_Gateway.SendBuffer ();

orignal }

orignal погоди

uwjjdahijdadquw Да, до сюда сообщения долетают всегда

orignal вызывается outboundTunnel->SendTunnelDataMsgs (

orignal печатай в SendBuffer

orignal у TunnelGateway

uwjjdahijdadquw Окей, вечерком сёдня проверю тунели 0 длины и поглубже посмотрю что с сообщениями творится. Отпишу результаты

orignal m_Sender->SendMessagesTo

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

orignal void TunnelTransportSender::SendMessagesTo

orignal там довольно сложный алгоритм

orignal но он везде работает

uwjjdahijdadquw Просто довольно странный симптом, что регулярно раз в 120 секунд сообщение может дойти, а остальные тихо дропаются. Думал что с expire timeом лизсетов накосячил, но перепроверял всё - нет

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

orignal если не хочешь снарк

uwjjdahijdadquw Нет, джавовскую версию не пробовал. Снарком не пользуюсь, я просто протокол заимплементить хочу, чтобы разобраться лучше как работает i2p

orignal а вот ты попробуй и сравни

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

orignal возможно что часть протокола вообще не реализовано

uwjjdahijdadquw Спасибо за наводки, буду смотреть

orignal я делал чисто для снарка это

uwjjdahijdadquw Так, отладился, из того что смог понять, что сессия ECIESX25519AEADRatchetSession при отправке сообщений с одного клиента на другой, застревает в состоянии m_State = eSessionStateNewSessionSent, поэтому п��рвое сообщение, которое инициируется из eSessionStateNew

uwjjdahijdadquw всегда прилетает, а последующие выбиваются в WrapSingleMessage switch (m_State) -> default и сообщение дропается. Из логов подозреваю, что это из-за того что у меня для второго клиента LeaseSet пытается постоянно перепубликоваться и в моменты, когда

uwjjdahijdadquw он всё-таки верифается, сообщение как раз долетает до адресата. Пока единственное что могу предположить, исходя из возможных путей факапа сессии и перепубликации лизсета (причём только одного из клиентов) что возможно где-

uwjjdahijdadquw то с генерацией ключей проблема у меня. Буду дальше логи отфильтровывать

uwjjdahijdadquw :47:50@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :47:50@597/debug - Destination: Publishing LeaseSet confirmed for ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :47:56@597/debug - Destination: Published LeaseSet verified for ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :48:16@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :48:16@597/debug - Destination: Publishing LeaseSet confirmed for ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :48:40@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :48:41@597/debug - Destination: Publishing LeaseSet confirmed for ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :48:59@597/warn - Destination: Couldn't find published LeaseSet for ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :49:19@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :49:56@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw 49:56@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw 50:18@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :50:55@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :51:17@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :51:18@597/debug - Destination: Publishing LeaseSet confirmed for ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :51:41@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :51:42@597/debug - Destination: Publishing LeaseSet confirmed for ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :51:49@597/debug - Destination: Published LeaseSet verified for ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :52:11@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

uwjjdahijdadquw :52:33@597/debug - Destination: Publish LeaseSet of ufcumh23epvsbt6att34u4pgoubthldvjjuf4uunes22q7dfcz2q

orignal тип шифрования какой? 4,

uwjjdahijdadquw Да, 4

orignal я бы пробовал без посткватовых

uwjjdahijdadquw ElGamalи?

orignal нет

orignal ElGamal вообще забыть как страшный сон

orignal типы 5,6,7 это постквантовые

orignal <uwjjdahijdadquw> всегда прилетает, а последующие выбиваются в WrapSingleMessage switch (m_State) -> default и сообщение дропается

orignal вот тут подробнее с какой стати он дропаются?

orignal должны идти как новая сессиия

uu много сейчас пиров с постквантом ?

orignal а на другую сторону собщение о новой сессии приходит?

uu я сейчас на 2

orignal пиров или дестинейшинов?

uu роутеры, кто трафик гоняет

orignal если ты про NTCP2-PQ то он еще не выпущен

orignal реально только мой и деда флудфилы

uu я про те ML-KEM (3,5,6)

uwjjdahijdadquw m_State На первом сообщении eSessionStateNew. В NewOutgoingSessionMessage он меняется на eSessionStateNewSessionSent и так и остаётся

orignal 3,4,5 может?

uu угу

uu я не запомнил еще

orignal ну остается но следующий пакет просто ициниирует новую сессиию и все

orignal NTCP2-PQ пока еще рано

orignal здесь разговор только про скводное

orignal *сквозное

orignal uwjjdahijdadquw скажи строчку где дропается я посмотрию

uwjjdahijdadquw Следующий пакет, прилетающий в WrapSingleMessage?

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

orignal так он не должен вообще в эту сессию отправляться

orignal он должен в новую

uwjjdahijdadquw ECIESX25519AEADRatchetSession::WrapSingleMessage switch statement. У меня ~1074 строчка, но я логи добавлял, они чуть-чуть поехали в моём файле

orignal смотри в стримах как

orignal if (!m_RoutingSession || m_RoutingSession->IsTerminated () || !m_RoutingSession->IsReadyToSend ())

orignal то есть в I2CP скорее всего не так

orignal в этом возможно источник проблемы

orignal я погляжу

uwjjdahijdadquw В I2CP через GetRoutingSession сессия создаётся на первом сообщении

orignal счас разберемся

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

uwjjdahijdadquw В любом случае, даже если у меня баг в генерации ключей, тогда первое сообщение до адресата доходить не должно

orignal а у тебя оно доходит или нет?

uwjjdahijdadquw Первое - всегда доходит

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

uwjjdahijdadquw Дальше - раз в 120 секунд, когда лизсет очередной раз проверифается

uwjjdahijdadquw Это 2 мои стороны, в одну сторону шлю

orignal ну то есть почему вобще сессия не содается?

orignal пришло NS должен уйти ответ NSR

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

uwjjdahijdadquw Да

orignal или он просто не может расшифровать сообщние?

orignal дальше от отвечает NSR

orignal и что оно не доходит обратно?

uwjjdahijdadquw NSR это он клиенту i2cp отправляет?

orignal да

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

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

orignal расскажи что у тебя там просиходит после получения NS

uwjjdahijdadquw Мне приходит RequestVariableLeaseSet после создания сессии, и я ему отправляю LeaseSet2 в ответ

uwjjdahijdadquw Он его кушает нормально

uwjjdahijdadquw Все следующие RequestVariableLeaseSet также обрабатываются. Дальше что должно происходить?

uwjjdahijdadquw NS не совсем понял что такое, NS роутер мне не отправляет

uwjjdahijdadquw По коду тоже не вижу, чтобы в CreateLeaseSet2MessageHandler что-то в ответ отправлял

orignal ns - new session

orignal нет смотри

orignal у тебя клиент отправляет серверу какие то данные

uwjjdahijdadquw Да, я ему NS, он мне NSR, потом он мне RequestVariableLeaseSet и я ему в ответ CreateLeaseSet2

orignal так погоди

orignal клиент получает в ответ NSR?

orignal от сервера

uwjjdahijdadquw SessionStatus получаю

uwjjdahijdadquw Не то написал

orignal смотри логику работы

orignal твой клиет отправяет какие то данные

orignal они уходят вместе с NS

orignal сервер получает NS расшифровывает эти данные и отправяет твоему серверному приложению

orignal твое серверное приложение должно на них как то ответить

orignal только тогда обратно уйдет NSR

uwjjdahijdadquw А, любым ответом?

orignal да. лишь бы с данными

uwjjdahijdadquw Т.е. роутер ожидает, что в ответ источнику сообщения придёт что-то от назначенной точки?

orignal иначе NSR не отправится

orignal роуетер ожидает на посланный NS получить в ответ NSR

orignal если NSR не пришел сессия так и будет висеть

uwjjdahijdadquw Бля, спасибо, щас проверю. В спецификации этого не видел) Видимо реализация. Значит датаграммы в один конец слать без ответа со стороны не получится

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

orignal как у них реализовано

orignal мы в i2pd в UDP тоннелях шлем принудительно пустое сообщение в ответ

orignal тут понимаешь еще какое дело

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

uwjjdahijdadquw Хм, а что лучше тогда, SAM?

orignal я бы лучше испольщовал или сэм или боб

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

orignal я не вижу чтобы в WrapSingleMessage (std::shared_ptr<const I2NPMessage> msg) оно дропалось

orignal откуда ты это взял?

uwjjdahijdadquw return nullptr; возвращается в i2cp, и в итоге в перепаковке shared_ptr(nullptr) оказывается, и оно так дальше и прокидывается

orignal а вот все нашел

orignal счас подумаю

orignal эту сессию вообще не должно находит пока не прилетел NSR

orignal иными словами у тебя GetRoutingSession должен возвраать или новую или в ссотоянии estbalished

uwjjdahijdadquw Сработало перебрасывание сообщениями, спасибо

orignal но ты утвржаешл что auto remoteSession = GetRoutingSession (remote, true); возврашает его в статусе eSessionStateNewSessionSent,

orignal давай разбираться с этим

uwjjdahijdadquw Не, первый раз он возвращает в статусе eSessionStateNew

uwjjdahijdadquw Поэтому первое сообщение долетало

uwjjdahijdadquw Я логику понял теперь

orignal каким образом тебе GetRoutingSession вернула такое состояние

orignal понимаешь этого быть не должно

uwjjdahijdadquw На второе сообщение во WrapSingleMessage уже он был в eSessionStateNewSessionSent

orignal так а откуда?

orignal в каком месте ты взял сессиию?

orignal не должно быть ее в статусе sent

uwjjdahijdadquw ECIESX25519AEADRatchetSession::NewOutgoingSessionMessage

uwjjdahijdadquw m_State = eSessionStateNewSessionSent;

orignal это понятно

orignal я спрашиваю место в I2CP.cpp

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

uwjjdahijdadquw Саму сессию я в таком состоянии по логам перехватывал в

uwjjdahijdadquw bool I2CPDestination::SendMsg (const uint8_t * payload, size_t len,

uwjjdahijdadquw std::shared_ptr<i2p::garlic::GarlicRoutingSession> remoteSession, uint32_t nonce)

uwjjdahijdadquw callstack не смотрел конкретно по состоянию сессии

orignal а remoteSession откуда?

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

uwjjdahijdadquw Смотрю щас где я её брал

uwjjdahijdadquw А так вот

uwjjdahijdadquw SendMessageMessageHandler

orignal наверное он где то сохраняется в этом состоянии

orignal счас разберемся

uwjjdahijdadquw if (!remoteSession || !m_Destination->SendMsg (buf + offset, payloadLen, remoteSession, nonce))

orignal погляжу

orignal спс. все нашел багу

orignal счас починю и закоммичу

uwjjdahijdadquw Рад помочь

orignal отличная находка

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

uwjjdahijdadquw Настолько непопулярный протокол i2cp походу)

orignal у джавистом все через него а в i2pd только снарк

orignal github.com/PurpleI2P/i2pd/commit/45b518f7e9fcb629d7f5ac312f9ac01e619df6ca

uwjjdahijdadquw Странно только что необходимо в ответ слать что-то, потому что в протоколе самом i2cp нету никаких метаданных о том, от кого сообщение было, это надо самому сверху городить надпротоколы

orignal как дед говорит "это должны делать протоколы более выского уровня"

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

orignal как они в streamr делают

orignal спросил ждем разъяснений