[BitTorrent] Re: Trackerless BitTorrent
ehem at m5p.com
Thu Dec 30 20:16:46 EST 2004
>From: apoipoi <apoipoi at yahoo.com>
> Maybe I didn't explain this clearly. There are only two events in
> where address exchange took place: (1) first connection -- let's call
> this "Initial Exchange" and (2) new connection which happens to others
> -- "Update Exchange". Consider A, B, C, D. A + B already connected.
> 1. C connects to A, request the list, and given the address of B.
> (This is the first event -- Initial Exchange)
> 2. C connects to B. But, does not request the list again.
> 3. D connects A, request the list, and given B, C. At the same time A
> informs B, C the address of D. (This is the second event -- Update
> Any peer may choose to connect to all or not, nevertheless every has
> the complete list. And no redundancy whatsoever.
> 1000 peers = (6-byte-address) + 2-byte-port) * 1000 = 8,000 bytes.
> Takes merely a couple of second out of Dial-Up 56kbps connection. Yes,
> that's optimistically, but it should be no longer than say ten
Extraordinarily *bad* idea. Might seem like a good idea at first, but it
isn't. Pretty much boils down to you're introducing every problem faced
by packet-switching networks into the BitTorrent protocol.
First I'll bring up the one that isn't from networks that you're directly
introducing. You've made the torrent file *much* larger, and you've made
it writable by clients. So, torrent files spend 80 bytes per megabyte of
payload. 80K for a one gigabyte file. Well, for that 1000 peer case the
overhead is 6,000 bytes, 4 bytes per peer for an IPv4 address and 2 bytes
of port. If IPv6 finally comes in (oh gee, China's new giant network
project does v6 directly on the backbone!), it will be 18,000 bytes due
to the 16 byte addresses. You're 7-20% overhead on the server where the
torrent resides. For 56K of torrent (CDROM, many Linux distributions)
and 10,000 peers, you're adding 100% overhead. This is better than a
small tracker? Making the torrent writable by clients is also strongly
Next, what of the overhead of those connect/disconnect broadcasts.
Assuming a file of one gigabyte (there are much larger ones out there,
but *lots* of smaller ones), and say 1,000 clients with an average
connection of 256kbps. Assuming ideal conditions downloads will take just
over 9 hours. There will be other things going on slowing things down
and seeders staying connected for an extra long period of time, so let
us say the average client will remain connected for 10 hours. Each of
these will generate a connect and disconnect message pair. So, 1,000
clients and 10 hours will produce a disconnect or reconnect message
every 18 seconds. At 1,000 clients you're producing an additional message
for every two HAVE messages. With 10,000 clients you're increasing the
overhead by 500%.
Have I given you sufficient proof that the overhead is much too great?
Okay, the network problems. The one that comes to mind is this one. Maybe
I accidentally stopped my client just a little bit too early. So I need
to reconnect and get one more sub-piece. I guess I'm an evil guy since I
tell my client to connect, and then disconnect a half second later when
it completes. Guess what happens?
Well, during the connect all my peers will broadcast out to the swarm
that there is a new client. Then I disconnect and all my peers broadcast
to the swarm that a peer has disappeared. The problem is those will echo
through loops in the mesh. Unfortunatly the disconnect may happen quickly
enough that the connect message is still echoing across the mesh.
Somewhere there is pretty certain to be a loop (or more likely,
*hundreds* of loops!), the connect message enters the loop and clients
start processing it and passing the broadcast along. If the disconnect
enters the loop before the connect leaves the two messages will chase
each other around the loop generating a continuous stream of
connect/disconnect messages, filling the swarm with garbage.
Really nasty, and we haven't even gotten to malicious clients yet. Just
say no, this would introduce *massive* complexity for dubious gains. If
the load on your tracker is too high, perhaps you should decrease the
frequency with which clients reconnect?
> Hmm I do not understand where you get the idea that a new peer will
> get only the close others. Anyone should receive the same addresses
> like anybody else. Care to explain, maybe I missed something?
> How can the tracker be able to give anyone a list of unique peers?
> (1) the tracker has the complete list of which peer has already known
> which other peers, or
> (2) the requesting peer specify what it already has, each time it
> makes a request.
> Database and storage nightmare for (1), and an unefficiently and
> unnecessarily long request arguments for (2).
> I don't think either of them is the case. The tracker chooses randomly
> the 50 peers. And this is specified by the protocol (at least from
> what's written at http://bittorrent.com/protocol.html). Thus the
> tracker cannot guarantee the list to be unique. Indeed since it is
> random a peer may very well receive a list that contains only nearby
> other peers.
This is detritus from trying to keep these two diverging threads
together. Covered in my previous message, and only affects that one.
> > Really? Sounds like precisely the same amount of data as that sent
> to a
> > tracker. Worse, you're now trusting peer A to be running and giving
> > correct information (suddenly DoSes become *really* trivial).
> Well you're talking about two different things here: the protocol
> itself and methods to exploit it. It is not impossible to abuse
> current BitTorrent protocol as it is for attack. But that's another
> story for another time. ;) Nothing is perfectly secure. Unfortunately.
But all those existing protocol attacks are of limited scope and have
reasonably effective countermeasures. What you're proposing *invites*
massive attacks that cannot be countered. With the MPAA and RIAA out
there, these *will* be tried. Not to mention evil clients trying to get
better downloads. To suggest a few:
The torrent is writable (so the peers field can be changed during
disconnects/reconnects). Since I'm an evil client, how about I remove
everyone else? Now everyone connects to me, I'll get exclusive access to
any seeds that join. How about I simply corrupt the hashes (the MPAA and
RIAA would *love* this one)? The solution to both of these is to make the
keeper of the torrent file smarter, but you've just reintroduced tracker
type intelligence. How about I flood the swarm with connect messages for
bogus peers? I'll easily tear the swarm fabric to shreds here.
> It still use processing power though. Not to mention inefficient and
> unnecessary. Why waste a good server only to keep track who is still
> alive if the same thing can be done by between peers themselves.
> Besides, that was not my point. If BitTorrent can truly be
> decentralized, then its advance and spread would be massive. As it is
> right now, the "bottleneck" is on the dependency on trackers. We
> should always try to improve shouldn't we?
That is a double-edged sword, the peers *cannot* maintain the list in a
reasonable fashion. Removing more centralization makes trust a much
bigger issue, as it opens more attack paths for the clients (and if they
exist *someone* will attempt to utilize them).
(\___(\___(\______ --=> 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 Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
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