Standards (was [BitTorrent] Back to Merkle Hash Trees...)
Olaf van der Spek
OvdSpek at LIACS.NL
Tue Feb 8 09:19:09 EST 2005
>>>It messes up the code, because you cant allocate buffers until you receive
>>What's the disadvantage of the delayed buffer allocation?
> You start to get have messages for example before you know what they mean
> because you dont know the piece size. Even if you just connect to a peer
> to get the info blob it has to send you have messages. And a bitmap that
> you dont know whether it is the right length. You are going to have to
> cache all this stuff and process it later.
That'd be one option. You could also introduce a have_info message and
not send other stuff before you receive that.
>>>>>eg see the THEX paper.
>>>>No it doesn't. That paper says nothing about minimal transfer size.
>>>>It does mention 1 kbyte as base segment size, but my 'spec' uses 1 kbyte
>>>>as base segment size too but it doesn't use it as minimal transfer size.
>>>But if you cant transfer less than 32k, there is no point having the
>>>segment size less than 32k. As far as I can see.
>>The (only) point is to make the root hash (and top of the tree)
>>independent of the chunk/piece size and to maintain compatibility with
>>other uses of merkle hashes/THEX.
> But your implementation has a fixed 32k chunk so that dopesnt matter.
It does. I could change my implementation without invalidating old
> Being compatible with other uses, hmm, well I am not sure. Who else is
> using THEX?
I don't know. I considered the cost of being compatible lower than using
another base segment size.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> To unsubscribe from this group, send an email to:
BitTorrent-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
More information about the BitTorrent