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.

Elliott Wilcoxon

[email protected] 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.
> 
> 


-- 
Fedora-config-list mailing list
[email protected]
http://www.redhat.com/mailman/listinfo/fedora-config-list