transmission: заметное падение кол-ва коннектов после автосмены IP-адреса провайдером

Латентность DHT и период обновления инфы на трекерах.

софт анонсит адрес, который он определил в момент своего старта, и больше не проверяет его повторно?

DHT отключена.

и период обновления инфы на трекерах.

Сколько дней для этого нужно? Речь идёт именно о том, что если не перезапустить, то трафик никакой. Да и с «днями» проблема: ведь через уже 24 часа айпи снова поменяется.

софт анонсит адрес, который он определил в момент своего старта, и больше не проверяет его повторно?

Тогда бы трафик свалился бы в 0. И было бы всё просто: или чёрное, или белое. А тут какая-то «магия». И вот решил я наконец-то с этим разобраться. Ведь на самом деле должно быть техническое объяснение или ошибка где-то.

А разве в анонсе есть адрес? Трекер же сам видит, от кого анонс пришёл.

Тогда бы трафик свалился бы в 0

может тебе достался ip-адрес, который только что был у другого «качка»

А разве в анонсе есть адрес? Трекер же сам видит, от кого анонс пришёл.

ну, я деталей не знаю, на ходу строю теорию под озвученные «факты»; к примеру, я не знаю, какой будет ip-src у тех пакетов, которые уйдут через сокет, который был создан с прежним адресом на интерфейсе, а может там на каждый анонс новый сокет создается

может тебе достался ip-адрес

Ну, по прошествии нескольких часов ситуация не меняется. Значит, дело не в этом.

а может там на каждый анонс новый сокет создается

Я уже рылся в исходниках. К моему удивлению, похоже, используется curl. А, значит, каждый анонс отдельно. Странно, если при запуске на один трекер надо сообщить о нескольких сотнях торрентах да ещё и по https, так это ж просто ужас для каждого анонса дёргать curl. Хотя, может, кто ещё копал?

Отваливаются входящие соединения (их можно определить по флагу I), но остаются исходящие, может быть?

Период обновления к примеру 30 минут (тот же рутрекер).

За минуту до смены адреса качалка сообщает, что у нее такой-то адрес и столько-то скачено-отдано.

Адрес меняется.

Следующие 30 минут трекер будет отдавать старый адрес. И еще столько же примерно будут пиры, которые в эти 30 минут обращались к трекеру и получали инфу о старом IP-адресе.

DHT отключена.

ССЗБ

При перезапуске качалка анонсирует все торренты.

Это можно будет проверить. Т.е. клиент, чтобы раздавать, может и сам к кому-то подсоединиться (что происходит значительно реже)?

И, кстати, попутный вопрос. Одни соединения идут по случайному порту, что я и ожидаю. А другие - по тому единственному открытому через nat на вход. Вроде как он должен был бы использоваться только для установки соединения, которое потом идёт по случайному tcp порту, не? А в netstat можно как-то получить инфу, кто инициатор соединения?

Ну, по прошествии нескольких часов ситуация не меняется. Значит, дело не в этом.

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

И еще столько же

Так и я об этом. Проблема в чём-то другом.

DHT отключена.

ССЗБ

И что? От этого проблема не исчезнет, а будет замаскирована.

При перезапуске качалка анонсирует все торренты.

Точно так же, как и каждые 20-50 минут. А эффект наблюдаю разный.

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

Это был жирный баг, который, наверняка бы, уже заметили. Я исхожу из того, что если трекер сообщает рекомендуемый интервал анонса в столько то минут, то как раз через вот этот интервал + ещё немножко он пира и удалит. Именно это я наблюдаю: после рестарта клиента некоторое время висит двойное кол-во торрентов.

А вот если пир присылает анонс с тем же ID, но уже с другого айпи, то в статистике он значится как тот же (новый пир не появляется, старый пир не удаляется), а вот айпишник-то нужно действительно обновить! Хм, вот это может быть точно этот старый-престарый баг.

Ростелеком? ССЗБ. Мало того что трансмиссия до сих пор медленно разгоняется на отдачу, так еще и трекеры запоминают старые параметры (IP, порт). Я полгода назад сменил адрес торрент-качалки, так до сих пор куча запросов приходит на старый адрес, 2/3 всех реджектов.

представь, что несколько пиров достались тебе по «наследству» от предыдущего владельца ip-адреса, а все новые пиры подключиться уже не могут из-за неверной инфы на трекере вследствие какой-то ошибки; при этом те удачные пиры могут работать с тобой сколь угодно долго, т.к. у них о тебе есть корректная инфа (чанки же качаются), и никакой трекер со своей кривой инфой (или ее отсутствием) о тебе их сбить не может; дальше эти удачные пиры по DHT могут сообщать о тебе другим пирам дефицитную корректную инфу, при этом включенность/выключенность DHT у тебя этому процессу ортогональна

