Hi Peter- I totally agree. I'm not trying to attack Bram, and BitTorrent
has certainly changed things for the better overall. I'm just highlighting
the benefits of moving in a different direction, using standards to create
more powerful applications because they can all interoperate. It would also
avoid all the duplication of efforts going on now, like everyone writing
their own NAT traversal schemes instead of using the same open source
libraries implementing open protocols.
As far as development time goes, this approach *can* save a ton of time
because you can use open source libraries out there that are already
standards compliant. Many of those libraries are buggy or poorly written,
though, so you can also waste a lot of time on integration only to write
your own implementations in the end.
To me, BitTorrent is sort of a "proof-of-concept" of where this could go,
albeit an extremely powerful one in its own right.
-Adam
On 1/6/07, Peter K Chan <[EMAIL PROTECTED]> wrote:
Adam,
I see how the fully integrated approach can be a problem for you,
as someone interoperating.
However, I want to point out another way of looking at it: without
the fully integrated approach, we may still not have BitTorrent today. Bram
was working by himself when he designed and coded BitTorrent - he didn't
have an army of engineer working for him. To have made BitTorrent as quickly
as he did, he would have had to prioritize. Choosing Python as the
implementation language was crucial (if he had chose C as the language, it
may well have quadrupled the development time).
Similarly, he can only keep so many things in his singular mind.
There is tremendous advantage in using something that he understands and not
have to learn. So, inventing his own protocol was his way of tackling the
problem. Imagine if he had to spend months reading RFCs; deal with people
who use other clients (instead of his own, which he fully understands), and
even having to fix bugs because his client "isn't HTTP compliant." I am not
sure if BitTorrent could have come out as well as it did.
I am not arguing for the merits of how well designed the BT
protocol is. I just want to bring up a perspective that, if it was designed
any other ways, BT may not be here today for us to talk about.
Just a thought.
Peter
________________________________________
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] On Behalf Of Adam Fisk
Sent: Friday, January 05, 2007 2:47 PM
To: theory and practice of decentralized computer networks
Subject: Re: [p2p-hackers] HTTP design flawed due to lack of
understandingofTCP
Hi Peter- I've come to this view after closer work over the last several
years with the IETF and more intimate experience with protocol design in
implementing various IETF protocols, particularly within the SIP family. My
initial forays into protocol design came from working on many different
protocols on Gnutella, and some of the Gnutella protocols suffer from the
same problems as BitTorrent.
In a nutshell, well-architected protocols are designed to do very specific
things well. This allows each protocol to evolve independently, with each
protocol yielding control to others in the stack at the appropriate levels
of abstraction. In SIP, this approach is readily apparent and strikingly
effective, with SIP exclusively establishing sessions, leaving the Session
Description Protocol (SDP) to describe the session, the MIME specifications
within SDP to describe the type of media the session will handle, and with
STUN and ICE handling thorny NAT traversal issues. Each protocol is
independent of the others, with these discrete building blocks leading to
incredible flexibility as the protocols evolve. It also allows discrete open
source projects to be extremely focused in the protocols they implement.
One key to these principals is to re-use protocols effectively. With
everyone in the world implementing and understanding MIME, SDP can
interoperate much more easily if it also uses MIME. For file transfers, HTTP
is the universal standard for lots of good reasons. BitTorrent uses
effectively a proprietary file transfer protocol, thereby breaking
interoperability with the rest of the Internet. While BitTorrent is "open"
in the sense that anyone can implement it, it's almost worse than being a
closed protocol because it doesn't fit in with any of the very well-designed
other protocols out there. It would never have a chance to interoperate
with, say, SIP or XMPP because it just implements everything as it damn well
pleases.
I say the features of BitTorrent don't come anywhere near justifying this
because the primary reason for breaking HTTP is tit-for-tat support.
Tit-for-tat is basically providing incentive to keep your client running.
That's more or less fine, but that piece should not be coupled to file
transfers. At a protocol design level, that's just insanity. It also comes
at a tremendous cost. Every web server on the planet is now an invalid
source for a file! Excluding the most powerful computers on the Internet
from the distribution system doesn't seem like a sound design decision,
particularly for the poorly conceived tit-for-tat justification described
above.
I actually have lots of other issues with BitTorrent, but the protocol
layering issue might be the biggest.
-Adam
On 1/5/07, Peter K Chan <[EMAIL PROTECTED]> wrote:
Adam,
Your assessment of BitTorrent caught my attention.
How is BitTorrent "breaking interoperability with the rest of the
Internet?" Why is it that the unique features of BT "don't come anywhere
near justifying" it?
Peter
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
