[BitTorrent] XML Torrents?

Elliott Mitchell ehem at m5p.com
Fri Mar 11 15:26:50 EST 2005


>From: Kenneth Porter <shiva at sewingwitch.com>
> --On Friday, March 11, 2005 10:18 AM +0000 Justin Cormack 
> <justin at street-vision.com> wrote:
> 
> > Actually the character encoding and space reasons are relatively minor.
> 
> Yeah, I don't see the point of saving 20 bytes when we're dealing with a 
> protocol designed to transfer hundreds of megabytes. 

Key issue here, the hundreds of megabytes are transfered between peers
with major bandwidth. The torrent file may come from a heavily bandwidth
constrained system in Antartica.

> Penny-wise/pound-foolish. For larger XML files, the "bloat" can easily be 
> dealt with using commonplace compression like deflate. For example, 
> OpenOffice documents are stored in zipped XML collections. Much of the 
> bloat is caused by the large in-line descriptive tags, and those are 
> natural candidates for leveraging dictionary-based compression.

However, once they're that large, they're effectively no longer human
readable.

> > For many purposes it would be very useful to have a text format (eg to
> > send a torrent by email). However it is required that there is a unique
> > representation of the info portion of the torrent file so that the info
> > hash can be generated (hence the rules about ordering of fields in
> > bencoding). XML doesnt give you a fixed representation, so you still need
> > some canonical form.
> 
> I see what you mean. It looks like the hash is used as a short-hand way of 
> representing a given metadata file, to be used as a key into the tracker 
> and peer state machines to identify a given swarm. Does the hash serve a 
> security purpose, or just an identification function? If the latter, the 
> authoring application could hash the initial contents of the XML 
> representation that it's written and append it as a final element. This 
> would provide the required uniqueness without requiring that a particular 
> representation be maintained by those communicating the content.

Nope, they 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
transfered.

> To me, the advantages of XML are extensibility, self-documentation, and 
> easy validation. Plus the wide availability of tools to manipulate the 
> format. This makes it easy to implement the tracker part of new clients in 
> any language that has an XML parser, and makes it easy to extend the 
> protocol. Since the tracker acts as a web server, and XML has web origins, 
> it also makes it natural to adapt existing web machinery to do the job.

Easy validation? This is why the tools to do so are large? This is why
a lot of folks have gotten it wrong, leading to security holes?

The tracker is assumed to have very limited bandwidth, therefore using
XML with its bloat is a bad thing there.


-- 
(\___(\___(\______          --=> 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:
    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