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

Justin Cormack justin at street-vision.com
Tue Feb 8 11:02:25 EST 2005


> 
> 
> >>>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.

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.
 
> >>>>>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.

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 the issue of piece size may be relevant too.

Justin
 


 
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:
    BitTorrent-unsubscribe at yahoogroups.com

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





More information about the BitTorrent mailing list