Faster end game
m |
m (grammar/spelling) |
||
| Line 1: | Line 1: | ||
| − | Faster Endgame | + | Faster Endgame AKA ''Dynamic Block Requests'' is a technique employed for faster file completion. |
| − | == | + | == Netfinity's Dynamic Block Requests == |
| − | Faster endgame by not requesting many blocks if the downloading file is near completion. A requested data range is blocked for downloading, you cannot download a certain datarange from multiple clients (by design of | + | Faster endgame by not requesting many blocks if the downloading file is near completion. A requested data range is blocked for downloading, you cannot download a certain datarange from multiple clients (by design of eMule, the protocol would allows this). So by requesting less blocks from slower clients we can request more blocks from faster uploading clients which results in a speed increase and faster file completion. |
| − | This feature only makes sense if | + | This feature only makes sense if a small part of a downloading file remains. |
| − | An earlier implementation included "dropping" of too slow | + | 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 in a while (e.g. if you're on a trickle slot). |
| − | == | + | == Dazzle's Faster Endgame == |
| − | Another implementation is " | + | Another implementation is "Dazzle's faster endgame" feature 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 client simply 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. |
| Line 19: | Line 19: | ||
TODO: | TODO: | ||
| − | I've seen that Morph includes an own version of DBR, though I | + | 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 == | == Official Approach == | ||
| − | The official client partially adapted | + | The official client partially adapted Netfinity's feature by introducing 2 new features: |
| − | * if a file is near completion and | + | * if a file is near completion and the download speed of a source is pretty low then less block requests will be created for that client. |
| − | * block requests are | + | * block requests are reduced in size to avoid "already requested ranges". |
== Conclusion == | == 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. | |
[[category:features]] | [[category:features]] | ||
Revision as of 07:22, 31 March 2007
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. A requested data range is blocked for downloading, you cannot download a certain datarange from multiple clients (by design of eMule, the protocol would allows this). So by requesting less blocks from slower clients we can request more blocks from faster uploading clients which results in a speed increase and faster file completion.
This feature only makes sense if a small part of a downloading file 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 in a while (e.g. if you're on a trickle slot).
Dazzle's Faster Endgame
Another implementation is "Dazzle's faster endgame" feature 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 client simply 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.
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 2 new features:
- if a file is near completion and the download speed of a source is pretty low then less 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.
