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

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

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

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

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

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

Vort короч над UX стоит поработать

` Можно пофлудить, пэжэ?

` MIT или AGPLv3? И почему?

Leopold в mit нет копилефта, а в афферо есть

orignal Vort я нашел в чем дело

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

orignal потому роутры выкидывались

orignal я уже это исправил

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

orignal если только что стартовали то и старые RI принимать

orignal я тут сообразил что есть бага с пит тестом

orignal теперь получаются ложрные Firewalled

orignal буду чинить

Vort они были всегда

Vort я тебе об этом больше года говорю

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

Vort одну часть ты (надеюсь) починил

Vort осталась вторая

orignal проблема именно из-за моей починики

orignal боб мне отвечает что придет тест от чарли

orignal я ставлю Firewalled

Vort то есть Firewalled теперь дважды глюченый? :)

orignal он приходит да не от того

orignal ну типа да

orignal счас починю

Vort по-нормальному переделывать всё ещё не хочешь?

Vort от этого места веет "техническим долгом"

orignal а по нормальному это как?

orignal предлагай

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

Vort во-первых, нужно скрыть внутреннее состояние теста от юзера и от внешнего кода, принимающего решения на его основании

orignal то есть статус теста отдельный

orignal хорошо

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

Vort сейчас же можно по сути два теста одновременно запустить

orignal логично

orignal подумаю

Vort ну и, в-третьих, нужно больше попыток, да. точнее, столько, сколько нужно

orignal а если Firewalled то что?

Vort попробую получше сформулировать свою идею

Vort предлагаю после начала теста складывать ответы на запросы во внутреннее хранилище. затем в процессе теста решать - или нужно отсылать дополнительные запросы или завершать тест с каким-то определённым внешним результатом

Vort в случае когда внутреннее состояние намекает на Firewalled исход - надо чуть больше тестов делать, чтобы надёжнее убедиться в том, что это действительно так

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

Vort пока идёт тест, внутри можно менять состояние сколько угодно

orignal я думаю надо полагаться на предыдйщую итсорию

Vort можно и так, но это уже ближе к оптимизации

Vort сейчас же важна надёжность и чёткость

Vort помнишь ты предлагал отправку запросов с изменяющейся задержкой? вот это тоже стоит сделать

orignal да. надо

orignal на самом деле там все не так плохо

orignal просто будет считаться такой тест как не дошедший и все

Vort это о каком конкретно сценарии речь?

orignal приходит от боба сообшние 4

orignal мы ставим Firewalled

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

orignal и не трогаем

orignal так и остается в этом тесте Firewalled

orignal по уму бы надо ставить Unknown

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

Vort ну вот поэтому результат теста формировать надо не по одному из ответов, а на основании анализа всей пачки

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

Vort а если по одному ответу выходит OK при том, что по 9 оставшимся Firewalled, то нафиг такой ОК результат нужен. надо Firewalled ставить

onon Почини SSU2 - не будут теряться пакеты - будет сильно меньше проблем с пиртестом.

Vort по поводу Unknown: мне интуитивно кажется, что надо от этого статуса избавляться. он логичен разве что при старте узла

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

Vort onon: теряться пакеты будут всегда. узлы в оффлайн уходить будут. дырки в NAT иногда будут жить дольше обычного

Vort нужно повышать надёжность с тем, что есть сейчас

Vort это вполне реально

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

Vort потратить на него в 2-5 раз больше ресурсов - не проблема вообще

orignal ну вот я начал рефакторинг

orignal разнести пиры тесты 1-4 и 5-7 по разным структорам

orignal не согласен если из 10 9 Firealled in 1 OK то скорее всего у тебя сеть глючная

orignal там вообще надо ни то ни другое

orignal а SSU отклюать ))

onon Надо в таком случае Fireawlled ставить, чтобы другие не пытались к тебе стучаться

orignal неее

orignal к тебе же и через интродьюсеры скорее всего не смогут

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

onon Это вроде доступен, но только с определённых IP? Тогда нужно ставить статус Stan

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

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

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

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

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

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

Vort "<@onon> Это вроде доступен, но только с определённых IP? Тогда нужно ставить статус Stan" особенность в том, что блокировки IP адресов обычно двусторонние. так что недоступность будет как с одной стороны "стены", так и с другой

Vort другими словами, сейчас в любом месте Земли можно найти недоступные IP адреса

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

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

orignal соотвествующие функции IsLimitedConnectivity

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

Vort то есть, как минимум, нужен какой-то порог для классификации

Vort а для этого - опять же - измерение "нормы"

orignal именно так

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

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