Re: Trackerless BitTorrent

Ack sorry the previous reply has horribly broken grammar and
misspelling. Hopefully this one is better.

--- In [email protected], Elliott Mitchell <ehem@m...> wrote:
> >From: apoipoi <apoipoi@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
> requests.

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 B) connects to A, where A gives 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 and may contact them individually.

All in all, the amount of "request" is far less than what is made to
trackers.

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 -- correct me 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 send 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 updated torrent (with identical hash
but additional peers' addresses) and new clients can connect to either
one of them. Yes, at the beginning new clients will only recognize A
since that's the only address contained in the torrent. After say 20
peers are connected to A and the torrent file updated 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 from the tracker the currently known list. Only
the currently known and at the beginning, not periodically. 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 which is 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 explained above.

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 chosen randomly. But this will cripple the network. Instead of
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 of) clients out there will not
discriminate which peers to connect 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.
> 
> Happens.
> 
> 
> -- 
> (\___(\___(\______          --=> 8-) EHM <=--         
______/)___/)___/)
>  \   (    |         EHeM@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 --------------------~--> 
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:
    [email protected]

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