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

Bill Cox bill at
Tue Feb 8 09:27:27 EST 2005

> > > problem about get_info is that peers have to carry around enough information
> > > to recreate the info from teh torrent file (eg the filenames). The code 
> > > implementing the peer protocol shouldnt need to know about stuff like that.
> > 
> > It doesn't need to know. It just has to pass the info blob around.
> It messes up the code, because you cant allocate buffers until you receive
> it.

I've implemented the get_info/info messages in btslave.  It was trivial
to write, and certainly did not mess up the code.  One problem with
get_info/info is that it forces clients to keep the info blob handy.  I
keep it in memory.  That can add up to a lot of memory if I'm in very
many torrents (I'd like to be able to be in thousands).  Another problem
is that a peer has to be nice enough to transfer the thing to you before
you have anything of interest to him.  Needing to get 100K bytes from
one peer can be a problem.  Fortunately, Merkle hash trees make the info
blob many times smaller, effectively solving both problems.

The get_info/info messages are a nice fit with Merkle hash trees, and
make the xbtp:// URL much more reasonable in length.  They also help
with torrent caching, which may help keep ISPs happy.  Once Merkle hash
trees are there, the get_info/info messages are an obvious upgrade.


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