[BitTorrent] XML Torrents?

Elliott Mitchell ehem at m5p.com
Sat Mar 12 02:24:46 EST 2005

>From: Kenneth Porter <shiva at sewingwitch.com>
> --On Friday, March 11, 2005 8:29 PM +0000 Konstantin 'Kosta' Welke 
> <kosta at fillibach.de> wrote:
> > Also, the torrents are already too big, they should be an url like http
> > or ed2k do it. That why there are efforts to eminate them in bt2.
> Looking at the spec <http://www.bittorrent.com/protocol.html>, I see a 
> filename (or list of filename/length pairs), tracker URL, and a set of 
> fragment checksums. Most of the size would be the checksums. How do you 
> propose shrinking this to fit in a URL? I suppose you could designate 
> trusted peers (eg. initial seeds) to host the checksums.

There is talk of the BT2 protocol. Something similar to that would likely
be done.

> >> Is bencoding so special? If the original BT protocol had been written in
> >> Perl, would everyone be raving about Data::Dumper format? (And I recall
> >> that PHP has its own data structure dump format.)
> >
> > bencoding is not some "binary dump" format. You can think of it as "XML
> > without the bloat", i.e. Easy to parse, space-efficient, easy to extend,
> > but harder to read for the human eye.
> My point was just that bencoding is a Python-centric structure dump. 
> Data::Dumper is the Perl equivalent, and PHP also has a structure dump.

Python-centric? Doesn't look that way to me. The bencode format might of
been created with Python in mind, but it in no way imposes anything that
can be considered Python-centric. Should take less than 5 minutes of work
to produce a parser for your language of choice.

>From: Kenneth Porter <shiva at sewingwitch.com>
> --On Friday, March 11, 2005 12:26 PM -0800 Elliott Mitchell <ehem at m5p.com> 
> wrote:
> > [info_hash's] provide proof that the data blocks have been transfered
> > successfully. This includes showing that the peer isn't sending you
> > garbage hoping to fool you into given credit for pieces you haven't
> > transferred.
> Looking at the Tracker GET request in the protocol spec at 
> <http://www.bittorrent.com/protocol.html>, I don't see how the info_hash 
> provides any integrity. I understand how the fragment hashes do that, but 
> those are computed from the payload file, not the metadata file, and aren't 
> sensitive to the representation of the metadata.

May of messed up contexts.

Hashing the payload is the way to go for the info_hash. Since the payload
is what you care about, that is the natural thing to identify the torrent
to the tracker. You don't want to hash the metadata file, as that is
merely a means to an end, not the end in and of itself.

> I also don't see any mechanism for preventing spoofing of one's statistics 
> to the tracker.

There isn't. Bram's thought is not use the statistics for anything, but
information. The reasoning being that you can't prevent the spoofing
thereof, so why bother? As long as you use it *strictly* for
informational purposes, there is no incentive to spoof them.

(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EHeM at gremlin.m5p.com PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

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 mailing list