On Thu, May 24, 2012 at 4:13 PM, John G. Scudder <j...@juniper.net> wrote: > 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.
per publication-point I think? So you have to collect N-thousand of these torrent files, and keep N-thousand torrent jobs running and keep state on N-thousand remote torrent files changing over time... some of this could be alleviated in many ways, worst case though is that. > 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. well, folk like fedora/ubuntu/etc offer full distributions over bittorrent ... I've not done a find . | wc -l on a system like this in a long time, but 4-8 gb over bittorrent for a few thousands of files seems to work fairly well for them. > 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). maybe looking at a bittorrent-like solution for intra-as distribution is interesting though? though that also seems (to me) to fall into 'local implementation' land, from the vendor/arms-dealer that sold me the solution. > Speaking purely as a Bittorrent amateur + not the author of the slides! me too, as an amateur of bittorrentz I mean. -chris > --John > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
