Re: BitTorrent based update mechanism

[Elliott Wilcoxon <elliott@xxxxxxxxxxxx>]

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.

Elliott Wilcoxon

fedora@xxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> All,
>
> 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.
>
> Regards,
>
> Al.