forked from premiere/premiere-libtorrent
parent
06597a5d30
commit
da58e0cbd1
|
@ -10,7 +10,7 @@ piece picking
|
|||
-------------
|
||||
|
||||
The standard bittorrent piece picker is peer-centric. A peer unchokes us or we
|
||||
complte a block from a peer and we want to make another request to that peer.
|
||||
complete a block from a peer and we want to make another request to that peer.
|
||||
The piece picker answers the question: which block should we request from this
|
||||
peer.
|
||||
|
||||
|
@ -89,7 +89,7 @@ Some requests will stall. It appears to be very hard to have enough accuracy in
|
|||
the prediction of download queue time such that all requests come back within a
|
||||
reasonable amount of time.
|
||||
|
||||
To support adaptive timeuts, each torrent maintains a running average of how
|
||||
To support adaptive timeouts, each torrent maintains a running average of how
|
||||
long it takes to complete a piece. There is also a running average of the
|
||||
deviation from the mean download time.
|
||||
|
||||
|
@ -112,7 +112,7 @@ even though it has already been requested from another peer.
|
|||
|
||||
This has the effect of getting more and more aggressive in requesting blocks
|
||||
the longer it takes to complete the piece. If this mechanism is too aggressive,
|
||||
a significant amount of bandwidht may be lost in redundant download (keep in
|
||||
a significant amount of bandwidth may be lost in redundant download (keep in
|
||||
mind the zero-sum game).
|
||||
|
||||
It never makes sense to request a block twice from the same peer. There is logic
|
||||
|
|
Loading…
Reference in New Issue