Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
Помоему пропущен важный шаг: выяснить, что это за адрес, зачем туда стучится клиент, и к каким последствия приведет его вырезание.
Последствий никаких, без него качается нормально. Один из адресов должен использоваться внутри локальной сети для поиска локальных пиров, но не во всех сетях есть такие трекеры. А что делает другой адрес — для меня осталось загадкой, возможно это дублирующий трекер, на случай подения первого.
Все должны помнить историю с отбиранием домена torrents.ru
Помню даже была тема по массовому добавлению анонса bt*.rutracker.org ко всем раздаваемым торрентам, чтоб трекер работал и учитывал отдачу.
Так вот, два анонс урла в зонах .org и .net нужны чтобы при проблемах с одним из них, по второму бы все уже скаченные и раздаваемые торренты работали бы.
Помню даже была тема по массовому добавлению анонса bt*.rutracker.org ко всем раздаваемым торрентам, чтоб трекер работал и учитывал отдачу.
Так вот, два анонс урла в зонах .org и .net нужны чтобы при проблемах с одним из них, по второму бы все уже скаченные и раздаваемые торренты работали бы.
А разве поиск локальных пиров идет не через retracker.local/announсe?
retracker.local — это ретрекер, который используется для поиска локальных пиров (разумеется, при условии, что в вашей локальной сети поднят некий ретрекер, и на DNS-сервере в локальной сети поднята зона local и в ней прописана запись retracker.local, которая указывает на этот сервер с ретрекером).
А ix*retracker.net, как я понял, это тоже ретрекер, но он используется, как и сам трекер bt*.retracker.org, для поиска внешних пиров в инете. В отличие от трекера он не учитывает статистику файлообмена, а просто помогает пирам найти лруг-друга. В мирное время он просто разгружает сам трекер. А в случае блокировки регистратором доменного имени (как было с torrents.ru) позволит пирам продолжать файлообмен.
А ix*retracker.net, как я понял, это тоже ретрекер, но он используется, как и сам трекер bt*.retracker.org, для поиска внешних пиров в инете. В отличие от трекера он не учитывает статистику файлообмена, а просто помогает пирам найти лруг-друга. В мирное время он просто разгружает сам трекер. А в случае блокировки регистратором доменного имени (как было с torrents.ru) позволит пирам продолжать файлообмен.
Я про него и говорил, рутрекер отдает 3 трекера в раздаче — главный, ix и локальный.
Кстати, по поводу имени retracker.local и соответственно DNS-зоны .local на DNS-сервере в локальной сети.
Я категорически против, чтобы для внутрилокальных bittorrent-ретрекеров в torrent-файл добавлялся такой announce-URL. Т.е. я не против добавления туда URL ретрекера вообще, но просто имя (а точнее зону) для этого универсального локального ретрекера следовало выбрать другое. Сделали бы имя в некой зоне bittorrent (например, retracker.bittorrent) или в зоне retracker (bittorrent.retracker) или ещё в какой-то уникальной нигде не зарезервированной зоне. Но имя в зоне .local выбрали совершенно напрасно.
И очень жаль, что администраторы rutracker.org (torrents.ru) повелись на это предложение. А глядя на них администраторы ряда других трекеров сделали так же, а администраторы локальных сетей создали зону .local с этой записью в локальных DNS.
Проблема в том, что зона .local в протоколах разрешения имён уже была ранее зарезервирована совсем для других целей.
В реализациях технологии Zeroconf от Apple (Bonjour) и в реализациях этой технологии, используемой в Linux/BSD, (Avahi) для разрешения имён хостов и сервисов в локальной сети без DNS-сервера используется связка протоколов mDNS (multicast DNS) и DNS-SD. И в протоколе mDNS как раз зарезервировано, что имена хостов в некой псевдо-зоне .local должны разрешаться клиентами не через классические запросы к DNS-серверу, а именно мультикастом по протоколу mDNS. И клиенты с Mac OS X, Linux и *BSD именно так и поступают, если у них установлена поддержка Bonjour (Mac OS X) или Avahi (у всех десктопных дистрибутивов Linux она точно есть).
В итоге получается явный конфликт. С одной стороны записи *.local прописаны на DNS-серверах в локальной сети и администраторы сети предполагают, что эти имена будут разрешаться именно через DNS. А с другой стороны ряд клиентов в сети используют протокол mDNS, который предполагает разрешение имён *.local мультикастовыми mDNS-запросами, а вовсе не через DNS-сервер.
И чтобы Linux-клиенты научились разрешать имена хостов вида *.local не только через mDNS, но и через обычные DNS-запросы к DNS-серверу, во многих Linux-дистрибутивах (в частности Ubuntu и openSUSE) приходится делать ручные манипуляции по редактированию конфиг-файла
Windows-клиентам на этот конфликт с использованием зоны .local, конечно, насрать. У Microsoft, как обычно, своя реализация технологии Zeroconf, называемая APIPA (Automatic Private IP Addressing), а для разрешения имён там используется не mDNS, а свой протокол LLMNR (Link-local Multicast Name Resolution), в котором не зарезервирована зона .local для разрешения имён локальных хостов. Поэтому для Windows нет конфликта, связанного с использованием зарезервированной зоны .local.
Но всё же при принятии решения о выборе универсального имени для локальных ретрекеров следовало учесть не только Windows-клиентов, но и прочие реализации и зарезервированные для них зоны.
Я категорически против, чтобы для внутрилокальных bittorrent-ретрекеров в torrent-файл добавлялся такой announce-URL. Т.е. я не против добавления туда URL ретрекера вообще, но просто имя (а точнее зону) для этого универсального локального ретрекера следовало выбрать другое. Сделали бы имя в некой зоне bittorrent (например, retracker.bittorrent) или в зоне retracker (bittorrent.retracker) или ещё в какой-то уникальной нигде не зарезервированной зоне. Но имя в зоне .local выбрали совершенно напрасно.
И очень жаль, что администраторы rutracker.org (torrents.ru) повелись на это предложение. А глядя на них администраторы ряда других трекеров сделали так же, а администраторы локальных сетей создали зону .local с этой записью в локальных DNS.
Проблема в том, что зона .local в протоколах разрешения имён уже была ранее зарезервирована совсем для других целей.
В реализациях технологии Zeroconf от Apple (Bonjour) и в реализациях этой технологии, используемой в Linux/BSD, (Avahi) для разрешения имён хостов и сервисов в локальной сети без DNS-сервера используется связка протоколов mDNS (multicast DNS) и DNS-SD. И в протоколе mDNS как раз зарезервировано, что имена хостов в некой псевдо-зоне .local должны разрешаться клиентами не через классические запросы к DNS-серверу, а именно мультикастом по протоколу mDNS. И клиенты с Mac OS X, Linux и *BSD именно так и поступают, если у них установлена поддержка Bonjour (Mac OS X) или Avahi (у всех десктопных дистрибутивов Linux она точно есть).
В итоге получается явный конфликт. С одной стороны записи *.local прописаны на DNS-серверах в локальной сети и администраторы сети предполагают, что эти имена будут разрешаться именно через DNS. А с другой стороны ряд клиентов в сети используют протокол mDNS, который предполагает разрешение имён *.local мультикастовыми mDNS-запросами, а вовсе не через DNS-сервер.
И чтобы Linux-клиенты научились разрешать имена хостов вида *.local не только через mDNS, но и через обычные DNS-запросы к DNS-серверу, во многих Linux-дистрибутивах (в частности Ubuntu и openSUSE) приходится делать ручные манипуляции по редактированию конфиг-файла
/etc/nsswitch.conf и удалению оттуда фрагмента [NOTFOUND=return] в строке hosts:. Только после этого эти Linux-клиенты начинают находить в локальной сети сервер retracker.local, прописанный в torrent-файлах и на внутрисетевом DNS-сервере в зоне .local.Windows-клиентам на этот конфликт с использованием зоны .local, конечно, насрать. У Microsoft, как обычно, своя реализация технологии Zeroconf, называемая APIPA (Automatic Private IP Addressing), а для разрешения имён там используется не mDNS, а свой протокол LLMNR (Link-local Multicast Name Resolution), в котором не зарезервирована зона .local для разрешения имён локальных хостов. Поэтому для Windows нет конфликта, связанного с использованием зарезервированной зоны .local.
Но всё же при принятии решения о выборе универсального имени для локальных ретрекеров следовало учесть не только Windows-клиентов, но и прочие реализации и зарезервированные для них зоны.
Спасибо.
Ага, у меня ubuntu каждый раз при загрузке напоминает об отключении службы avahi из-за зоны .local.
> А глядя на них администраторы ряда других трекеров сделали так же, а администраторы локальных сетей создали зону .local с этой записью в локальных DNS.
Такие администраторы локальных сетей — идиоты. Создавать надо не хост retracker в зоне local, а сразу _зону_ retracker.local., тогда она не будет конфликтовать с Zeroconf/Avahi
Такие администраторы локальных сетей — идиоты. Создавать надо не хост retracker в зоне local, а сразу _зону_ retracker.local., тогда она не будет конфликтовать с Zeroconf/Avahi
Я, помню, еще когда торрентс.ру это вводили, писал на форуме про это. Что придумали имя, не подумав головой, положив болт на всех, кроме Windows. Комментарии были в стиле «macos? linux? что это? вот еще, греть голову из-за нескольких %%».
От души пожелал им, чтобы в одно прекрасное утро к их винде приехал update, после которого windows-клиенту тоже понадобится зона .local :)
Причем писал ведь и про то, что надо хотя бы инструкцию поправить, для тех админов, которые не включают голову, а будут тупо копипастить. Чтобы, как пишут выше, создавалась в fake dns не зона .local и в ней хост retracker. А сразу зона rettracker.local с доменной A записью. Тогда хоть убунты не станут ругаться при каждом логине и т.п.
Пофигу. Деревянные.
От души пожелал им, чтобы в одно прекрасное утро к их винде приехал update, после которого windows-клиенту тоже понадобится зона .local :)
Причем писал ведь и про то, что надо хотя бы инструкцию поправить, для тех админов, которые не включают голову, а будут тупо копипастить. Чтобы, как пишут выше, создавалась в fake dns не зона .local и в ней хост retracker. А сразу зона rettracker.local с доменной A записью. Тогда хоть убунты не станут ругаться при каждом логине и т.п.
Пофигу. Деревянные.
> А разве поиск локальных пиров идет не через retracker.local/announсe?
Также можно добавить, что поиск локального bittorrent-трекера/ретрекера (а потом через него и пиров в локальной сети) возможен и без добавления announce-URL этого ретрекера во все torrent-файлы.
Существует расширение BitTorrent-протокола BEP-0022, которое позволяет автоматически искать адрес локального bittorrent-ретрекера в DNS через специальную SRV-запись, созданную там. Для этого bittorrent-клиент должен поддерживать эту фичу, а также администратор локального DNS-сервера должен добавить туда соответствующую SRV-запись для локального ретрекера.
Ну и всякие механизмы DHT, Local Peer Discovery и Peer Exchange, которым для поиска/получения списка пиров не нужен ни локальный ретрекер, ни DNS.
Также можно добавить, что поиск локального bittorrent-трекера/ретрекера (а потом через него и пиров в локальной сети) возможен и без добавления announce-URL этого ретрекера во все torrent-файлы.
Существует расширение BitTorrent-протокола BEP-0022, которое позволяет автоматически искать адрес локального bittorrent-ретрекера в DNS через специальную SRV-запись, созданную там. Для этого bittorrent-клиент должен поддерживать эту фичу, а также администратор локального DNS-сервера должен добавить туда соответствующую SRV-запись для локального ретрекера.
Ну и всякие механизмы DHT, Local Peer Discovery и Peer Exchange, которым для поиска/получения списка пиров не нужен ни локальный ретрекер, ни DNS.
Есть предположение что это резервный домен, на случай если rutracker.org «умрет».
В случае «утери» домена rutracker.org не составит труда поднять трекер на rutracker.net. В раздачах он уже вбит, значит с сидерами после смены домена, проблем не будет.
В случае «утери» домена rutracker.org не составит труда поднять трекер на rutracker.net. В раздачах он уже вбит, значит с сидерами после смены домена, проблем не будет.
В единственном треде на форуме что я нашёл — rutracker.org/forum/viewtopic.php?t=2833412, ничего нет информативного.
Ошибки есть у всех, у кого я узнавал, поэтому моё мнение таково, что что-то планировали сделать, но не срослось, и сейчас сервис не функционирует.
Ошибки есть у всех, у кого я узнавал, поэтому моё мнение таково, что что-то планировали сделать, но не срослось, и сейчас сервис не функционирует.
> Это добавление в список трекеров адреса ix*.rutracker.org, который служит для непонятных мне целей.
А вы ничего не путаете?
У меня у torrent-файлов, скачанных с rutracker.org в качестве трекера указан либо
Домены-то разные (.net и .org). И тот и другой трекер работают в битторрент-клиенте без ошибок.
А вы ничего не путаете?
У меня у torrent-файлов, скачанных с rutracker.org в качестве трекера указан либо
http://bt*.rutracker.org/либо
http://ix*.rutracker.net/
Домены-то разные (.net и .org). И тот и другой трекер работают в битторрент-клиенте без ошибок.
А просто добавить запись в hosts, указываюшую на rutracker?
думал об этом, но есть несколько причин почему отказался:
1. Изучение протокола позволит решать ряд других задач, например, автоматизация смены трекера (torrents.ru -> rutracker.org), или добавление нового. Поэтому в плане опыта лучше разобраться что к чему.
2. Не знаю как вы, но я нередко забываю о модификациях hosts/dns, и поэтому возможно множество факапов в дальнейшем — например, банальная смена пасскея.
3. Я не знаю механизмов работы торрент-клиента, поэтому вполне возможно что он будет посылать в 2 раза больше запросов, чем нужно.
Возможно это напоминает — «давайте потратим 8 часов сейчас, что бы когда-нибудь сэкономить 2 раза по 5 секунд». Но надеюсь что это не так :)
1. Изучение протокола позволит решать ряд других задач, например, автоматизация смены трекера (torrents.ru -> rutracker.org), или добавление нового. Поэтому в плане опыта лучше разобраться что к чему.
2. Не знаю как вы, но я нередко забываю о модификациях hosts/dns, и поэтому возможно множество факапов в дальнейшем — например, банальная смена пасскея.
3. Я не знаю механизмов работы торрент-клиента, поэтому вполне возможно что он будет посылать в 2 раза больше запросов, чем нужно.
Возможно это напоминает — «давайте потратим 8 часов сейчас, что бы когда-нибудь сэкономить 2 раза по 5 секунд». Но надеюсь что это не так :)
То есть, если взять ресурс типа isohunt, где в каждом терренте прописано много трекеров, и некоторые всегда оказываются недоступны, transmission будет его всегда помечать сломанным?
Или вариант №2 — исправить transmission
Что то я никогда за transmission такого не замечал (по крайней мере в мак версии), а под линуксом я таких проблем сроду не видел, сколько не сижу и не качаю :) Может лучше баг-репорт разрабам послать? Это будет выглядеть логичнее мне кажется.
я не считаю что это баг.
имхо, правильно помечать то что торрент сломан, когда хотя бы один из трекеров вернул ошибку.
По-крайне мере если трекеров 2 — URL источника (bt*.rutracker.org, например) + retracker.local.
То при возникновении ошибки (например Unregistered torrent), мы сразу увидим это.
имхо, правильно помечать то что торрент сломан, когда хотя бы один из трекеров вернул ошибку.
По-крайне мере если трекеров 2 — URL источника (bt*.rutracker.org, например) + retracker.local.
То при возникновении ошибки (например Unregistered torrent), мы сразу увидим это.
Я вообще если честно слабо понимаю о чём речь. Я этого никогда не наблюдал. Вот что у меня делюг например говорит
Status:
rutracker.org: Анонс успешен
Трекер:
bt3.rutracker.org/ann?uk=1NP1VrIWfC
Пока я в редактор трекеров не залезу я и не знаю что их там 3 штуки вообще.
Status:
rutracker.org: Анонс успешен
Трекер:
bt3.rutracker.org/ann?uk=1NP1VrIWfC
Пока я в редактор трекеров не залезу я и не знаю что их там 3 штуки вообще.
Ну 2 из 3 трекера работают — что ему панику то наводить? ИМХО баг
если бы он панику не наводил то отслеживать _реальные_ проблемы с трекером было бы сложно.
Остальные 2 работают? Информацию передают? Всё качается, статистика учитывается? Значит всё ок — пусть молчит.
а если в списке окажется только retrecker.local?
а остальные 2 отвалятся?
ну или retrecker.local + ix*, который не учитывает статистику.
Технически практически нереально определить «важность» трекера. Поэтому вывод из строя любого из списка должен сигнализировать, ибо вдруг этот вышедший и является самым главным, а остальные, рабочие, — просто заглушки.
а остальные 2 отвалятся?
ну или retrecker.local + ix*, который не учитывает статистику.
Технически практически нереально определить «важность» трекера. Поэтому вывод из строя любого из списка должен сигнализировать, ибо вдруг этот вышедший и является самым главным, а остальные, рабочие, — просто заглушки.
Вас тоже касается =)
Товарищ KorP у тебе щас паскей стырят! :)
Вот он твой 1NP1VrIWfC
Как возьму и скачаю что-нить от твоего аккаунта, будешь знать! :)
Вот он твой 1NP1VrIWfC
Как возьму и скачаю что-нить от твоего аккаунта, будешь знать! :)
Можно очень сильно не переживать, это ж рутрекер, а не порнолаб :)
Это мой не основной аккаунт просто. Этим аккаунтом только мой сервак пользуется :) А за счёт того что я его натренировал самостоятельно следить за обновляемыми раздачами, которые мне интересны — он при обновлении торрента оказывается всегда в первой десятке раздающих, отсюда высокий рейтинг и никаких переживаний :)
На рутрекере фрилич
Вы сейчас спалили свой passkey (uk=). Теперь можно добавить на скачку любой торрент с рутрекера, в редактировании трекеров указать ваш passkey, и всё скачанное будет засчитываться вам. Вы можете зайти в профиль на рутрекере и сгенерировать новый паскей. В старых раздачах в торренте придётся его тоже сменить.
> Bencode
> Именно так называется формат кодирования данных в .torrent-файлах.
> Больше он почти нигде и не используется,
Он используется для кодирования всех пакетов BitTorrent.
Кстати формат .torrent-файла указан слишком примитивно, в нём часто можно встретить дополнительные хеши файлов и другую опциональную информацию.
> Именно так называется формат кодирования данных в .torrent-файлах.
> Больше он почти нигде и не используется,
Он используется для кодирования всех пакетов BitTorrent.
Кстати формат .torrent-файла указан слишком примитивно, в нём часто можно встретить дополнительные хеши файлов и другую опциональную информацию.
Мне кажется или Вы копирайт на картинке замазали?
Когда год назад torrents.ru стал rutracker.org, я написал питоновский скрипт, правящий announce-list в торрент файлах. Использовал готовые функции работы с bencode из BitTorrent/BitTornado и не изобретал лишних сущностей :-)
А я год назад написал скрипт на Perl и патчил им все торренты на лету вообще для всех пользователей нашей сети ;)
Для решения этой задачи не достаточно ли было внести изменения в файл hosts,
подставив для имени ix*.rutracker.net IP адрес от retracker.local?
подставив для имени ix*.rutracker.net IP адрес от retracker.local?
Автору зачёт. Но в качестве альтернативы можно использовать BEncode Editor
forum.utorrent.com/viewtopic.php?id=31306
forum.utorrent.com/viewtopic.php?id=31306
Любопытная статейка. Хотя сишить это костыль :) хоть и автору респект. Есть де куча вменяемых либ, на базе того де python.
Автоматизирую ка я для себя с учетом, что качать могу на лине и на макоси.
Автоматизирую ка я для себя с учетом, что качать могу на лине и на макоси.
Если файлы ты кидаешь копированием, то IN_CREATE неправильно использовать в данном случае. Данные код будет отлавливать только мув-ы и линк-и. С копированием будут ошибки, тк ты будешь открывать недозаписанный файл.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Torrent-файл. Что же у него внутри?