Wes, On May 23, 2012, at 9:22 PM, Wes Hardaker wrote:
> Bittorrent works well for sharing the load, but either requires a lot of > bittorrent start files (whatever they're called), which then becomes > hard to syncronize; or a small number of bittorrent files (one per > aggregation point) that indicate you need to refetch and entire .zip > file even if you already have most of it anyway. I'm far from an expert on Bittorrent but I believe this is not right. A .torrent file (what you called a "bittorrent start file") can contain contain a list of files to be transferred, there's no mandate to zip them into a single file first. Presumably the BT protocol is smart about not transferring files you already have locally -- that's kind of the whole point. Rob's "operational overview" slide makes it clear he's imagining operating in the collection-of-files mode. Probably there are some issues with this mode of operation too -- if you list every single RPKI object individually then the size of the .torrent file scales linearly in the size of the unauthenticated/ tree. This seems likely to suck since I am guessing BT's normal operating regime is to transfer small numbers of large files rather than potentially vast numbers of relatively tiny files. The zip files Rob's slides talk about just contain the .torrent file and manifest (which is also O(N) in the size of the tree, sigh). Speaking purely as a Bittorrent amateur + not the author of the slides! --John _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
