[Ffmpeg-devel] What happend to www.mplayerhq.hu

[Jan Knutar]

On Saturday 15 October 2005 22:15, Mike Melanson wrote:

>  Maybe it's time to consider an alternate samples archiving and 
> distribution method. I was wondering how well BitTorrent would work for 
> such an application? I am not sure how it works, though, if one were to 
> add another sample to the repository already in distribution.

BitTorrent is lousy for archiving anything. It shows it power at distributing
a large archive to many /simultaneous/ downloaders. Typically, once interest
and demand has gone back to low, there is only the original source left, if
even that.

Adding more samples to an existing BitTorrent "distribution", to use your
terminology here, requires the .torrent file to be respun, and for every participant
in the torrent swarm to re-download the .torrent. In practice this would be a
manual operation, and the clients would re-hash the locally existing files (bt
uses a sha-1 checksum).

The other alternative is to make each individual sample file an individual torrent,
but again that doesn't give you automatic distrib to everyone attempting to
participate.

>From a practical point of view, a tracker and original source would be needed.
If the tracker becomes unreachable, the entire swarm dies. If the original source
(seed) goes down, the torrent is likely to be dead quite soon.

For one torrent per file case, depending on the client, you would have to run one
instance of the client, per file in the samples archive, and manually each person
would have to add new torrents and fire up more clients. With one torrent for entire
archive, people would have to redownload the .torrent file and restart their client
whenever anything in the samples archive changed. BitTorrent would automatically
detect differences from current local copy, and just download the difference, more
or less.

>From a mirroring point of view, it is entirely possible to automate bittorrent as an
rsync replacement. For adding files, it would be atleast as efficient and fast as rsync,
for modifying files, assuming uniform bandwidth situation, rsync would probably be
faster. If the site acting as mirror has a very slow connection to the master site, but
very fast to other mirrors, then bittorrent would automatically have data go through
the other mirrors, resulting in faster mirroring than pure rsync from master alone.
While it's relatively easy to automate periodic rsync for syncing mirrors, bittorrent takes
a bit more scripting to do automatically.

In any way, the myth/dream that you can put something on BitTorrent and that it
magically will live forever and ever is not real. It's best to consider BitTorrent as a
transport method, a damn efficient transport method that scales extremely well,
but that's basically all that it is.