Vort
orignal: хочешь опечатку поправить? ResetFlooldFill () в RouterInfo.h
Vort
R4SAS: похоже, у reseed-fr.i2pd.xyz перестал работать IPv6 адрес (2001:470:1f13:e56:e0f::333). не пингуется. можешь проверить?
Vort
по поводу рейта: я перепроверил свои данные и ещё раз сделал тест и, похоже, вот это почти верно: "<onon> Имхо, потому что когда транзит, большинство узлов в твоей БД - занатовцы."
Vort
большинство или не большинство, но у узла, который имеет в netdb в 2 раза меньше U узлов, рейт в 2 раза выше
Vort
"<onon> Потому что это они строят через тебя туннели и занимают весь объём БД" - не так всё просто. R узлы тоже туннели через мой узел строят
orignal
поправлю
orignal
я думаю еще вот что
orignal
занатовцы к тому же часто первый хоп потому что при сами поключены когда много трназита
orignal
кстати еще одно наблюдение
orignal
на чистом ipv6 рейт не падает
orignal
хотя транзит есть
orignal
потому что узлы не концевые
Vort
про первый хоп - верно. U висят в пирах и этим самым держат RI в базе. что само по себе нормально, но даёт определённый эффект
Vort
"<~orignal> на чистом ipv6 рейт не падает" - может, у U узлов редко ipv6 бывает?
orignal
да но тоннель дальше же может быть с U
orignal
то есть первый хоп по ipv6 дальше у того пира есть еще и 4
Vort
так а как U узлы в пирах появляются? они же наверно сами к нам приходят?
orignal
следущбгий вполне может быть U а конец уже R
orignal
зондированием
orignal
да кстати это мысль
Vort
"<~orignal> зондированием" вот не думаю
orignal
что они к нам не подключаеются
orignal
хотя комбинация интродьюсеров по ipv4 и адерс по ipv6 довольно частая
Vort
я сейчас держу два узла для тестов - XfR и XRG. рейты 13% и 33%
orignal
ну с f то понято почему
orignal
туда прет вообще весь шлак
Vort
кстати, похоже, я понял, почему у f больше U
Vort
нефлудфил ведь не так активно чистит netdb?
Vort
я опять забыл механизм :/
Vort
короч если нефлудфил чистит реже, то у него R узлы в базе задерживаются дольше, чем U
Vort
так как у U срок годности не больше часа, а у R - и сутки может быть
orignal
на нефлудфиле зависит от размера нетдб
orignal
а флудфил выкидывает через час
orignal
иногла даже черз полчаса
orignal
неее для U свое правило
orignal
там вроде выкидывается через час
Vort
Routers: 2836 - какое может быть среднее время жизни R RI?
orignal
надо уточноить
orignal
посмотри по коду в Netdb.cpp
Vort
NETDB_NUM_ROUTERS_THRESHOLD выставлена в 6000
orignal
это касается получасовой очистки
Vort
я пока не понял, как там сделано, но чую, что этот механизм вполне может быть ответственен за пропорции R / U
Vort
NETDB_MIN_EXPIRATION_TIMEOUT*1000LL + (NETDB_MAX_EXPIRATION_TIMEOUT - NETDB_MIN_EXPIRATION_TIMEOUT)*1000LL*NETDB_MIN_ROUTERS/total
Vort
вот это значит тогда
orignal
expirationTimeout = i2p::context.IsFloodfill () ? NETDB_FLOODFILL_EXPIRATION_TIMEOUT*1000LL :
orignal
NETDB_MIN_EXPIRATION_TIMEOUT*1000LL + (NETDB_MAX_EXPIRATION_TIMEOUT - NETDB_MIN_EXPIRATION_TIMEOUT)*1000LL*NETDB_MIN_ROUTERS/total;
Vort
(5400+(97200-5400)*90/2836)/3600 = 2.3 часа
Vort
получается, чем выше нагрузка у узла, тем быстрее чистятся R узлы из netdb
Vort
ну а U узлы протухают за константное время
Vort
"orignal чем больше роутеров в нетдб тем ниже рейт ))"
orignal
почему?
orignal
если U долго не обновлялся также вылетит
orignal
надо поизучать код с протухаием U
Vort
ну допустим время протухания - 10 часов
orignal
возможно опять мой косяк
Vort
R так и провисит 10 часов
Vort
а U через час протухнет
orignal
правильно а U вылетит
Vort
ну вот, видишь, как пропорция меняется?
Vort
R / U
Vort
в зависимости от expirationTimeout
Vort
а expirationTimeout зависит от размера netdb
Vort
то есть, для нефлудфила пропорция R / U зависит от размера netdb
orignal
все понял твою мысль
orignal
чем больше размер тем больше доля U
Vort
ага
orignal
надо продумать вопрос этот
Vort
универсальное решение, конечно, это добавлять в протокол SSU2 второй keepalive, не обновляющий активность
orignal
причем отдельным сообщением
orignal
типа HolePunch
orignal
я придумал
orignal
если флудфил то клиентские тоннели строить только через R
orignal
ну не буквально через R а которые достижимы напрмую
Vort
"достижимы напрямую" - это как? либо в списке пиров и первый хоп, либо R?
Vort
проблема просто, как я понимаю, в том, что транспортное соединение вроде бы есть, но как только надо туда тыкать данные, то оказывается, что его как бы и нет уже
orignal
когда IP есть
orignal
хоть какой то
orignal
и второй может соединиться по этому ip
Vort
так а с первым хопом что? вот есть с ним транспортный коннект. не использовать просто потому, что это U узел?
Vort
вероятно, я неправильно понял идею
orignal
первый использовать как есть
orignal
если исходящий
orignal
если входящий то не использовать
Vort
подозреваю, что проблемы могут быть из-за того, что дырка протухает, а мы об этом не знаем
Vort
и построение туннеля уходит вникуда
Vort
тут флудфил или не флудфил - не сильно важно
orignal
у меня еще лучше идея
orignal
делать это когда болье 6K роутеров
Vort
как временное решение - можно. только проверить, даст ли это на практике вообще хоть какое-то улучшение
Vort
а вообще, с zzz обсуждать доработку SSU2 надо. но с этим я мало чем помочь могу
orignal
а что там?
Vort
ну новый keepalive
Vort
чтобы U
Vort
у них, конечно, проблемы не только с протуханием дырки
orignal
а ну да
orignal
поговорю
Vort
потом можно будет придумать инструменты для измерения времени жизни дырки и настроить правильно интервал keepalive
Vort
а для начала хоть какой-то поставить
Vort
orignal: пакеты для удержания дырки, как я понимаю, предназначены для промежуточного роутера с NAT, а не для узла назначения
Vort
может, подойдёт вообще что угодно, к примеру, нулевой размер?
Vort
в i2pd в SSU2Server::ProcessNextPacket такой пакет выкинется по if (len < 24) return;
Vort
как java отреагирует - не знаю
orignal
неее нуль нельзя
Vort
ну и хз что там по поводу безопасности - может, такие пакеты будут выделяться
orignal
палево сразу
Vort
понятно
orignal
а вот HolePunch вполне