guanying_wang
2005-02-19 06:08:21 UTC
My proposal is based on a fact that the same contents are tracked on
different trackers.
Say, there are two trackers inside our campus lan, some files are
tracked by both trackers. Peers tracked by one tracker cannot connect
to peers tracked by another tracker. But actually they are doing the
same job, they should do it together.
I propose that trackers communicate with each other, share their
database. Then peer connecting to one of the trackers, can get a lot
of other peers tracked by other trackers. In this way, trackers are
acting much like SuperNode in Kazaa. A tracker's capacity can be
limited, and it can suggest other trackers for peers beyond its
capacity. (This will also need client program to support.) The scene
is much like Kazaa, lots of trackers exists, each tracking about 100
peers, and peers can connect to all other peers in the world
downloading the same content. IMO the scalability is improved to a
great extent.
There can be some filter everywhere. For example, we have 10.*.*.* and
also 222.205.*.* ip address, some of 10.* can connect to 222.205, but
some others cannot. A peer from 222.205 tell the tracker, "I want
peers from only 222.205, but not 10.*." The tracker will return only
222.205 as the peer requests. Another example, 10.* are firewalled,
they can only access ip address outside our campus lan with a "dynamic
ip", that is, an ip address different than 10.*, and assigned
dynamically, like 210.32.*.*. If a tracker outside our campus lan
shares peers info with the tracker inside our campus lan, the 10.*
peers are not to be shared.
Later maybe we can connect the trackers into a higher level p2p
network, maybe a structured P2P.
Multitracker is also a proposal to solve this issue. I think
tracker-tracker communication can be deployed along with multitracker,
they don't conflict with each other.
A problem is the torrent file. Tracker info is written in the torrent
file, do I have to generate a new torrent file with multitracker
extension? I haven't think of a good point.
Another issue is that torrent file is a whole, maybe some files within
a torrent are being tracked, then another forum distribute a new
torrent file, only adding some of forum ad text. Two torrent are doing
the same job, and I think it's better we can let them do together. We
can calculate hash on every file seperately, just as what was done in
"Merkle Tree extension"[1] by Olaf van der Spek. And the tracker do
not categorize peers by torrent files, but by every single file
seperately. Unfortunately this will not be backward compatible.
Comments are welcomed. Thank you.
Guanying
[1] http://62.216.18.38/bt_merkle/
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-***@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
different trackers.
Say, there are two trackers inside our campus lan, some files are
tracked by both trackers. Peers tracked by one tracker cannot connect
to peers tracked by another tracker. But actually they are doing the
same job, they should do it together.
I propose that trackers communicate with each other, share their
database. Then peer connecting to one of the trackers, can get a lot
of other peers tracked by other trackers. In this way, trackers are
acting much like SuperNode in Kazaa. A tracker's capacity can be
limited, and it can suggest other trackers for peers beyond its
capacity. (This will also need client program to support.) The scene
is much like Kazaa, lots of trackers exists, each tracking about 100
peers, and peers can connect to all other peers in the world
downloading the same content. IMO the scalability is improved to a
great extent.
There can be some filter everywhere. For example, we have 10.*.*.* and
also 222.205.*.* ip address, some of 10.* can connect to 222.205, but
some others cannot. A peer from 222.205 tell the tracker, "I want
peers from only 222.205, but not 10.*." The tracker will return only
222.205 as the peer requests. Another example, 10.* are firewalled,
they can only access ip address outside our campus lan with a "dynamic
ip", that is, an ip address different than 10.*, and assigned
dynamically, like 210.32.*.*. If a tracker outside our campus lan
shares peers info with the tracker inside our campus lan, the 10.*
peers are not to be shared.
Later maybe we can connect the trackers into a higher level p2p
network, maybe a structured P2P.
Multitracker is also a proposal to solve this issue. I think
tracker-tracker communication can be deployed along with multitracker,
they don't conflict with each other.
A problem is the torrent file. Tracker info is written in the torrent
file, do I have to generate a new torrent file with multitracker
extension? I haven't think of a good point.
Another issue is that torrent file is a whole, maybe some files within
a torrent are being tracked, then another forum distribute a new
torrent file, only adding some of forum ad text. Two torrent are doing
the same job, and I think it's better we can let them do together. We
can calculate hash on every file seperately, just as what was done in
"Merkle Tree extension"[1] by Olaf van der Spek. And the tracker do
not categorize peers by torrent files, but by every single file
seperately. Unfortunately this will not be backward compatible.
Comments are welcomed. Thank you.
Guanying
[1] http://62.216.18.38/bt_merkle/
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-***@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/