Standards (was [BitTorrent] Back to Merkle Hash Trees...)
bill at viasic.com
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
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 yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
More information about the BitTorrent