Ростелеком?

Нет.

так еще и трекеры запоминают старые параметры (IP, порт)

Если дольше нужного или без резонного обновления, вот это был баг, с которым надо бороться.

Я полгода назад сменил адрес торрент-качалки

Статический IP?

так до сих пор куча запросов приходит на старый адрес

И старый статический по-прежнему твой? Мой опыт показывает, что инфа хранится до перезапуска клиента. Чтобы другие клиенты по полгода помнили айпи... ничего себе, это ж не mule!

Каждые 24 часа происходит автоматическая смена IP-адерса провайдером

Но зачем?

Да, спасибо за дискуссию: где-то так, скорее всего, и есть. Вот только так не хочется поднимать у себя tbdev на пых-пыхе да с sql, чтобы это окончательно проверить. Да и что случилось с ним: обновлений уже несколько лет нет? А на чём же тогда главный трекер шестой части суши работает? По крайней мере в старых исходниках, как вижу, если не ошибаюсь, айпишник действительно устанавливается один раз и не обновляется. Во дают.

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

угу, самому было интересно поразмышлять...

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

Как же не сообщил имени? В заголовке вопроса. А вот версия: последний коммит в svn на вчера, и 2.84 из дебиана тоже.

А как же если проблема не с трекером? Клиент делает анонс уже с другого адреса, трекер видит, что такой пир у него уже есть, обновляет статистику, но не обновляет айпишник, так что другим пирам будет по-прежнему сообщаться недействительный.

Единственная возможность для клиента (без перезагрузки программы): это остановить все торренты, и запустить их заново.

Можно предположить, что это из соображений безопасности (которая без https, да и вообще с данными в url - её просто нет). Но тогда было бы логично сверять ID клиента с айпишником, и сообщать об ошибке, если не совпадают. Возможно, на заре создания был (и есть?) какой-то популярный случай, для которого необходимо вот такое поведение: сохранять валидность пира, который анонсит с другого айпишника, но при этом игнорировать этот айпишник?

не понимаю, как трекер может различить анонсы от клиента после смены у него ip-адреса в двух случаях: без перезагрузки сервиса и после перезагрузки, чтобы в одном случае действовать криво, а в другом — верно?

поэтому, думаю, что бага/фича скорее всего все же в клиенте

У рутрекера свой кастомный движок на основе мода phpbb. На старой его версии еще порнолаб работает и вроде фриторрент. Одно время кодом делились, но из-за чего-то там это дело прикрыли.

без перезагрузки сервиса и после перезагрузки

Будет достаточно остановить торрент и запустить его снова. Анонс - это простой http запрос, айпишник которого получается стандартными средствами (протокол bittorrent тут не причём). При анонсе трекер (судя по исходнику) ищет, не зарегистрирован ли уже этот пир-ID, если нет - то добавляет его (включая айпишник), а если уже зарегистрирован, то идёт в else, а там есть обновление статистики, но нет обновления айпишника. Т.е., чтобы попасть в if необходим или успешный останов и перезапуск торрента или смена пир-ID путём перезапуска клиента.

поэтому, думаю, что бага/фича скорее всего все же в клиенте

Это было бы проще: ведь трекеров - куча. Просить каждого об обновлении, дело будет не простое. И каждый будет подозревать о том, что этот фикс будет ослаблять безопасность.

на основе мода phpbb

Так это же форум. А целый трекер как мод к форуму?

но из-за чего-то там это дело прикрыли.

Бекдоры вставили? Иначе, что там скрывать?

разве пир-id — это не постоянный id, привязанный к логину? он меняется с каждым запуском клиента?

похоже смена адреса пира просто не предусмотрена в логике работы трекера; это или фича или UB

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

Т.е. клиент, чтобы раздавать, может и сам к кому-то подсоединиться (что происходит значительно реже)?

Вполне может, наверное. За NATом же раздача как-то примерно так и идёт, например. И потом, разделяются ли вообще соединения с точки зрения клиента на те, что предназначены для раздачи, и те, что для загрузки? По одному и тому же соединению ведь может и то, и другое происходить. Ну и надо полагать, что клиент реже сам подсоединяется к кому-то именно по той причине, что эти «кто-то» могут находиться за тем самым провайдерским NATом без возможности принимать входящие соединения.

