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

orignal onon короче главные тормоза при запросе лизсета это не сам запрос а ожидание ответа

orignal таймаут

orignal то есть вот мы думаем что флудфил ближайший а он падла не отвечает

orignal и мы ждем

segfault orignal: почему бы не послать сразу нескольким флудфилам и не воспринять ответ первого?

segfault orignal: только это надо делать опциональным, вдруг кто-то попытается атаковать сети, заполнив сеть множество флудфлов у которых ping будет ниже, чем у других

Vort "<~orignal> то есть вот мы думаем что флудфил ближайший а он падла не отвечает" если предположить, что эти узлы работают на оригинальных i2pd/i2p java бинарниках, то это, всё-таки, проблема кода

Vort может идёт упор в какой-то ресурс (сеть, CPU, диск), а может и вообще явный баг где-то сидит (допустим, ответ уходит куда-то не туда)

orignal ну вот onon жаловался на межденныость поиска лизсета

orignal какие вариаеты решеия?

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

onon флудфил должен отвечать максимально быстро, а значит должен быть доступен максимально быстро

onon В идеале любой фф должен быть доступен напрямую из ipv4 & ipv6

onon Но так как это требование пока невыполнимо, можно сделать костыль в виде однохопового туннеля на каждом клиенте, построенного из ipv4&ipv6 роутера

onon Чтобы через него ipv4-only могли бы максимально быстро достучаться до ipv6 флудфила

segfault orignal: почему бы не послать сразу нескольким флудфилам и не воспринять ответ первого?

segfault orignal: только это надо делать опциональным, вдруг кто-то попытается атаковать сети, заполнив сеть множество флудфлов у которых ping будет ниже, чем у других

onon И наоборот ipv6-only до ipv4 флудфила

orignal onon ну вот даун он

orignal и некому ответить

orignal segfault а почему бы не помолчать?

onon Ну так если не отвечает, таймаут

onon И следующий

segfault orignal: а что плохого в этом варианте?

orignal onon так мы так и делаем но таймут там 5 секунд

onon Это слишком много

orignal ови предложения?

orignal segfault не надо считать себя самым умным, раз так сделано значит есть на то причина

orignal я предлагаю вот что

segfault orignal: а какая?

onon Если пинг у нас 250, можно сделать три ретрансмита

orignal запрашиваем флудфил

onon И через секунду смена

orignal если через секнду нет ответа запршиваем следующий

orignal а этот ждем 5 секунд

orignal кто первый встал того и тапки

orignal еесли вдруг первый ответит

segfault orignal: и как таймаут 1 сек для первого исправляет моё предложение

orignal segfault иди этим деду мозги еби

orignal ты заебал встречать в рузговор

orignal не по делу

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

orignal и осознать что собрался сказать хуйню

onon У нас сервера на разных континентах, естественно пинг до всех будет разный

orignal ну так че делать то?

onon Так годное предложение у тебя вроде

onon Лучше, чем просто ждать 5 сек

orignal и да если таймут у лучшего а все равно не нашли то попытаться снова

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

segfault а если делать сразу несколько запросов к случайным флудфилам, брать первый ответ, но гарантировать, что ответ от одного и того же флудфила не будет взят два (или более раз) подряд?

segfault то есть рандом будет, но в приоритете будут быстрые

onon У нас запрос идёт не к случайным флудфилам

onon А к тем, кто ближе по хешу

segfault ну это фактически случайный

orignal нет это не фактически случайный

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

segfault orignal: там же число меняется каждые сутки, если я правильно помню

orignal ой все

orignal спросил у деда насчет их таймаута

Vort "<~orignal> какие вариаеты решеия?" локализовать проблему надо вначале. потом о решениях думать

Vort "<~orignal> флудфил кстати может не отвечать просто потому что выключен в этот момент" ну вот надо узнать, как часто выключен, а как часто - глючит

orignal проблема что флудфил в этот момент даун

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

orignal а я думаю что вариант "глючат тоннели"

Vort в смысле "даун"? нету транспортной сессии?

onon А может в сети затор и большинство пакетов дропаются

Vort onon: в это можно было бы поверить были бы лаги по полсекунды допустим. но по 5-10 сек - тут можно сотню ретрансмитов успеть сделать

Vort но вообще могут быть конечно проблемы в сети. но это надо доказать как-то

Vort может кто X флаг на dial-up вкорячил. других идей нету )

onon Всё смешалось, люди, кони.

orignal даун просто выключен по какой то причине

onon Мы про direct или через туннели

orignal лизсеты всегда через тоннели

Vort orignal: типа с запросами RI иначе?

Vort или что там напрямик

Vort вот идея для анализа...

orignal там обычно напрямую

orignal если можно

orignal а лизсеты всегда тоннель

