Have compression (was Re: Standards (was [BitTorrent] Back to
justin at street-vision.com
Wed Feb 9 07:06:00 EST 2005
> > Your solution of chunk-haves can be used for reducing latency, but doesnt
> > suggest strategies for how to use it, and when you use it it always increases
> True, but as different usage strategies don't (always) require different
> protocol syntax, I'd consider that less important.
But you add protcol syntax, 2 special cases. My suggestion only has 1.
> > bandwidth. My version starts to suggest how to use it, and has other side
> > effects like reducing the load on seeds and near-seeds as they dont have
> > to send out bitmaps, they can send high order have messages.
> Also true, but my extension was specifically designed to keep the
> changes as simple as possible.
> Changes in the p2p protocol are (IMO) easier to make (via extension
> bits) then major incompatible changes in the .torrent format.
extension bits are generally not very good ways to change protocols, as any
client that doesnt understand them will probably just hang up as they dont
understand them. Actually with the BT peer protocol, mandating that commands
that you dont understand are ignored (as they have a size this is pretty
easy to do, though you might penalise peers that send you lots of stuff
you dont understand...)
There are 2 issues here.
1. Merkle trees change that entire protocol in non compatible ways, so it
is a great opportunity to change everything. There is no advantge to
having a piece size in the torrent file for "small change reasons".
2. The reason for this initial thread is that I am interested in a
standards track (ie accepted RFC) protocol that fulfills the functions
of bittorrent. Currently there is a de-facto standard (even if it is not
well documented) of BT1, but as I said at the start of this thread I dont
think it is acceptable as an RFC in its current form. I dont think Bram's
BT2 will be either, as even outside the technical reasons, there needs to
be a standardisation process involved.
Now I am interested in standards because I work for a *very* small company
and we cant make up our own standards like large companies. Our potential
clients only want open standards (and open source often). So BT1 is kind
of ok as its quite simple, de-facto, best we have at the moment. BT2 is
of no interest whatsoever. If it becomes more widely used than BT1 in a
few years then well its another de-facto standard perhaps.
I also think that it is very important in legitimising this type of protocol.
You cant really ban an IETF RFC...
It is less clear to me whether anyone else is interested in this.
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