Faster end game
m (→Netfinity's Dynamic Block Requests) |
(spelling and grammar) |
||
| Line 8: | Line 8: | ||
Downloading procedure goes as follows: | Downloading procedure goes as follows: | ||
*Connection to a peer is made and it is determined what [[chunk]]s the peer has. | *Connection to a peer is made and it is determined what [[chunk]]s the peer has. | ||
| − | *A Data range on the local client is reserved for downloading. This a small part of the file. That same | + | *A Data range on the local client is reserved for downloading. This a small part of the file. That same data range will not be requested from other peers. |
| − | *That | + | *That data range is then requested from the peer. |
| − | + | ||
| − | + | So, by requesting fewer blocks from slower peers we can request more/bigger blocks from faster peers, which results in a speed increase and faster file completion. | |
| − | An earlier implementation included "dropping" of sources that are too slow in order to allow faster clients to take over. Dropping sources is not always a good idea since sources that are slow now might become fast sources | + | This feature only makes sense if a small part of a downloading file/[[chunk]] remains. |
| + | |||
| + | An earlier implementation included "dropping" of sources that are too slow in order to allow faster clients to take over. Dropping sources is not always a good idea since sources that are slow now might become fast sources after a while (e.g. if you're on a trickle slot). | ||
== Dazzle's Faster Endgame == | == Dazzle's Faster Endgame == | ||
| − | Another implementation is "Dazzle's faster endgame" | + | Another implementation is "Dazzle's faster endgame" which simply drops the slowest source from a file if no more block requests can be created. This is bad because block requesting might also fail if a peer has no more blocks for us (No Needed Part Source), thus dropping a source would be very bad in such a situation and won't help at all. |
| + | How is this bad? The source could be used for A4AF. What else? --[[User:134.130.183.101|134.130.183.101]] 05:07, 22 August 2008 (CEST) | ||
== Morph Approach == | == Morph Approach == | ||
| Line 29: | Line 31: | ||
== Official Approach == | == Official Approach == | ||
| − | The official client partially adapted Netfinity's feature by introducing | + | The official client partially adapted Netfinity's feature by introducing two new features: |
| − | * if a file is near completion and the download speed of a source is pretty low then | + | * if a file is near completion and the download speed of a source is pretty low then fewer block requests will be created for that client. |
* block requests are reduced in size to avoid "already requested ranges". | * block requests are reduced in size to avoid "already requested ranges". | ||
Revision as of 03:07, 22 August 2008
Faster Endgame AKA Dynamic Block Requests is a technique employed for faster file completion.
Contents |
Netfinity's Dynamic Block Requests
Faster endgame by not requesting many blocks if the downloading file is near completion.
Downloading procedure goes as follows:
- Connection to a peer is made and it is determined what chunks the peer has.
- A Data range on the local client is reserved for downloading. This a small part of the file. That same data range will not be requested from other peers.
- That data range is then requested from the peer.
So, by requesting fewer blocks from slower peers we can request more/bigger blocks from faster peers, which results in a speed increase and faster file completion.
This feature only makes sense if a small part of a downloading file/chunk remains.
An earlier implementation included "dropping" of sources that are too slow in order to allow faster clients to take over. Dropping sources is not always a good idea since sources that are slow now might become fast sources after a while (e.g. if you're on a trickle slot).
Dazzle's Faster Endgame
Another implementation is "Dazzle's faster endgame" which simply drops the slowest source from a file if no more block requests can be created. This is bad because block requesting might also fail if a peer has no more blocks for us (No Needed Part Source), thus dropping a source would be very bad in such a situation and won't help at all.
How is this bad? The source could be used for A4AF. What else? --134.130.183.101 05:07, 22 August 2008 (CEST)
Morph Approach
TODO: I've seen that Morph includes an own version of DBR, though I have not had any time to check it in detail... if anyone knows more, please add it --WiZaRd 21:34, 15 Jun 2006 (CEST)
Official Approach
The official client partially adapted Netfinity's feature by introducing two new features:
- if a file is near completion and the download speed of a source is pretty low then fewer block requests will be created for that client.
- block requests are reduced in size to avoid "already requested ranges".
Conclusion
Netfinity's original implementation is by far superior to any present implementation as it combines better dynamic block requests than the version in ESE mod plus better/more intelligent slow source dropping than Dazzle's version.
