[BitTorrent] Re: Trackerless BitTorrent
apoipoi at yahoo.com
Mon Dec 27 08:10:07 EST 2004
--- In BitTorrent at yahoogroups.com, Elliott Mitchell <ehem at m...> wrote:
> >From: apoipoi <apoipoi at y...>
> > For example there are four people peers: A, B, C, D.
> > 1. A has the complete file and makes the torrent.
> > 2. B downloads and opens the torrent, which contains the address of A.
> > 3. B connects to A.
> > 4. A is now connected to B. Since B already knows A and there's no
> > other address that might be of interes to B, no address is sent.
> > 5. C tries to connect to A.
> > 6. A is now connected to B, C.
> > 7. A sends C the list of address, which currently only has B.
> > 8. C now knows B and connects to B.
> > 9. B is now connected to A, B. Since there's no connection known to B
> > that is not know to C, then no address is sent.
> > 10. D comes into the scene by trying to connect to (for something
> > diffent), let's say to B.
> > 11. B is now connected to A, C, D. B sends the list (A, C) to D.
> > 12. D now knows, in addition of B, of A and C and tries to connect to
> > both.
> > The only necessary change to the torrent format is the list of
> > addresses. Which can be affixed at the end. The creator of torrent
> > would be the first in the list of course to ensure anyone can connect
> > and start downloading. As the "network" grows, this addresses can be
> > added to the torrent. The updated torrent file can be uploaded on the
> > web. Instead of every new clients connecting to A, they can
> > (randomly?) try B, C, or D. This will reduce the workload on A.
> Two fatal weaknesses. First, you've replaced a tracker getting bombarded
> with requests with the client A/torrent source getting bombarded with
A does not replace the role of tracker by being the (sole) keeper of
address list. There are only two events that may constitute as
"request" to A (or to any other peers):
(1) When a new peer (let's say) connects to A, where A givest it the
list of other address(es), and
(2) (Optional?) After the connection has been made, A informs others
in the network of a new address/peer. This is optional though, as B
now has the list may contact them individually.
All in all, the amount of "request" is far less than what is made to
Trackers are designed as webserver where there is no active connection
to any peer. It is not possible to send information about new peers to
currently connected ones. Thus -- correctly if I'm wrong -- it is
necessary to let peers request information periodically. With this new
method, since there is already an active connection why not use it.
And only sends information when needed, reducing the frequency to minimum.
The torrent file now also contains the list of addresses. Not only the
hashes. Peer A can then upload new torrent (with identical hash but
additional peers addresses) and new peers can connect to either one of
them. Yes, at the beginning new peers will recognize A since that's
the only address contained in the torrent. After say 20 peers are
connected to A and a new torrent make with total of 21 address
including A, new peers can connect to any of the 21.
Or to take this even further, after each successful connection peers
(e.g. A) may send the address of newly connected peer (e.g. B) to
tracker. Tracker will store this address. When a client tries to
connect it can request the peer the currently known list. Only the
currently known, therefore one request only. The rest goes as usual,
no more disturbing the tracker.
> Second, you've missed an important effect of the first function
> of the central tracker. That of keeping the network widely
> interconnected. With this scenario a client will tend to connect with
> nearby neighbors, forming cliches. With the tracker you'll get some
> nearby connections, but also a bunch that span the network, a client
> cannot do this.
New peer will be given list of addresses known to existing network (or
at least to the peer it is connecting to). This has always been the
case with trackers. The difference may be that trackers only send a
limited number and chosen randomly. This is to reduce the total data
size transfered and to cater to multiple requests. Ideally the
complete list should be given. What cannot be done currently (because
of sheer total request load) can be done with this new method as I've
The choice of which address to connect is up to clients. BitTorrent is
a protocol. There is no way we can enforce a law of which address to
choose (or to not choose).
Yes, we can specify that the list should contain limited number of
address chose randomly. But this will cripple the network. Instead
improving performance by introducing each peer to every other peers,
we limit them to just a few. Besides, any developer can choose not to
follow this particular rule.
However, I do believe all (or most) clients out there will not
discriminate peers to connect to and will not do so with this new
method. Except regarding banned addresses and the like.
> > Admittedly I haven't really thought this through in details so there
> > may be many mistakes and weaknesses. If this has been raised, my
> > apologies.
> (\___(\___(\______ --=> 8-) EHM <=--
> \ ( | EHeM at g... 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 --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
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