In the past, we’ve covered how to make a torrent, and possible ways to revitalise a dead torrent. This time, we’ll cover what steps you can take to keep a torrent as healthy as possible for as long as possible.
A mistake that was common just a few months ago, was throwing out torrents with multiple trackers listed on it. Until recently, a number of torrents listed on the Pirate Bay, had the same tracker listed multiple times under different aliases, something they have since corrected. There are also occasions where up-to a dozen different trackers are listed, all for one torrent.
Some might argue that adding more trackers to a torrent is a good thing, but the fact is, it’s often harming things. Clients that can only handle one tracker, will only announce to the first one listed, and ignore any subsequent trackers listed. Multi-tracker capable clients will announce to the first tracker, as well as any subsequent ones, depending on how they are grouped. The thing is, every peer on the second tracker, will also have announced to the first tracker, and would be available there. However, the peers on the first tracker may not be on any other trackers.
At the end of the day, you’ve gained no new peers (unless the initial tracker was overloaded or down) but used up connection time and bandwidth on your connection, and more importantly, you’ve added an extra load to a tracker. While it may not seem a lot, with even a single thousand-peer torrent, and a 15 minute limit on re-announcing, that’s 4000 extra, needless connections per hour, per torrent.
The solution, use DHT if your client supports it, or if you’re strongly adverse to DHT but feel there is a possibility that the tracker might go offline, you can use a second fall-back tracker. Don’t disable DHT for the torrent though (by setting the private flag) because it can help the torrent die that much faster.
This is a little foible that’s pretty much unique to the BitComet clients. A padding file is an extra file, comprising junk data that’s added to torrents, so that files all start at the beginning of a torrent piece. In theory, this means that if you only want certain files in a torrent, you don’t have to download an extra part, belonging to another file. It is also supposed to make torrent ‘previews’ easier.
However, you don’t save any data downloaded. What you gain from the front will even out with the added data needed for the larger padding file needed at the beginning. Worse, if you’re downloading multiple files, the padding files can add up in size, and examples have been seen where padding files have been 25% of the total torrent size.
For the average user, there is no good reason to use padding files. The is certainly no reason that compensates for the added irritation those files give to other users, or the increased data bulking up the torrent.
Piece size is the bit that can make a torrent seeded on a home connection scale well, or make even the best seeded torrent bog down. At its heart, it’s how big each piece is that is checked, and distributed, but also how much data you discard for a hash-fail. Make the pieces too few and big, and it can be very hard for a peer to get started, too many small pieces will use more of a peers connection for overhead.
It’s a delicate balance, that is not easily found. Small pieces make it less susceptible to poisoning attacks (as practiced by MediaDefender, among others) and will help a torrent deal with sudden increases in peers, by making it easy to get a piece or two to trade. However, keeping track of who has what piece requires bandwidth, and small pieces mean that you will be telling connected peers about pieces you have just got more often.
After a number of years toying around, the optimum number of pieces seems to be between 1200 and 2200. Most torrent creators will only allow piece-sizes in multiples of 16kb, so you should, with few exceptions, find a size that fits in that range. A 700Mb torrent should be 512Kb pieces (giving 1400 total) and similarly, 350Mb would be better with 256kb. A 4.5Gb torrent would have 2,250 pieces, roughly, with a 2Mb piece-size. Or 1,125 with 4Mb. Either way would be fine, but 256kb pieces would mean 17,500+ pieces, and is too many.
The file-layout is something that can be key in determining how long the torrent lasts. The layout of a torrent and the data in it, is one of the most important factors in torrent longevity. In general, rars are not encouraged, and can lead to a shorter torrent life. Mainly this is down to the doubling of space this requires, space for the files, and space for the torrented rar. The only observed exception to this seems to be ‘scene rars’ where the rar files are widely available from multiple sources.
For multiple file torrents, directory names are also as important as file names. An accurate, and descriptive directory name frustrates less, than one called “temp” or “001” which can clash with similar named directories on client computers. It should also be noted that although most torrent creators will name the torrent file after the parent directory in the torrent, the torrent file can later be renamed without worry. There is a general misconception that torrents can only contain a certain number of individual files, which is not true.
Also, be wary in adding extra files, such as small text files with a hello, or attribution. Without this exact file the piece can not later be resurrected in a reseed. The more complex the file, the harder a reconstruction, if someone else wants to reseed. That music video of your band might be on someone’s hard drive, but if you had a fancy nfo file full of ASCII-art, which someone has deleted, it not only won’t reseed, but will delete the end of the re-seeders copy of the video when it is hash-checked.
Finally, and not directly related to making a torrent, make sure your connection settings are optimized. We have published hints on optimizing µtorrent and Azureus/Vuze in the past, as well as more general guides. Make your torrents right, and they will last longer, providing you follow one last tip – SEED. Without seeding, any torrent will die sooner.