Одни соединения идут по случайному порту, что я и ожидаю. А другие - по тому единственному открытому через nat на вход. Вроде как он должен был бы использоваться только для установки соединения, которое потом идёт по случайному tcp порту, не?

Хммм... А разве входящие соединения не должны как раз приходить на порт, указанный в настройках клиента (если он доступен снаружи, конечно же), в то время как исходящие должны открываться со случайного порта? Вот как раз таким образом их и можно различать, если я правильно понимаю.

пир-id

К логину (в смысле к учётной записи, а не к логину на web-интерфейсе трекера, который через куки) привязан только passkey. А пир-id - это строка из id клиента + рандом для текущей сессии.

это или фича или UB

Вот-вот. Тут нужен писатель этих трекеров, чтобы понять, было ли так задумано по какой-то веской причине, или это можно без проблем пофиксить.

повесить триггер на смену адреса сетевого интерфейса

Вот это не так просто: т.к. адрес меняется в роутере. Было бы здорово, если бы он мне за 5 минут сообщал, что щас как возьмёт, да и сменит адрес. Но такого там нет. Можно пробовать искать свободную прошивку, но и там этого скорее всего в готовом виде нет. Пока удалось найти только велосипеды с правкой скриптов в роутере с добавлением поллинга через cron. Просто обидно останавливать торренты из-за этого. Хоть бери да и патчь клиент, чтобы он по новой команде слал stop/start анонсы, не разрывая существующих соединений с пирами. Хм, вот это было бы неплохо реализовать, и после того, как роутер точно поменял адрес, вызывать (промежуток с точностью до целого часа вместо чего-нибудь помельче).

Да, трекер - это мод к форуму.

Вот это не так просто: т.к. адрес меняется в роутере.

есть же в инете сайты, определяющие твой IP

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

Я ищу что-то без поллинга и тем более без использования сторонних ресурсов.

про ip можно роутер спрашивать

И старый статический по-прежнему твой?

Внешний белый IP не изменился, изменился открытый порт, который ведет на другой серый IP домашней подсети. И да, на старый порт, ныне закрытый, до сих пор все долбятся, а он использовался только для торрентов.

Ограниченное кол-во соединений. Клиент держит старые открытыми до последнего, хотя они уже не работают по причине смены адреса. А на другом конце фаерволл отбрасывает левые пакеты, поэтому завершить эти соединения нормально не получается.

За NATом же раздача как-то примерно так и идёт, например.

Тут надо определиться: за NATом находятся, думаю, практически все. А вот за NATом с закрытыми портами - нет. Т.е. проблема возникает в последнем случае. Я сейчас рассматриваю только аплоад с моей стороны, а вот если бы мне нужно было что-то загрузить, а та сторона за NAT (с закрытым портом), то облом. Трекер посылает пиры, которым что-то нужно. Дальше, наверное, тот удалённый клиент, зная, что порт закрыт, и никто у него сам по себе не может качать, сам контактирует тех, кому что-то нужно. Но у меня порт открыт, значит, такой сценарий быть не может. Но, может, есть ещё случаи, когда устанавливается исходящее соединение?

Интересно, как бы так проследить, как точно устанавливаются эти соединения. Вот сейчас подёргал netstat и заметил:

tcp        0      0 PRIVATE_IP:SOME_PORT_1   PUBLIC_IP:NAT_PORT      ESTABLISHED -                   
tcp        0      0 PRIVATE_IP:NAT_PORT      PUBLIC_IP:SOME_PORT_1   ESTABLISHED -

Вот как раз таким образом

Да, получается вопрос наоборот: что это за соединения с рандомным портом. Надо заглянуть в bittorrent протокол: если удалённый пир получил меня, а я получил его, то соединение инициирует тот, кто первый, вместо того, чтобы мой клиент просто ждал соединений (т.к. он знает, что порт открыт и проблем нет)?

Ещё видно кучу SYN_SENT с рандомных портов.

Кстати, подёргав netstat ещё видно, что трансмиссия, бывает, открывает дюжины соединений с 80-ым портом каких-то серверов CloudFlare, privatelayer panama. С чего бы это?

Но зачем?

Например, чтобы генерировать эпические звонки клиентов техподдержке.

Ограниченное кол-во соединений. Клиент держит старые открытыми до последнего

Только, если он ни пишет, ни читает. Т.к. иначе при неудачной попытке пообщаться работу по уборке выполнит ядро. В netstat не видно, чтобы висели эти соединения.

поэтому завершить эти соединения нормально не получается.

А в этой стадии, значит, соединения уже накрылись и будут завершены локально принудительно по истечении TCP/IP таймаута в ядре.