Standards (was [BitTorrent] Back to Merkle Hash Trees...)

Olaf van der Spek OvdSpek at LIACS.NL
Tue Feb 8 11:14:52 EST 2005

Justin Cormack wrote:
>>>>>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.
> The other major problem is when conencting to a torrent, if most peers use
> the URL encoding it will be very hard to find a peer (ie the seed) that has
> the info data. If there are a lot of clients all at once there will be a large
> delay before anyone can do useful work.

The first thing any peer does, is get the info. The info is probably 
very small (size depends on the file count), so would that really be an 

>>>>>>>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.
> Personally I think 4k as a chunk size and hashable size makes sense as this
> is the most common page size and file system block size so it is the amount
> that will be written to disk anyway, and its not too small.

But what is the advantage over 32k? Do you consider 32k too large?

Yahoo! Groups Links

<*> To visit your group on the web, go to:

<*> To unsubscribe from this group, send an email to:
    BitTorrent-unsubscribe at

<*> Your use of Yahoo! Groups is subject to:

More information about the BitTorrent mailing list