Re: Standards (was Back to Merkle Hash Trees...)

>>>It messes up the code, because you cant allocate buffers until you receive
>>>it.
>>
>>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 
.torrents.

> 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:
    http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/