BOUNTY: Low bandwith friendly protocol for interacting with remote rtorrent

[peshua19]

As ruTorrent is the most comfortable and feature rich frontend for rtorrent, it would be great to use it in any conditions. Meanwhile, the current implementation utilizes multiple XMRPC calls from client (on which the WebUI is running) to server (on which rtorrent is running). In practice, that means that a stable broadband link with decent latency should exist between client and server, otherwise ruTorrent fails to update data in time, even when considerably increasing timeouts. Unfortunately, such link is not always available, so communicating with remote seedbox via, e.g., GPRS link is virtually impossible.

My suggestion is to implement a more bandwidth-effective protocol for communicating between client and server (it may combine multiple XMLRPC calls in batches, compress them etc.), to develop an additional portable server-side component that translates this protocol into plain XMLRPC calls and a plugin for ruTorrent to send requests using this protocol. This is not a simple task, as it involves both client- and server-side programming, and should be not easy to implement, so I offer a bounty for this feature.

If stable work (updating a list of ~200 torrents at least each 10 sec.) over a ~40 kbit/s link with moderate packet loss (below 15%) becomes possible, I will pay 100 USD.
If such result is not possible to achieve by any means - I'll better consider donating rakshasa for improving rtorrent console interface

 

[saroos1]

this would be most excelent and could lead to aps for iphones, and other smart phones.

I think this would be a great mod, but quite difficult. I support this as well, i can't pledge 100 dollars but i'll throw in 20.

 

[lisas4567]

Something like that can be done - for example, server may send only changed data instead full torrents list. But, as result, we will increase server's loading (because these "difference" will be calculated by php script). If you has a slow server, then this -

If such result is not possible to achieve by any means - I'll better consider donating rakshasa for improving rtorrent console interface

will be a better solution.

 

[peshua19]

i don't think the problem is a slow server.

I think he's offering the bounty because he wants to use the application on low bandwidth links like cell phones or dial up.

It would be the ideal sort of addon/plugin for an iphone app for instance.

 

[randac56]

Exactly. I have a dedicated server. It's load average with 200-300 seeding and 5-10 leeching torrents never reaches more than 0.20. The bottleneck is the connection on the client side. While traveling across Russia, it is not easy to find a decent wireless internet connection, you must know...

 

[saroos1]

While traveling across Russia, it is not easy to find a decent wireless internet connection, you must know...

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

 

[lisas4567]

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

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

P.S. Заодно уменьшение трафика помолго бы и в другой ситуации - международный роуминг, где как раз может быть вполне шустрый 3G, но по заоблачным ценам за трафик.

 

[peshua19]

Я попробую кое-что предпринять в этом направлении. В течение месяца, примерно. Правда, консоль в любом случае заведомо будет экономичнее, тут ничего не поделать.

 

[randac56]

Я попробую кое-что предпринять в этом направлении. В течение месяца, примерно. Правда, консоль в любом случае заведомо будет экономичнее, тут ничего не поделать.

Спасибо заранее. Ну и bounty в оговоренном выше размере

 

[saroos1]

r868 - это оно? Или только один из этапов?

 

[lisas4567]

Кое-что поправил в данном направлении, но задуманное пока полностью не реализовал.

• Добавлена поддержка gzip. Для включения необходимо в conf/config.php выставить константу PHP_USE_GZIP в true. Имеет смысл использовать совместно с плагином rpc. Не имеет смысла использовать, если zlib.output_compression (или соотв. mod от apache) в php уже есть (тут, впрочем, не совсем уверен, сравнительных тестов не проводил). Сам gzip должен быть в пути у пользователя веб-сервера, либо путь к gzip должен быть настроен в config.php. Разумеется, включать режим можно только если загрузка сервера позволяет - каждый http ответ больше 2К фильтруется через внешнюю программу, что на загрузке сервера хорошо не сказывается.
• Добавлена поддержка кеширования для ряда запросов.
• Пооптимизированы картинки.

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

 

[peshua19]

I am testing the latest changes...so far they work well.
I've noticed the page loads "differently" now.


Before, when i load rutorrent, it would load several elements and they would show up one by one...now there is more of an inital lag, but the entire page seems to load as one. This is a possitive change i think, because while the initial lag is longer, the net time to see a full loaded page is much less.

 

[randac56]

I've noticed the page loads "differently" now.

I try to translate posting above.
I make some changes for optimize traffic.

• Added external gzip support. For turning this mode on, you need set to true const PHP_USE_GZIP in conf/config.php. As result, part of http answers (not all) > 2K will be gzipped by external program. This mode is most useful with plugin rpc. This mode can't be used when zlib.output_compression (or something like mod_gzip) is already on. This mode can't be used on slow servers.
• Added cache support for part of http requests.
• Part of images was optimized.

Structure of config files (main and plugins) was changed - you need to check its (see section of setting paths for external programs).
Any significult changes in protocol (obtaining torrents list "by difference") coming soon.

 

[randac56]

yes, i've been using google translator (if you use chrome as your browser any russian text will be tranlated for you, it's nice)


Questions:

