Bram Cohen tips-off Bit Torrent 2 protocol features
Posted Jun 3, 2004, 9:47 AM ET by Alberto Escarlate (http://p2p.weblogsinc.com)
Heres a quite technical description of whats being implemented for version 2 of Bit Torrent protocol.
From: Bram Cohen < bram@b>
Date: Thu Jun 3, 2004 1:02 am
Subject: bt2 protocol features
After much arguing, cogitating, arguing, and cogitating, the bt2 protocol
designs are now further along than they were before.
Features planned for bt2 -
merkle hash trees - this is by far the most compelling reason to break
compatibility. Files in a multi-file will each have their own hash root.
udp-based tracker protocol (with http-based alternative for those who care less about bandwidth than convenience)
tracker redirection - when talking to a tracker, that tracker will tell
you where your primary tracker is (usually the one you just hit) and your
backup tracker is. This will enable (1) dynamic tracker load
redistribution, and (2) tracker backups. Of course, some smarts on the
tracker are necessary. When trackers are distributed they either have to
send some peers to each other or make sure a seed is on each tracker, and
when using a backup tracker it has to redirect everyone back to the main
tracker when it comes back up again. Since those smarts dont involve
changing the protocol, Im completely punting on it until later.
a beefed up peer protocol - there are some subtle changes to the state
machine planned, which are strict improvements but kind of involved so
Ill skip over them now. Also peers will announce which files they want to enable cross-torrent trading. Finally, announcements of having parts of pieces will be added, since thats enabled by hash trees. Doing that last part well requires some smarts, but again the smarts dont change the protocol so Im punting.
The above are the things Im convinced are a good idea. Notably missing is gossip. Too dangerous, may be added later via an extension mechanism.
The main sticking point left is how to deal with piece sizes - ideally all peers should be using the same piece size, but whether thats a good thing to require and if so (or even if not) how to set it Im not sure of yet.
Also Im not sure how to make trackers support scrape functionality (or
more to the point, Im not sure how much scrape functionality to carry
over, and in what way). Other than those issues all thats left is a whole mess of details.
Rest assured that bt2 protocol will have the same ease of implementation
and reliable compatibilty of bt1. Also rest assured I wont push the damn
thing out until Im certain it will get feature requests down to a dull
roar for at least a few months.
-Bram
Bram Cohen tips-off Bit Torrent 2 protocol features
Posted Jun 3, 2004, 9:47 AM ET by Alberto Escarlate (http://p2p.weblogsinc.com)
Heres a quite technical description of whats being implemented for version 2 of Bit Torrent protocol.
From: Bram Cohen < bram@b>
Date: Thu Jun 3, 2004 1:02 am
Subject: bt2 protocol features
After much arguing, cogitating, arguing, and cogitating, the bt2 protocol
designs are now further along than they were before.
Features planned for bt2 -
merkle hash trees - this is by far the most compelling reason to break
compatibility. Files in a multi-file will each have their own hash root.
udp-based tracker protocol (with http-based alternative for those who care less about bandwidth than convenience)
tracker redirection - when talking to a tracker, that tracker will tell
you where your primary tracker is (usually the one you just hit) and your
backup tracker is. This will enable (1) dynamic tracker load
redistribution, and (2) tracker backups. Of course, some smarts on the
tracker are necessary. When trackers are distributed they either have to
send some peers to each other or make sure a seed is on each tracker, and
when using a backup tracker it has to redirect everyone back to the main
tracker when it comes back up again. Since those smarts dont involve
changing the protocol, Im completely punting on it until later.
a beefed up peer protocol - there are some subtle changes to the state
machine planned, which are strict improvements but kind of involved so
Ill skip over them now. Also peers will announce which files they want to enable cross-torrent trading. Finally, announcements of having parts of pieces will be added, since thats enabled by hash trees. Doing that last part well requires some smarts, but again the smarts dont change the protocol so Im punting.
The above are the things Im convinced are a good idea. Notably missing is gossip. Too dangerous, may be added later via an extension mechanism.
The main sticking point left is how to deal with piece sizes - ideally all peers should be using the same piece size, but whether thats a good thing to require and if so (or even if not) how to set it Im not sure of yet.
Also Im not sure how to make trackers support scrape functionality (or
more to the point, Im not sure how much scrape functionality to carry
over, and in what way). Other than those issues all thats left is a whole mess of details.
Rest assured that bt2 protocol will have the same ease of implementation
and reliable compatibilty of bt1. Also rest assured I wont push the damn
thing out until Im certain it will get feature requests down to a dull
roar for at least a few months.
-Bram
http://p2p.weblogsinc.com/entry/4845286863127275/
http://groups.yahoo.com/group/BitTorrent/message/5481
You can read the original publication here.