The first couple of times I tried to setup Bittorrent I had a lot of trouble. Here is a basic summary of what you need to do:
btmakemetafile.bittorrent test.iso http://server.example.com:8000/announce
The above command will create a metafile named test.iso.torrent. Note that the server name (in this example server.example.com can be an IP address and any TCP port can be used (it’s generally best to use a port above 1024 to run as non-root). The “/announce” at the end of the string is vitally important, it won’t work without it – and you won’t get any usable error message! I have filed Debian bug report #511181 about this [1].
bttrack.bittorrent --port 8000 --dfile dfile
The above command starts a tracker listening on port 8000 and uses the file named dfile to store the recent downloader information. By default it will only allow downloads for .torrent files in the current directory, the --allowed_dir option allows you to specify another directory and the --parse_allowed_interval option allows you to specify the length of time in minutes between checking for changes to the list of torrent files.
In Debian you can edit the file /etc/default/bittorrent if you want the tracker to start on boot. There is no configuration for starting a btdownload program on boot (for seeding the data). In most cases it’s probably best to just run a couple of seed btdownload processes via screen on different servers and rely on the fact that you can login to restart them if the servers are rebooted.
btdownloadcurses.bittorrent test.iso.torrent
The above command needs to be run on a machine that has the complete test.iso file in the current directory to seed the torrent. Probably most people will use the same machine for creating the metafile, running the tracker, and running the seed download program. But these can all be done from different machines. This is the curses version which works from screen, there is also a btdownloadheadless.bittorrent program that is designed to be run from scripts.
Once all that is done any machine on the net can start downloading via the above command.
For the seed server the most useful option seems to be --max_upload_rate to specify the maximum transmission rate (otherwise it will eat all your transmission bandwidth).
Thanks for the article, I know a few people that would be very interested in it and will point them to it. It also tells me how to set up something that I find useful and use for various things from time to time.
And if you want your torrent to stick around for a longer time – use multiple public trackers, such as:
http://tracker.openbittorrent.com:80/scrape
http://open.tracker.thepiratebay.org/announce
This way other people can continue seeding the file long after you have lost interest.
Using a dht-enabled client, such as Vuze also allows you torrent to appear in the tracker-less cloud and it will still be accessible if your trackers go down.
If you are uploading a first copy of a popular file (Debian releases come to mind) it would be advised to use SuperSeeding mode, where you client ensures that it has given out at least one copy of every part of the file before giving out extra copies of the same pieces. Starting distribution from several servers is another good option.
http://en.wikipedia.org/wiki/BitTorrent_client
Aigars: Great suggestions! The above web page has information on which clients support DHT and Super Seeding. The “vuze” package in Debian appears to have this.
How do you configure a metafile to support multiple trackers?
Is there a tracker proxy around or does using any of these features lose you the ability to talk to older clients?
I get the impression from your list posts and this blog post that setting up trackers is ridiculously hard for absolutely no reason. People suck. What happened to keeping the easy things easy and making the hard things possible?
My understanding of BT is pretty minimal but from reading your post I don’t see why the /announce even needs to be /explicitly/ specified in the first place. IMHO if it is needed in all cases it should be a bloody default with an option to change it if necessary (eg. for /quux/announce and /sorge/announce), as should the commonly used port number.
IMHO the usage should be, for simple cases,
bttrack.bittorrent test.iso http://www.example.com
KISS. Commandline utilities are no excuse for ridiculous interfaces
… and my sample commandline didn’t have ‘http://’ at the beginning, by the way; I think your blog software inserted that. I’d typed a bare hostname
John: I agree with your points. It seems to me that the ideal thing to do might be to have the program which creates the metafile attempt to contact the tracker. Then if in doubt you could run the tracker first and if the metafile creation program can’t talk to it then you try different options. That would mean that any problems in setting up the tracker and the metafile could be isolated to two programs – my problem was that there were three possible causes of the problem which made it harder to solve.
It’s ironic that my blog software “corrected” your URL and made it a link even though visiting the page in question will not help the readers. That both demonstrated how software can do things to make it easier for users and how such correction can give slightly undesirable results.
But if a command-line utility just prints a warning “are you sure you didn’t mean to type \”%s\”” then there’s little scope for problems.
for seeding torrent clients like rtorrent (screen compatible) that keep a list of files to seed and can handle multiple files at once might be more helpful.
with an @reboot cron job (with screen etc) they should even automatically come back up with the same set of files to seed after a reboot.
rtorrent even has a web interface if wanted (disabled by default)