ruTorrent был разработан на базе WebUI к µTorrent, соответственно, его внешний вид очень напоминает "родителя". Собственно, своим названием ruTorrent тоже обязан этому самому родителю - µTorrent + rtorrent = ruTorrent. Начиная с версии 3.0 основной код был полностью переписан, в результате чего от предка только внешний вид и остался.

• rtorrent версии не менее 0.8.2, скомпилированный с поддержкой XMLRPC.
• Веб-сервер с поддержкой php 5.0.
• Браузер, как локальный клиент.
  • IE 7.0-11.0, Firefox 2.x-31.x - оптимальный выбор.
  • Opera 9.x-11.x - работает.
  • Safari 3.x-5.x - работает. Возможны проблемы с не отображением картинок при использовании протокола https. Полагаю, ошибка в браузере. Нужно подстраивать сервер, чтобы не держал keep-alive соединения, если клиент пользует Safari.
  • Google Chrome - работает. Возможны проблемы, аналогичные Safari.

Прочие браузеры не проверял.

См. Настройка веб-сервера, Установка и настройка ruTorrent.

• Аутентификация. В настоящий момент ruTorrent не поддерживает аутентификацию. Используйте соответствующие функции веб-сервера.

• Галку "Запрашивать сообщения трекера" в настройках ruTorrent можно включать только в том случае, если Вы используете версию rtorrent >= 0.8.5. В противном случае ее включение может привести к потере работоспособности ввиду некорректной обработки rtorrent сообщений трекера, содержащих не UTF-8 символы.
• Настройки rtorrent, изменяемые пользователем через соответствующий диалог ruTorrent валидны только на время текущей сессии rtorrent. После рестарта последнего они будут утеряны.
• Если вместо чисел больших 2 гигабайт ruTorrent показывает отрицательные числа, следует рекомпилировать rtorrent с более свежей версией xmlrpc-c. Минимально необходимая версия данной библиотеки - 1.11.
• При изменении номера порта, на котором rtorrent будет ожидать запросы, необходимо так же внести коррективы в конфигурацию ruTorrent - указать этот же порт в файле ruTorrent/conf.php в переменной $scgi_port.
• Авторизация доступа реализуется полностью средствами используемого веб-сервера и от ruTorrent не зависит. Защищать нужно URL /ruTorrent и, если используется scgi модуль веб-сервера - /RPC2. В случае использования вместо scgi модуля веб-сервера плагинов ruTorrent RPC или HTTPRPC URL /RPC2 защищать не нужно.
• Если Вы используете многопользовательскую конфигурацию, каждому пользователю должна соответстсвовать собственная точка монтирования scgi. Подробнее смотрте Настройка and Настройка веб-сервера.

• Имеющиеся клавиатурные хоткеи можно посмотреть нажав F1. Более-менее корректно работает это пока только в Firefox.
• Ряд аддонов к браузерам может привести к полной или частичной неработоспособности ruTorrent.

Начиная с версии 0.7.6 rtorrent поддерживает удаленное управление по протоколу XMLRPC через SCGI шлюз. Работать напрямую с SCGI шлюзом браузер не может - протокол не позволяет, да и открывать этот шлюз на сервере "наружу" никто в здравом уме не будет. Зато браузер (а значит и ruTorrent) может работать с веб-сервером, который, в свою очередь, переправляет команды в этот самый шлюз. Делать он это может двумя путями:

• Используя соответствующий модуль mod_scgi, который "срезает" с запроса HTTP оболочку, "обертывает" запрос в SGCI, отсылает rtorrent-у, производит обратную операцию с ответом последнего и засылает ответ обратно браузеру.
• Используя php скрипт, который принимает запрос от браузера, формирует на его основе запрос к rtorrent и проделывает обратную операцию с ответом rtorrent.

Каждый подход имеет свои плюсы и минусы. В первом случае веб-сервер не разбирает логику запроса а производит чисто техническую работу по конвертации одного протокола в другой. Следствия:

• Быстрая обработка запроса, малая загрузка сервера.
• Большой трафик между клиентом и сервером (клиент должен передавать и принимать уже готовый XML код, который в ряде случаев довольно велик по размеру).
• Логика обмена полностью вынесена в клиентскую часть.

Во втором случае веб-сервер сам генерирует должный XML код, основыванный на запросе браузера (но не идентичный ему), и отдает браузеру уже "переработанный" ответ rtorrent-а. Следствия:

• Сравнительно медленная обработка запроса, большая загрузка сервера.
• Малый трафик между клиентом и сервером.
• Логика обмена полностью вынесена в серверную часть.

ruTorrent изначально создавался для работы со слабыми серверами с широким каналом передачи, поэтому в основном использует первый подход. Однако существует плагин HTTPRPC, который "ставит все с ног на голову", т.е. переделывает логику работы для конфигурации "мощный сервер, узкий канал".

Вопросы Вы можете задать на форуме. Предложения и сообщения об ошибках Вы можете засылать сюда.