A rails iPhone webapp

One of the problems I had was that rtorrent is so efficient in using the bandwidth that it makes browsing very sluggish. Whenever I wanted to use the internet for something else, I used to ssh into the box and terminate the rtorrent process or at least throttle it from the webUI. However, my father also uses the internet connection and I needed a much simpler way to control how much of the bandwidth rtorrent uses.

One way could me using rutorrent and cutting it down to just barebones. However this solution seemed inelegant. rtorrent has an excellent XML-RPC implementation to control most of its actions. In fact, rutorrent uses this to control rtorrent. So, I thought why not use Rails to write a small webapp for iPhone to use XML RPC and do basic throttling and status reporting? Rails was probably too much for this application. Especially given that I didn’t need a database. Perhaps something like sinatra should’ve sufficed. However, it turned out to be exceedingly simple to write it in rails and I did so anyway.

The app simply has three buttons as follows:

Unlimited mode

This is the default mode of the app, where it keeps the bandwidth caps on rtorrent to unlimited. Limited mode puts it in 25kbps upload and 100kbps download limit mode. This allows normal things like browsing to be done in parallel with ease.

Limited mode

The restricted mode sets limits to 10kbps download and upload. This lets heavy duty operations such as downloading or watching videos to be done in parallel.

Restricted mode

By default, whenever you put the app in either limited or restricted mode, it gives you a 30 minute lease. Post this time the app switches back to unlimited mode. You can keep extending the lease indefinitely if you want to. I implemented this feature because we used to forget to put the thing back in unlimited mode after we finished browsing or downloading. This led to wasted bandwidth especially at nights. However, I use file read write for this persistence in storage and some race conditions exist in the code. These conditions however are very unlikely to be a source of problem given our usage and have therefore left out costly semaphores for synchronization.

Of course, remember this is entirely a server based application and all the heavy lifting needs to be done on my little plug computer. Hence I’ve tried to keep the code light.