Comment 5 for bug 319529

El Miércoles 21 Enero 2009, Rehan Khan escribió:
> Therein lies the rub. If you have a swarm where people are only getting
> a few files from the torrent the number of seeds would be quite low and
> the number of peers would be relatively high. This may result in
> relatively low performance of the torrent. Torrent's are more suited to
> large static un-changing blobs of data (video, iso's etc) for this
> reason.

I have torrented large collections of files selectively with no performance
impact. And since the torrent is Web-seeded, there is no negative performance
impact -- only positive. Furthermore, the latest batch of critical must-ahve
updates (or rather, the popular cluster of torrent chunks containing them)
will ALWAYS have seeds because everybody requests those. And what you care
about is optimizing most-popular use case, not *everything*.

>
> Also for the very small files the ratio of setup traffic/data
> transferred would be very high and thus it would be in-efficient.

Why? Or, put it in another way, what is impeding this implementation to put
only large (say above 10MB) files inside the torrent file list, and use the
traditional mechanism for small files?

> An alternative would be to use an edonkey/emule p2p protocol which
> performs better for small files. Still it has it's own issues.

True. True. I just referred to BT because it's stable and has many python
implementations.

>
> Another method would be to use torrents to synchronise mirrors which is
> a more practical use.

That's also conceivable but it still means people have to download from the
*mirrors* instead of from nearby computers (an optimization that becomes
possible if using BT).

--

 Manuel Amador (Rudd-O) <email address hidden>
 Rudd-O.com - http://rudd-o.com/
 GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/

The trouble with the rat-race is that even if you win, you're still a rat.
  -- Lily Tomlin