111 |
-not network/geographical locality |
-not network/geographical locality |
112 |
|
|
113 |
See summary table for performance details |
See summary table for performance details |
|
|
|
114 |
|
|
115 |
1.7. Summary |
|
116 |
|
1.7. BitTorrent |
117 |
|
Notice: pros and cons are not presented here |
118 |
|
-BitTorrent is not a lookup system-- it's a tool for *distributing* data |
119 |
|
-MIT License, written in Python |
120 |
|
-resembles Overnet's/ed2k's MFTP |
121 |
|
-supports resumed downloads |
122 |
|
-supports upload-download ratios (if this is a built in feature, this might be a problem for us (if used as out-of-box)) |
123 |
|
-however, upload-download ratios reduces DoS attacks: one cannot publish a large amount hokum data in the network if ratios are used |
124 |
|
-reduces query hotspots (DHTs), however routing hotspots remain |
125 |
|
-when more than one person is downloading from a server/node/computer, BitTorrent sends blocks of the files to downloaders |
126 |
|
-this reserves the server's/node's/computer's bandwidth |
127 |
|
-supports simultaenous downloads |
128 |
|
-since each new downloader introduces a new upload capacity, eventually the upload overhead for the original server/node/computer bandwidth is reasonable small |
129 |
|
-uses SHA-1 for checking data integrity (suits for us very well!) |
130 |
|
-we don't have to create 'mini-blocks' for Gzz p2p, since bitTorrent itself partitions data into several blocks for us |
131 |
|
-my initial suggestion for our p2p data obtaining scheme: use Kademlia for data lookup and bitTorrent/MFTP-like tool for downloading the data |
132 |
|
|
133 |
|
See http://bitconjurer.org/BitTorrent/ for details. |
134 |
|
|
135 |
|
1.8. Summary |
136 |
|
|
137 |
This summary table is far from complete (and from total truth) |
This summary table is far from complete (and from total truth) |
138 |
|
|