Vort стоит проверить, если через определённый фф лизсеты лагают, то будут ли лагать и RI

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

orignal это сразу деанон

onon Через туннели таймаут в 1 сек норм

onon Кмк

orignal понятно будет кто запрашиваетэ

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

orignal чтобы было непонятно что запрашивает лизсет

Vort "<~orignal> это сразу деанон" да я же про анализ говорю

Vort локализацию проблемы

Vort код пока что трогать не предлагаю

onon 1 сек это в верхней части диапазона для direct и в нижней части для 3хоп туннеля

onon Если никто не отвечает можно пробовать следующий

Vort создатся ощущение "заметания пыли под ковёр". но практично, да

unlike <Vort> может кто X флаг на dial-up вкорячил. других идей нету ). а разве узлы должны полагаться на флаги, а не на фактическую статистику?

unlike примерно как в https скорость постепенно повышается пока не пойдут потери

Vort unlike: ну вот сейчас и сделан бан лагающих флудфилов. но это мало помогает, потому что первоисточник проблемы не выявлен

Vort что касается проверки флага, то это очень-очень непросто

Vort полная информации о нагрузке узла есть только у этого самого узла

unlike но ведь в http это как-то реализовано. что он плавно заполняет весь канал

unlike точнее в tcp вроде. плаваю здесь немного

onon Да, это называется congestion control

onon Но при чем здесь это - не понятно

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

Vort unlike: ну вот, допустим, 64КБ/с канал плавно заполнен 1000 коннектами. на другой стороне скорость в 64 байта/сек не сильно будет отличаться от варианта "узел оффлайн"

Vort orignal: поэтому предлагаю проверить, насколько часто это случается по сравнению с вариантом "живой, но не совсем"

orignal возможно

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

unlike а что за история с лагающиме флудфилами? низкая скорость или большие потери, пинг?

onon Да с флудфилами проблема в том, что java и i2pd имеют о них разное представление

onon javai2p например считает занатовских флудфилов валидными

onon Что на мой взгляд совершеннейшая глупость

unlike т.е проблема политическая, а не техническая

onon И вот представь, сайт хостится на яве, и публикует свой лизсет на занатовских флудфилах, а клиент с i2pd пытается получить к нему доступ, но не может найти лизсет

unlike а через introducer нельзя?

unlike или это только для обычных пиров работает

onon Через интродьюсеров можно, вот только это сама по себе очень медленная процедура, а в некоторых случаях вообще не выполнимая

onon А нам нужно чтобы флудфилы были доступны максимально быстро

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

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

orignal на них реально высокая нагрузка

unlike а как тогда javai2p работает? через introducer?

orignal они не поднимают флудфил на U

orignal но они считают U за флудфилы

orignal а мы нет

orignal поднимать флудфил на U это дурость

unlike окей, считают. но как они с ними работают?

onon Через интродьюсеры

onon А как ещё?

onon Но как я выше указал, это очень медленно, а иногда вообще не возможно.

unlike но это лучше чем вообще никак, правильно?

onon В текущих реалиях - не правильно

unlike почему?

onon Потому что интродьюсер в данном случает получает нагрузку, сопоставимую с самим флудфилом

orignal плохой флудфил хуже чем его отсуствие

unlike тогда остается только политическая плоскость. уговорить всех перейти на i2pd или договориться с java developers

orignal не в этом главная проблема

unlike если вы не можете повлиять политически и при этом число роутеров javai2p составляет существенную часть сети то придеться делать как javai2p. иначе это вредит всей сети

orignal нет

onon Значит подождём, пока i2pd будет составлять большую часть сети

orignal проблема вовсе не в этом

unlike а в чем?

orignal читай выше

orignal что флудфил может не ответить а мы ждем слишком додго

unlike а как это в javai2p сделано? какие-там таймауты

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

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

orignal ну почему? можно например запрашивать 2 сразу можно запрашивать попторно

orignal можно по более сложному алгоритму

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

unlike но всеравно гадание

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

orignal onon считаем что он слишком медленный

onon А ты, что, считаешь иначе?

unlike чисто по вероятности нужно тогда сразу к нескольим флудфилам обращаться и брать самого быстрого. но это увеличит нагрузку на сеть

unlike за все надо платить

orignal сразу к нескольким это заведомо засирать всю сеть

orignal флудфилов и так то не хватает

Spirit90 Я правильно понимаю, что strchr пробегает по всей строке и просто находит нужный символ?

Gamma <Gamma> onon, orignal -

Gamma <Gamma> Why read crystals of useless truths?, [22.12.2024 22:37]

Gamma <Gamma> продумываю как в и2п гламурные аппы делать однокликовые чтоб клик и пашет

Gamma <Gamma> Why read crystals of useless truths?, [22.12.2024 22:37]

