David P. Mott
dpmott at sep.com
Thu Mar 24 12:17:44 EST 2005
> From: Kenneth Porter <shiva at sewingwitch.com>
> Subject: Re: [bittorrent] unforking
> --On Thursday, March 24, 2005 2:57 PM +0000 Justin Cormack
> <justin at street-vision.com> wrote:
>> The list of extensions on the wiki is fairly good, but I think it would
>> be a good idea to sort out the common ones that are actually in use, see
>> if they need any changes, document them properly etc.
> Which wiki is this?
> Forking doesn't necessitate incompatibility if there's a common fallback
> subset of features that can be agreed upon. Is there any negotiation scheme
> in place to allow clients to identify what extensions they have in common
> and can leverage?
Alas no, and there's the rub.
Bram has been adamant about forbidding anything that would carve out a
small part of the protocol for developer community use (for reasons that I
can't fathom). This would fall into that niche.
If we could just have a developer community maintained bitfield or some
such, a set of flags that we could define and extend, then we could get
*lots* of clients cooperating with *lots* of extensions.
In the absence of this, you're stuck to an approach like this:
1. Agree that there's a new message, called CAPABILITIES. It has a
2. Define what that response is, and what it means.
3. Understand that clients that don't support this message will
disconnect you (because that's what the original spec says).
4. Agree that, based on #3, all clients that want to make use of the
CAPABILITIES message may have to connect to each peer twice, since
they might get disconnected the first time after sending the
5. If you don't like #4, then you could just say that your client that
askes for the CAPABILITIES of other peers isn't backwards compatible.
And as soon as you say #5, then you aren't a bittorrent client anymore, so
you're stuck with 1-4.
It might be nicer, for forward compatibility, if the protocol had
originally stated that it'll respond to messages with NO_GROK or some
such, if it didn't understand the response. This implies that the NO_GROK
message had enough information in it for the recipient to understand what
the original request was...
More information about the BitTorrent