This page is an attempt to compare mirroring with bittorrent as principally as a software distribution mechanism. I'm not a mirroring guru, nor a bittorrent guru; nor am I infallible.
- Mirroring is substantially more simple and better understood from a technical point of view. While there are a few new developments in recent years (such as rsync/gzip and the move to sftp), on the whole mirroring is a well known, stable science built on well-known stable protocols. Bittorrent represents a move away from these well known protocols towards a substantially newer protocol.
- Mirroring is built from simple protocols (ftp, http and rsync), which are inherently less complex than the bittorrent protocol.
- Bittorrent minimises the dependency on a single site or service. With bittorrent, most content is delivered to most downloaders from peer sites rather than well known addresses and machines. These central machines serve only as rendezvous points (called trackers), matching up users who want to download the content with those who have already downloaded it. They may act as servers of last resort for serving the content to users, in which case they fall back to a model very much like the mirroring model, only less efficient, because of the extra overhead.
- Once a client has rendezvoued, it is almost impervious to network and server disruption and client reboot. Obviously no download can happen when the client is not running, but if the client is running and can connect to a single peer then the download will be automatically resumed.
- Institutions, projects, organisations and individuals can contribute bandwidth piecemeal to a bittorrent swarm with no expense or administrative overhead at the rendezvous points.
- Bittorrent is inherently more suitable for downloading content from a tape library or other high latency storage media because it has multiple levels of retrys and fail-overs. A client will wait indefinitely (and across reboots) for requested data to arrive, rather than timing out as ftp, rsync and http implementations do.
- Bittorrent has an overhead to package software into a torrent and then distribute that torrent file. The economics of this overhead mean that bittorrent is more suitable for large or very large files (application installers and iso images) than for smaller files.
- Bittorrent does not have the notion of versions or updates. It has no HEAD request as HTTP does.
Some of the services that could sensibly be offered around bittorrent by a regional / national / pan national body include:
- RSS feeds of interesting torrents. Bittorrent clients can be configured to automatically download and serve torrents published in an RSS feed, and existing RSS tools would allow the RSS to be filtered accouring the users interests and requirements. The torrents might be new torrents, frequently downloaded torrents, "good" torrents, reviewed torrents...
- A local tracker service. This might involve republishing torrent files with additional of trackers based network-locally (with *.ac.uk, *.eu, etc) this would make downloading these significantly more robust globally, but particularly within those domains.
- A local bittorrent builder and hoster service. This would involve helping individuals and institutions distribute their software (or content) via bittorrent, with the service providing serving the first copy of the torrent and being its tracker.
- A framework for the on-going discussion of the interaction between peer-to-peer systems and network acceptable usage policies.
Links:
Bittorrent reference implementation: http://www.bittorrent.com/
Azureus Bittorrent: client http://azureus.sourceforge.net/
Legal torrent sites: http://azureus.aelitis.com/wiki/index.php/Legal_torrent_sites
Multi tracker spec http://bittornado.com/docs/multitracker-spec.txt
