[bittorrent] BitTorrent - Open or Public?

arvid at cs.umu.se arvid at cs.umu.se
Thu Jun 16 13:50:50 EDT 2011


Hi P.G.

Quoting apropos at lavabit.com:
> [...]
> Two web sites currently exist : bittorrent.org and bittorrent.com. The 
> former seems to be dedicated to the advertisement of the protocol as an 
> efficient technology to reduce servers' load (and its development), and 
> the latter to the advertisement of non-free products based on that same 
> technology. My questionning arise from the fact that a .org domain is 
> supposed to be used by non-profit/community-centered organisations 
> (which seems to be used that way as there is no mention of the .com 
> website) but that, from what I can observe, it is maintained by the 
> same people than those from bittorrent.com (which looks like a conflict 
> of interests to me, the maintainer(s) of .org have email addresses at 
> the .com domain).

It's only a conflict of interest if you're paranoid enough to think that we
would censor people interested in extending the bittorrent protocol. Which
doesn't make any sense. All bad ideas voiced in the forums (so far) are obvious
bad ideas to most client developers reading it. No need for censoring.

> It also appears that some proposals were removed from 
> the index without notice (namely, BEP 0011). Also, most draft BEPs are 
> currently implemented in most transfer clients since a quite long period 
> of time and are still considered as drafts. What is, then, the goal and 
> manifesto of BitTorrent.org?

The goal is to provide a forum for bittorrent developers to discuss the
protocol
and extensions to it, and some sort of slightly more formal way to document
what
people come up with.

Anyone is welcome (and encouraged) to participate in these forums. There aren't
that many active users there though, but a few.

> If I may propose an answer, I think it is only to feed the commercial 
> quest of BitTorrent Inc. Having made the information available on 
> bittorrent.com rather than on bittorrent.org would appear like a 
> capital-centered solution; which would have been rejected by most free 
> software developers and probably have cause less interest than it had 
> (and still has) by the public.

That's sort of a funny assumption. The real answer is that BitTorrent Inc. is
too busy to spend any real time on the .org site. BitTorrent Inc. really just
provide hosting and people (typically it comes down to me) make updates to the
beps every now and then. I'm quite limited in how much time I have to maintain
the site though. Would you like to volunteer?

> [...]
> It can also be observed that some BEPs are missing (notably, BEP 11). 
> Although it is mentionned at bittorrent.org/beps/bep_0001.html that the 
> historical record can be found, BEP 11 cannot even be found in the 
> revision tree.  BEP numbers are not even consequent. Either numbers have 
> been intentionnally skipped, or documents have been removed without notice.

BEP 11 was withdrawn by its author as it turned out to be a bad idea, we didn't
want to implement it (he didn't) and no other developer at the time thought it
was a good idea either. I'm a bit surprised the files are gone though, are they
still in the subversion repository?

> If solutions like the DHT, the Fast extension, or the HTTP seeding 
> methods (wasn't the goal to reduce the servers' load?) are viable, why 
> are they still considered as drafts?

Because I'm too lazy to move them, and the process to transition BEPs to
accepted and final is still a little bit hazy to me. Most of the BEPs that are
published have been implemented by at least one client, most are quite
wide-spread.

> And why do the ones that were 
> accepted looks like the ones that will cause the less (if at all) 
> disruption of possible commercial politics?

coincidence. It was just the ones that had been implemented for a long time in
most popular clients at the time bittorrent.org was started.

> If my hypothetic answer is 
> right, I believe the DHT is still a draft because no one knows exactly 
> who is part of the swarm at a moment; multi-trackers torrent for the 
> same reason. Superseeding implies an acquisition delay that may not be 
> acceptable for paying clients. HTTP seeding could make a broadcaster 
> independent of paying solutions (which is actually the case anyway). 
> Fast extension suppose that a client is rewarded by contributing to the 
> swarm; which is certainly not interesting for costly products fore a 
> client could not pay for it.

All of those extensions you mention are implemented by uTorrent and BitTorrent,
both which are developed by BitTorrent Inc. Which sort of contradicts you
hypothesis.

> My answer is partly based on the aforementioned statements, some others, 
> and the lack of details in the specification (I prefer to call it a 
> description). BEP 0003 (the base specification) is only describing the 
> syntax of the protocol and is completely skipping its semantics; leaving 
> the student with the only solution to read the implementation of the 
> protocol to know what it is all about. I am not talking about a 
> rationale but, for example, what CHOKE is suppose to mean. If I choke, 
> are the pending requests still considered?

In the original specification there was a race condition in the choke message.
the Fast extensions fixed this by introducing the reject message. I bet you'll
understand how it's supposed to work if you read the fast extensions.

> Developers should not need to 
> rely on other clients implementation. I recognize that the protocol was 
> first publicized at a conference (CodeCon) and that working code is the 
> motto, but I believe that more efforts should have been made if you 
> really wanted to make something really useful to people.

It is possible to implement a complete client by just looking at the
documentation. My own implementation (libtorrent.org) was essentially
implemented straight from documentation + a lot of testing and experimentation.

My point is that the most important thing missing from the specification (and
what it sounds like you're asking for) is best practices. There was an attempt
to write up a document on best practices, but partly because of lack of time,
interest, forum and agreement, it fell apart.

> Is BitTorrent's evolution free of any commercial interests?

As long as the main client developers remains backwards compatible (which is
definitely the intention of BitTorrent Inc.) you can add any crazy extension
you'd like. If it's a good one and others are interested in it, write a BEP,
send it to me (editor at bittorrent.org) and I'll put it up. I might even implement
it in libtorrent if I like it, and if people like it at BitTorrent Inc. we might
even implement it in uTorrent. The evolution isn't more complicated than that.

Maybe you should join the forums over at forum.bittorrent.org, check out the BEP
section and read through the proposals and leave your comments on them. The ones
I've been working on lately are:

http://libtorrent.org/auth.html
http://libtorrent.org/dht_sec.html
http://libtorrent.org/dht_store.html

Please let me know if you would like to help out maintaining bittorrent.org, we
can use all help we can get.

-- 
Arvid Norberg


More information about the BitTorrent mailing list