Bittorrent and Enclosures

Dave and Andrew Grumet are thinking along the lines that bittorrent is going to be an answer to the enclosure popularity problem. It shouldn’t be that hard to do, even given current tools.

Consider this setup using the current Radio Userland/XmlStorageSystem architecture.
There would need to be an installation of the bittorrent programs on both the client and the Cloud machine.

The cloud server could be configured to report a bittorrent tracker url as a resource that it provides, similar to how discussion servers are configured. This does not have to be the same machine as the cloud server.

  1. When the client sees that there is a gem of > some threshold, it runs the btmakemetafile.py script on the gem and uploads both the resulting .torrent and the gem files.
  2. Once the upload is complete, the cloud server kicks off a bittorrent download client pointing to the uploaded file, perhaps with a process lifetime of 1 day or so. This is the seed downloader that provides the initial copies to the cloud.
  3. The client uses the .torrent url as the enclosure in any rss feed that it produces. Most likely, the rss feed would need to be uploaded after the gem, to ensure that the torrent is already available.
  4. Optionally, the uploading client also starts a download client pointed at the existing file – to provide another early feed. We can’t rely on this as the sole seed feed though, since the client is likely to be disconnected from the net at times.
  5. Rss aggregators using the .torrent files can be programmed to leave their download process running for a few hours after the download has been completed.

There’s a good chance that this would reduce the bandwidth needs and push bittorrent adoption across feed readers that support enclosures — especially if the rss feed writer only includes a link to the .torrent.

No comments

No comments yet. Be the first.

Leave a reply

You must be logged in to post a comment.