[BitTorrent] Re: Trackerless BitTorrent

apoipoi apoipoi at yahoo.com
Wed Dec 29 03:23:54 EST 2004



> You're not solving the problem. You're also likely expending a
*lot* of
> bandwidth and needing to do a *lot* of bookkeeping on the client.
> 
> First, assuming 50 peers and retrieving 50 peers from each out
those.
> Resulting in a list of 2500 address/ports, minimum bandwidth of
15,000
> bytes (45,000 with IPv6) for the peer list. In a small swarm there
will
> also be a *lot* of redundancy here merely because there aren't that
many
> actual clients.

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
Exchange).
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
seconds.

> The real problem is the one I was pointing to above. From your peers
> you'll get other peers that are already close to you in network
terms
> (degree 2). This is extraordinarily unhealthy for the swarm. Any
piece
> you get from your peers will likely already be had by most/all your
peers
> (because they're already cross-linked). This results in bad download
> speeds because you cannot obtain any pieces your peers are
interested in.
> In fact it is quite likely your peers won't have much at all anyway
> because they can't get anything either. Pretty much you end up with
the
> swarm divided into bunches of independant islands/cliches,
completely
> destroying the effectiveness of BitTorrent.

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?

> With the tracker not only will you get a list of 50 unique peers,
but
> those will also be widely spaced across the network. This *cannot*
be
> done by peers telling each other about other peers.

How can the tracker be able to give anyone a list of unique peers?
Unless:
(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.


> 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.
sigh.

> Peer A will
> likely also have a limitation of the maximum number of peers it will
talk
> to, so with standard peers they'll start refusing connections once
> they've hit 55.

I wasn't saying that client has to connect to each and every peer in
the list. Client will receive the adddresses, store them, and choose
whether to connect or not. When another peer request the list, it will
give the entire content. Everyone should has complete list.

You raise an interesting point, i.e. when some peers reached a
connection limit and do not try to connect anymore. This may very well
cause inconsistency with the list across the network.

Maybe we should introduce the third exchange event: the old arbitrary
request? A peer may request a list from others at anytime. To make
sure its list confirms with others. Have to think about this some
more.

> Once you've got sufficient peers the standard client will stop
talking to
> the tracker to request more peers, it will merely say "I'm still
here" at
> a frequency specified by the tracker (so that new peers can connect
to
> it). There could be a small gain of allowing a client to specify it
> doesn't need more peers, or specify that it is full (will refuse new
> connections). Perhaps you should be looking towards increasing the
> rerequest interval of your trackers or decreasing the number of
peers
> returned? (particularly with large torrents that will take hours to
> download, why tell the tracker every 5 minutes you're still alive)

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?

> Gee, this is *exactly* what a tracker does! Only now it is *much*
easier
> to attack, and you've made the load on the original webserver much
larger
> as the torrent file is bigger. Yes, you have decreased the bandwidth
> somewhat by batching things, yet the loses are very bad and those
gains
> are dubious anyway.

That was just some brainstorming. In any case, we're thinking about
trackerless bittorrent so should try to solve any problem without the
use of trackers. Scratch that part out. ;)

> Though limiting the size of the request might be the justification
> mentioned in the protocol specification, it also has the *far* more
> important effects mentioned above. Mainly you get peers widely
spaced
> across the network and therefore likely to have distinct sets of
pieces.
> If you get the full list from a peer, not only will you peers that
are
> close together, but you're just made the request much larger.

The addresses on the list from trackers are chosen randomly. A peer
may very well hit the jackpot and received high-speed/low-latency
uploaders, who live next door, with no capping at all. Or not. The
point is: it is random.

> Yes, a peer can be smarter and make a better choice about who to
attempt
> to connect to. Unfortunatly if the list is sub-optimal even the best
> algorithm/heuristic to choose will be useless.

Giving sub-optimal list does not fix the problem. The client can still
choose to connect only to the nearest peers.





------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/dkFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
    BitTorrent-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





More information about the BitTorrent mailing list