On Sat, Jan 8, 2011 at 2:17 AM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: > On Fri, Jan 7, 2011 at 10:59 PM, Luke Kenneth Casson Leighton > <luke.leighton@xxxxxxxxx> wrote: >> Âbottom line: my take on this is (sorry to say, nguyen) that i don't >> believe bittorrent "pieces" map well to the chains concept, unless the >> chains are perfectly fixed identical sizes [which they could well be? >> am i mistaken about this?] > > there are a few characteristics of bittorrent pieces that i see: > verifiable, resumable, uniquely identifiable across peers and > reasonbly small in count. > > The fixed size helps peers uniquely identify any pieces by splitting > the whole transfer equally and indexing them in 1-dimension. ok - you haven't answered the question: are the chains perfectly fixed identical sizes? if so they can be slotted into the bittorrent protocol by simply pre-selecting the size to match. with the downside that if there are a million such "chains" you now pretty much overwhelm the peers with the amount of processing, network traffic and memory requirements to maintain the "pieces" map. if not then you now need to modify the bittorrent protocol to cope with variable-length block sizes: the protocol only allows for the last block to be of variable-length. also, it's worth pointing out that the entire code-base of every single bittorrent client that you will ever be able to find revolves around the concept of reassembly of files from "pieces". bottom line: the bittorrent protocol and the available bittorrent source code libraries, both of which save you a great deal of time in getting something up-and-running, is _not_ the right fit for the concept of placing the proposed "chains" into bittorrent "pieces". translation: if you wish to pursue the "chains" concept, either a heavily-modified bittorrent protocol and client _or_ an entirely new peer-to-peer protocol is far more appropriate. orrr, doing what i initially suggested, which is to leave the bittorrent protocol as-is and to open one .torrent per "chain". especially if these "chains" vary considerably in size (k to gb) l. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html