Re: BitTorrent based update mechanism
Nice job, it's like you read my mind. However, I suggest that instead
of a million small .torrent files sent as part of the update summary,
one large one be sent. The large one would have the meta-info for a
completely updated system. The End User's client then just downloads
the specific updates that the user wants (several clients support
downloading selected files in a torrent, instead of the whole thing).
Unless, of course, the size of the larger .torrent is prohibitive; I'm
unaware of how .torrent filesize scales with the number of files that
the .torrent contains information for. There could be other issues with
one large torrent and/or many small torrents, something you might want
to research for v2 of the paper?
Also, to prevent the whole thing coming down should the tracker become
unavailable, I suggest that the multi-tracker spec be used (
http://home.elp.rr.com/tur/multitracker-spec.txt ). AFAIK, the most
recent official Bittorrent client doesn't support it, but many
unofficial open source clients support it, so I don't forsee its
inclusion as a huge problem.
I've written a short paper on how BitTorrent could be used in an update mechanism (i.e. a method that coule be integrated into up2date). This should help those who have bandwidth problems with the amount of downloads they get(such as the Fedora Legacy project).
I've put the paper online at http://www.argosytelcrest.co.uk/papers/btupdate.html and I'd appreciate any comments anyone has on the ideas.
[Fedora Legacy Announce]
[Red Hat Development]
[Red Hat 9 Bible]
[Red Hat 9]
[Big List of Linux Books]