BTSlave

Links

BitTorrent friends protocol

Sourforge Page

BTFS Now in Alpha!

A new program is available in the btslave distribution: btmount. This program uses the FUSE module to allow you to mount a torrent as a file system. Check out the Sourceforge page for downloads.

Download Faster

BTSlave builds on the brilliance of BitTorrent, enabling faster downloading of large files. BTSlave allows you to upload files when it is convenient for you, but when you need it, it's there to help you download fast.

Many users should see their download rates increase by 4x or more, especially when “flash crowds” hit. So when that new popular file gets released, BTSlave can save you days.

How it Works

BTSlave does not replace your current BitTorrent client. Feel free to continue using Azureus, BitTornado, etc. BTSlave simply helps your BitTorrent client download faster.

An extended BitTorrent peer protocol allows BTSlave to make friends, and help them download over time, When you need faster downloads, BTSlave asks it's friends to come help.

BTSlave is a “slave repeater”. A BitTorrent repeater is a client that only downloads data when no one is interested in the data it already has. Repeaters can achieve very high upload/download ratios, and they help the other peers in a torrent download faster. The “slave” part means that the repeater has as it's main goal helping out it's “master” -- your usual BitTorrent client.

Feel free to check out the current version of the proposed BitTorrent friends protocol.

The Problem

Down-loaders of big files typically leave their torrents after downloading.  This leads to an average upload/download ratio of around 1/1.  This limits many of us to download rates of about 40K bytes/second, instead of the 250K or better that our cable-modems/DSL can support. BTSlave aims to solve this problem.

A good analysis of the BitTorrent protocol can be found at:

http://www.theregister.co.uk/2004/12/18/bittorrent_measurements_analysis/

One very interesting conclusion:

"We believe that all current implementations of the BitTorrent protocol
exhibit a fundamental design flaw. Currently peers are punished for
seeding, as their Internet connections are then used at maximum capacity
to the significant benefit of other (downloading) peers. Instead of
punishing seeders, peers should be given an incentive to seed, possibly
at a bandwidth of their own choosing."

BTSlave provides exactly this kind of incentive. You leave it running until it's collected enough IOUs, and later, you cash them in for help downloading files.

The rest of this web page describes the basic ideas.

BitTorrent Free Repeaters

More of us would be willing to leave our BT clients running with lots of torrents open, except that:- It uses too much disk space to remain in lots of torrents

- It is difficult joining and managing lots of torrents

For example, I just upgraded to Linux FC3, and downloaded 2.3G of data.  I burned the DVD, and had to remove the data to save disk space.  I might be willing to donate upload time to another torrent with smaller files, but which one?  I cannot simply look at a list of web links and predict the torrent that would benefit the most.

Both of these problems can be solved.  In particular,  a modified client could do the job without modifying the BT protocol.

In effect, I'm writing a BT repeater in a multi-cast system.  I call the modified client a BitTorrent free repeater.

Here's how I imagine the repeater will work:

- The repeater will automatically download all .torrent files from a list of user-supplied .torrent file servers.

- The repeater will enter the torrent that needed additional bandwidth the most.

- To limit space on the hard-drive, only a user-specified sized cache will be used for writing pieces of files.  A typical cache might be from a few MB to a few hundred MB.

- The repeater will download only enough pieces to insure the repeater's upload bandwidth is fully used.  This leads to a very high upload/download ratio, thus increasing the torrent's overall download rate.

- The repeater will exit the torrent once it's cache fills up, flush it's cache, and then repeat this process.

BitTorrent Slave Repeaters

Most people leave torrents once they've finished downloading.  Simply offering the world free repeaters probably wont accomplish much, since many of us would need to run them before any of us saw a significant download bandwidth improvement.  We need a more selfish reason for people run their repeaters, or it probably wont ever happen.  The answer is slave repeaters.

To write a slave repeater, I'll first finish writing the free repeater, then I'll then modify the free repeater client to become a slave repeater.  Rather than have it fairly choose peers to transfer file pieces with, the slave repeater will immediately forward new pieces it gets to it's "master peer" -- the user's normal BT client.  If the repeater has no piece the master wants, it will try to obtain one by only being interested in connecting with peers that have pieces the master is missing.

This algorithm should not hurt the torrent in any way, since the repeater will forward as much data to the torrent as it gets just like any normal BT client.  However, the additional upload bandwidth it brings to the torrent will be split evenly between servicing the torrent and feeding it's master.  And, when there is no piece that the master is currently interested in, the slave repeater will act as a free repeater, thus helping the torrent's performance overall.

Assuming that I use 40KB/s as a max upload speed on all my BT clients (master and slave repeaters), every slave repeater I set up (at other sites - not on my own cable modem) should increase my master download speed by about 20KB/s.

Slave Friends

Chances are that any brownie points accrued by a slave repeater once it's master is no longer interested will be wasted.  In other words, a slave repeater does the master no good once the master completes his download by simply contributing download bandwidth to the torrent.

However, BitTorrent clients publish the version of the client running, so a slave repeater will be able to see all the other slaves in a torrent, and could strike up a conversation with them.  If any of the other slaves could use help transferring pieces to their masters, an idle slave will help them before helping the torrent in general.

A slave will expect future help from slaves that it helps.  A tit-for-tat algorithm will be used to insure that this happens (if you don't help my master, I wont help yours).  This algorithm creates a high incentive for masters to leave their slaves working around the clock.

I hope to be able to host a torrent of only slave repeaters to help them get to know each other.