Торрент-трекеры, API, которого не было, и torrt

С ростом вычислительных мощностей и совершенствованием JS-движков всё больше и больше появляется в Сети проектов, переносящих основную логику на клиентскую сторону, оставляя при этом на серверах модели данных и REST- или подобные интерфейсы для взаимодействия с этими моделями. Посмотрите на них: все эти Backbone.js, AngularJS, Ember и подобные выводят веб-приложения на другой уровень, делая из браузеров рабочих лошадок. Впрочем нам для статьи не столько интересен факт переноса логики, как факт существования API, поэтому переходим прямо к основной теме статьи — торрент-трекерам.

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


Расширение аудитории

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


Единый REST-протокол

При этом неплохо было бы, если бы трекеры использовали совместимые (или даже единый, унифицированный) REST-протоколы. Не велика беда, если этого не будет, но с точки зрения разработчиков, конечно, было бы удобно — разброд и шатание не всегда являются залогом здоровой конкуренции и развития.


Структуризация

Большинство трекеров сейчас построены на движках форумов, или же пытаются копировать их. В таких случаях описание материала — всего лишь первое сообщение темы, сплошной текст, в котором, если вы добавляете материал, можно на радость модераторам запросто ошибиться. Формы-надстройки, которые предлагается заполнить при добавлении, часто никак не гарантируют того, что модератор одобрит оформление.

Казалось бы, для чего одни люди снова и снова заставляют других исправлять неправильное оформление? Откуда вообще берётся проблема оформления с необходимостью изучать правила составления раздач, которые для разных разделов трекеров могут ещё и различаться? Да оттуда же — несовершенство программного обеспечения. Вместо того, чтобы сконфигурировать его надлежащим образом, люди предпочитают усложнять друг другу жизнь.

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


Новые возможности

Подход с API открывает прорву возможностей для развития. Пора бы предусмотреть полноценную систему рейтинга материала, возможно даже по множеству параметров (µTorrent, кстати, уже ввёл нечто подобное). Что мешает реализовать систему рекомендаций? А возможность автоматического скачивания торрентов из обновляемых раздач? А как вам идея интеграции подобных трекер-клиентов в медиа-сервера? Уверен, что это только верхушка айсберга.


Монетизация

Однако, радужные настроения может испортить денежный вопрос. Людям, развернувшим трекеры нужно как-то за них платить. Да чего там платить, люди, разворачивающие трекеры бывает живут за счёт них. Можно предположить, что основным (и часто единственным) средством заработка является показ рекламы — благо посетителей на трекерах тучи и показов страниц, перемещаясь по темам они генерируют тьму.

Понятно, что при таком положении дел никто не будет спешить с API. Максимум — RSS, оповещения об обновлении темы и кнопки «Нравится», «Не нравится». И повторять как мантру: «Нужно, чтобы пользователь зашел на страницу с рекламой».

Но, если задуматься, присутствие API вряд ли повредит делу. Никто не мешает показывать рекламу на трекер-клиентах. Путь проверенный, выхлоп есть, доказано ICQ, Skype, тем же µTorrent и прочими с Adware.

Сегодняшние технологии позволяют многое. Если вы боитесь, что на каком-то клиенте не будет показана ваша реклама, вы сможете и создать свой клиент и ограничить доступ к API только конкретными клиентами (взгляните, к примеру, на OAuth2). С другой стороны, никто вам также не гарантирует, что реклама будет показана в браузере.


А пока этого всего нет

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

Где-то в конце 2011 года, когда я ещё смотрел пару сериалов на регулярной основе, и уже изрядно устал от необходимости вручную мониторить обновление раздач, ко мне пришла мысль о возможности автоматизации этого процесса. Тогда я пользовался торрент-клиентом Deluge, основанном на Twisted, и потому решил реализовать функциональность в виде подключаемого модуля (плагина). Так появился deluge-updatorr, более известный как Updatorr. На первых порах он представлял из себя небольшой каркас для создания клиентов к различным трекерам, позволяющий Deluge периодически проверять нужные раздачи на предмет обновлённости. Тогда из коробки он поддерживал работу с RuTracker.org, позже ребята прикрутили к нему поддержку RUTOR и AniDUB.

С тех пор прошло немало времени, у меня появился NAS, на который было целесообразно поставить Transmission, вместо Deluge, но Updatorr по-прежнему пользовался у народа спросом и этим летом, я решил развить идею.

Так torrt стал консольным клиентом, поддерживающим работу с различными торрент-клиентами посредством их RPC. Помимо Deluge, torrt умеет работать с µTorrent и Transmission. Кроме указанных выше трекеров теперь поддерживается NNM-Club. Небольшую вводную статью по torrt, я опубликовал в июне в личном блоге.


Из чего состоит torrt

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

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

По сути, реализация поддержки нового трекера — это объявление правил посещения страницы раздачи (возможно с авторизацией) и изъятие ссылки на торрент-файл. Всё остальное торрт сделает сам.

Отмечу, однако, что некоторые трекеры идут на различные хитрости, чтобы защититься от роботов, например rutracker не даст скачать торрент файл, пока не удостовериться, что пользователь навёл мышь на ссылку скачивания. Поэтому, есть вероятность, что вам даже потребуются базовые навыки обратной инженерии для анализа происходящего, чтобы обхитрить систему %)

Что же касается поддержки новых торрент-клиентов, реализовать её будет чуть сложнее — придётся изучить их RPC (или реализовать его в случае отсутствия) и описать взаимодействие с ним. Единственное обязательное требование для новых RPC-классов — реализация интерфейса, предоставленного BaseRPC.


Вот что такое торрт, и вот к чему в наше время может привести отсутствие на сервисах программных интерфейсов.


Не написать ли вам над трекер-демоном свою веб-оболочку с клёвым API?
На Питоне, само собой.