Gamma <Gamma> это придётся свой форк и2пд кодить

Gamma <Gamma> он будет называться i2pd-component

Gamma <Gamma> orignal я думаю не потерпит таких нововведений в и2пд

Gamma <Gamma> чтобы без .conf файлов совсем.

Gamma <Gamma> умело чтоб так

Gamma ну и ещё easy to operate daemons

orignal Spirit90 это канал о разработке i2pd а не обучении нубов программированию

Gamma вторая purpose

Spirit90 orignal: зачем так? Мне хочется вам помочь в разработке...

segfault Spirit90: что мешает прочитать man strchr? зачем тратить время других людей?

trust Blinded message

tetrimer_ Получилось снять более менее разумную корку при shutdown на FreeBSD.

tetrimer_ Reading symbols from /usr/local/bin/i2pd-g39954480...

tetrimer_ [New LWP 109548]

tetrimer_ warning: Could not load shared library symbols for [vdso].

tetrimer_ Do you need "set solib-search-path" or "set sysroot"?

tetrimer_ Core was generated by `/usr/local/bin/i2pd --pidfile /var/run/i2pd/i2pd.pid --service --datadir /var/db'.

tetrimer_ Program terminated with signal SIGABRT, Aborted.

tetrimer_ Sent by thr_kill() from pid 8460 and user 255.

tetrimer_ #0 0x00000008286c154a in thr_kill () from /lib/libc.so.7

tetrimer_ (gdb) bt

tetrimer_ #0 0x00000008286c154a in thr_kill () from /lib/libc.so.7

tetrimer_ #1 0x000000082863b414 in raise () from /lib/libc.so.7

tetrimer_ #2 0x00000008286eb326 in abort () from /lib/libc.so.7

tetrimer_ #3 0x00000000004dfcbe in __clang_call_terminate ()

tetrimer_ #4 0x0000000000709703 in boost::detail::sp_counted_impl_pd<std::__1::array<std::__1::shared_ptr<i2p::data::RouterInfo::Address>, 5ul>*, std::__1::__bind<void (i2p::util::MemoryPoolMt<std::__1::array<std::__1::shared_ptr<i2p::data::RouterInfo::Address>, 5ul> >::*)(std::__1::array<std::__1::shared_ptr<i2p::data::RouterInfo::Address>, 5ul>*),

tetrimer_ i2p::util::MemoryPoolMt<std::__1::array<std::__1::shared_ptr<i2p::data::RouterInfo::Address>, 5ul> >*, std::__1::placeholders::__ph<1> const&> >::dispose (

tetrimer_ this=0x850587420) at /usr/local/include/boost/smart_ptr/detail/sp_counted_impl.hpp:179

tetrimer_ #5 0x0000000000518740 in boost::detail::sp_counted_base::release (this=0x850587420) at /usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_atomic.hpp:120

tetrimer_ #6 0x00000000005186ea in boost::detail::shared_count::~shared_count (this=0x85a51ecf8) at /usr/local/include/boost/smart_ptr/detail/shared_count.hpp:432

tetrimer_ #7 0x00000000005106d9 in boost::shared_ptr<std::__1::array<std::__1::shared_ptr<i2p::data::RouterInfo::Address>, 5ul> >::~shared_ptr (this=0x85a51ecf0) at /usr/local/include/boost/smart_ptr/shared_ptr.hpp:336

tetrimer_ #8 0x00000000006fc70b in i2p::data::RouterInfo::~RouterInfo (this=0x85a51ecb8) at libi2pd/RouterInfo.cpp:84

tetrimer_ #9 0x00000000006a09e7 in _ZNSt3__112__destroy_atB8se180100IN3i2p4data10RouterInfoETnNS_9enable_ifIXntsr8is_arrayIT_EE5valueEiE4typeELi0EEEvPS5_ (__loc=0x85a51ecb8) at /usr/include/c++/v1/__memory/construct_at.h:67

tetrimer_ #10 0x00000000006a09b9 in std::__1::allocator_traits<std::__1::allocator<i2p::data::RouterInfo> >::destroy[abi:se180100]<i2p::data::RouterInfo, void, void>(std::__1::allocator<i2p::data::RouterInfo>&, i2p::data::RouterInfo*) (__p=0x85a51ecb8) at /usr/include/c++/v1/__memory/allocator_traits.h:316

tetrimer_ #11 0x00000000006a097e in _ZNSt3__120__shared_ptr_emplaceIN3i2p4data10RouterInfoENS_9allocatorIS3_EEE21__on_zero_shared_implB8se180100IS5_TnNS_9enable_ifIXntsr7is_sameINT_10value_typeENS_19__for_overwrite_tagEEE5valueEiE4typeELi0EEEvv (this=0x85a51eca0) at /usr/include/c++/v1/__memory/shared_ptr.h:284

tetrimer_ #12 0x00000000006a0805 in std::__1::__shared_ptr_emplace<i2p::data::RouterInfo, std::__1::allocator<i2p::data::RouterInfo> >::__on_zero_shared (this=0x85a51eca0) at /usr/include/c++/v1/__memory/shared_ptr.h:287

tetrimer_ #13 0x00000000004e7a51 in std::__1::__shared_count::__release_shared[abi:se180100]() ( this=0x85a51eca0) at /usr/include/c++/v1/__memory/shared_ptr.h:157

tetrimer_ --Type <RET> for more, q to quit, c to continue without paging--

tetrimer_ #14 0x00000000004e79f9 in std::__1::__shared_weak_count::__release_shared[abi:se180100]() ( this=0x85a51eca0) at /usr/include/c++/v1/__memory/shared_ptr.h:186

tetrimer_ #15 0x00000000005d3cfc in std::__1::shared_ptr<i2p::data::RouterInfo const>::~shared_ptr[abi:se180100]() (this=0x860366730) at /usr/include/c++/v1/__memory/shared_ptr.h:648

tetrimer_ #16 0x0000000000697bb7 in _ZNSt3__112__destroy_atB8se180100INS_10shared_ptrIKN3i2p4data10RouterInfoEEETnNS_9enable_ifIXntsr8is_arrayIT_EE5valueEiE4typeELi0EEEvPS8_ (__loc=0x860366730) at /usr/include/c++/v1/__memory/construct_at.h:67

tetrimer_ #17 0x0000000000697b79 in std::__1::allocator_traits<std::__1::allocator<std::__1::shared_ptr<i2p::data::RouterInfo const> > >::destroy[abi:se180100]<std::__1::shared_ptr<i2p::data::RouterInfo const>, void, void>(std::__1::allocator<std::__1::shared_ptr<i2p::data::RouterInfo const> >&, std::__1::shared_ptr<i2p::data::RouterInfo const>*) (__p=0x860366730)

tetrimer_ at /usr/include/c++/v1/__memory/allocator_traits.h:316

tetrimer_ #18 0x0000000000697b38 in std::__1::vector<std::__1::shared_ptr<i2p::data::RouterInfo const>, std::__1::allocator<std::__1::shared_ptr<i2p::data::RouterInfo const> > >::__base_destruct_at_end[abi:se180100](std::__1::shared_ptr<i2p::data::RouterInfo const>*) (this=0xa2a148 <i2p::data::netdb+552>, __new_last=0x860364800) at /usr/include/c++/v1/vector:926

tetrimer_ #19 0x0000000000697a48 in std::__1::vector<std::__1::shared_ptr<i2p::data::RouterInfo const>, std::__1::allocator<std::__1::shared_ptr<i2p::data::RouterInfo const> > >::__clear[abi:se180100]() ( this=0xa2a148 <i2p::data::netdb+552>) at /usr/include/c++/v1/vector:920

tetrimer_ #20 0x00000000006979dd in std::__1::vector<std::__1::shared_ptr<i2p::data::RouterInfo const>, std::__1::allocator<std::__1::shared_ptr<i2p::data::RouterInfo const> > >::__destroy_vector::operator()[abi:se180100]() (this=0x82132c960) at /usr/include/c++/v1/vector:490

tetrimer_ #21 0x0000000000692017 in std::__1::vector<std::__1::shared_ptr<i2p::data::RouterInfo const>, std::__1::allocator<std::__1::shared_ptr<i2p::data::RouterInfo const> > >::~vector[abi:se180100]() ( this=0xa2a148 <i2p::data::netdb+552>) at /usr/include/c++/v1/vector:501

tetrimer_ #22 0x00000000006802d9 in i2p::data::NetDb::~NetDb (this=0xa29f20 <i2p::data::netdb>) at libi2pd/NetDb.cpp:51

tetrimer_ #23 0x00000008286eb6ff in __cxa_finalize () from /lib/libc.so.7

tetrimer_ #24 0x00000008286ebc31 in exit () from /lib/libc.so.7

tetrimer_ #25 0x00000000004dc427 in _start (ap=<optimized out>, cleanup=<optimized out>) at /usr/src/lib/csu/amd64/crt1_c.c:71

tetrimer_ Блин, хотел ссылку кинуть. Прошу прощения.

tetrimer_ privatebin.i2p/?a5171e2a94128d85#34XLZaWuDS6NCe3BATQiwkrHfWvQwiXXtQWexSf81Dnp

orignal спс

orignal починю

R4SAS-hex-ilita скоро запустится

R4SAS вроде всё

orignal дед сказал у них 3 секунды

orignal такой вопрос: ставим ли для роутеров через тор букву H?

orignal un твое мнение?