Hi,
Aaron Ximm here, I work at the Internet Archive (archive.org) where we've been trying make use of BitTorrent wherever we can. E.g. we make around 2-3 million items (one 'thing' in the archive -- could be a netlabel album, a live show with 20 tracks, a book with various derived formats like plaintext from OCR...) available through Torrents. Most are only webseeded but a few are very popular like the Musopen full-res recordings.
We currently use Transmission when retrieving Torrents that have been uploaded to us but wanted to put in a feature request related to a more ambitious use of Torrents we are undertaking.
We've been talking for a while now with BitTorrent Inc about some protocol extensions that make Torrents work better for us and other large institutions like us. Our needs are a little different than most people using the protocol, even for e.g. large distros. We have a commitment to long-term availability of our collections, which is a bit of a different use case, it has some unique challenges.
One thing about our distribution of content is that almost all the time users request less popular Torrents and hence get them only via Getright style webseeds we provide. We don't maintain a super-seeder.
That's not a bad thing generally. Webseeding has worked great for us!
But, it DOES collide with the fact that our content on disk can change or update for various reasons, e.g. when the metadata (description text for example) is edited. When that happens the webseeded blocks fail until an updated Torrent is retrieved. In some cases on some clients, blocks that have changed on disk don't validate and the error is chalked up to e.g. transmission problems, and the blocks are automatically retried. In the worst case this means infinite looping trying to retrieve blocks unless the webseed is blacklisted as a peer or something. :/
The root issue is that currently clients have no established way to tell that the Torrent they have is outdated (has been deprecated).
Working with BitTorrent Inc we came up with a solution which is defined in BEP 39 -- the addition into the info block of a URL which can be queried for a new Torrent:
http://www.bittorrent.org/beps/bep_0039.html
Kind of a 'acceptable source' in the magnet link sense for an update.
The latest uTorrent Windows alpha supports this feature and we've been using it.
SO...
I'm popping in here to see if we could maybe get Transmission to support this feature!
The basic idea is pretty simple; if the info-block contains an update URL feed, before download a HEAD or GET is done on it; if the results indicate that a newer version exists, the new Torrent is retrieved before download).
Additionally, the client can (should for our use case...) poll for changes and hence automatically stay in sync with the 'remote' -- kind of a poor-man's mirroring.
The details and kinks are still being worked out of the implementation, but we're really keen on it and hope to encourage wider adoption/support for the idea.
Happy to go over the details if anyone would like to!
Our long-term strategy is to encourage and support the wide adoption of BitTorrent as a protocol for institutions like us with large vulnerable but non-static collections which would benefit from peer cloud mirroring -- to guarantee that collections do not go dark if the institution should, e.g., burn down. Just what BitTorrent is great for. Now we want to bring that to archives and libraries who have needed features like this to consider adoption...
...hoping Transmission can be part of that!
best!
aaron
PS btw the current uTorrent implementation does two cool things as well, one is that for this feature to be used by the client, it requires that both the original and new torrent be signed by the same certificate using the strategy described in BEP 35.
Also, since most of the time most content has NOT changed and especially if padding is used to align files to block boundaries, only one or two files might change, local blocks e.g. retrieved for earlier versions can serve as source for the updated torrent, as described in BEP 38.