when you say:
Quote

This mode is most useful with plugin rpc​

does this mean:
using rpc with this mode is MORE desirable than using webserver SCGI (for speed)

or IF you already use RPC, this mode will be a benifet

I guess what i am asking is:

1) If i'm using the webserver for my rpc should i switch to RPC with these new changes
2) If i'm not using rpc, will the gzip offer any benifets (from my results it SEEMS to but i might be just thinking it is helping)


When you say http cache, does this just keep common sent info? how does this work? What exactly does it cache (sorry, you dont' have to answer, i just enjoy learning about this)

Thanks for translating some of this.

also, one more thing....

when i enabled it, i changed it to read this:

Code:
@define('PHP_USE_GZIP', true, true);
is this right?

also, is the gzip level in line with most other gzip levels (it's set to 2 now, with other things, it's 1-9 1 being worst compression 9 being most, but 9 taking the longest)

 

[saroos1]

does this mean:

If you use plugin rpc and PHP_USE_GZIP=true, rtorrent's output via RPC will be gzipped. If you use webserver SCGI - will be gzipped some ruTorrent answers only.

If i'm not using rpc, will the gzip offer any benifets (from my results it SEEMS to but i might be just thinking it is helping)​

​

Don't know, will the gzip offer any benifets for your system at all. This dependens from many factors. You need it if
1) Your system hasn't compression support for php yet.
2) You have narrow channel, but powerful server.

When you say http cache, does this just keep common sent info?​

​

Your browser cache. For example, you have ruTorrent with all of it plugins. When you load ruTorrent in your browser, it say to your server:
GET /rutorrent/php/getplugins
Your server answer for this:
200 OK
Last-Modified: [time of last changes in plugins configuration]
[~200K of content]
Your browser store this content (and it Last-Modified time) to it cache on your disk.
Next time, when you load ruTorrent, browser say to your server:
GET /rutorrent/php/getplugins
If-Modified-Since: [time of content, which stored in disk cache]
If you don't change something in plugin configuration, don't restart rtorrent since last time of loading, your server answer for this:
304 Not Modified
[0K of content]
As result, browser will use answer, which already stored in cache.
Not all requests may be cached, only some.

is this right?​

​

Yes.

also, is the gzip level in line with most other gzip levels (it's set to 2 now, with other things, it's 1-9 1 being worst compression 9 being most, but 9 taking the longest)​

Yes.

 

[saroos1]

very nice.

I still say i notice a SLIGHT difference...i am not sure if this difference is due to the gzip or the cache now.

Like i said, prior to 868 when i load, elements would load one by one, (maybe one image, then another, then another) but would start loading soon

now, it takes longer till they START loading, but the entire page seems to render all at once....or maybe i'm just crazy.

anyways, nice work, as always

 

[lisas4567]

Like i said, prior to 868 when i load, elements would load one by one, (maybe one image, then another, then another) but would start loading soon

See point 3, "images optimization". Now all status and toolbar icons are composed in one file.

 

[peshua19]

2Alexander
В основном работу завершил. Плагин называется 'httprpc', область применения - сравнительно мощный сервер и узкий канал передачи. Понятие "сравнительно мощный" должно выясняться на практике, например, на SOHO роутере данный плагин применять строго не рекомендуется - загрузка процессора php скриптами сводит на нет всю экономию на трафике.
Упомянутая экономия достигается за счет
1) замены протокола xmlrpc на более компактный
2) передачи торрент-листа "по изменению".
При тестовом прогоне смотрел на трафик для системы с 50 торрентами, в среднем 35 из них активны.
Без плагина каждый цикл обновления приводит к передаче ~60К данных (не зависимо от количества активных торрентов), время реакции ~1 сек.
С плагином - первая загрузка всего листа целиком - ~20К, в дальнейшем - ~5K, время реакции ~0.5 сек.
В качестве дополнительных мер по уменьшению трафика могу порекомендовать
1) Не использовать плагины.
2) Задействовать на веб-сервере сжатие. Либо выставив директиву php zlib.output_compression (лучше) либо использовав внешнее сжатие в ruTorrent (хуже). Данный пункт несколько спорен, т.к. при сжатом контенте, как правило, не выставляется Content-Length, что блокирует keep-alive соединения (замечу, что отсутствие сжатия keep-alive тоже не гарантирует, это зависит от настроек веб-сервера, но при использовании сжатия keep-alive не будет точно). Вообщем, это нужно смотреть на конкретной конфигурации - что окажется выгодней.
Я его еще буду потихоньку пилить, но в целом смотреть уже можно.

 

[randac56]

спасибо. Я как раз вернулся домой к серверу - сейчас обновлю rutorrent и посмотрю, что получается.

 

[saroos1]

Поставил, попробовал. Прогресс налицо - с полудохдым провинциальным CDMA список из 300+ торрентов (200+ сидируется, более 30 активных) хоть и грузился очень долго, но зато загрузившись стал просто летать: за 5 минут интенсивного щелкания всюду подряд всего один таймаут. Спасибо - обещанный bounty отправлен, ловите в PayPal!