Editing Faster end game
From EMule Wiki
Warning: The database has been locked for maintenance, so you will not be able to save your edits right now. You may wish to cut-n-paste the text into a text file and save it for later.
The administrator who locked it offered this explanation: site maintenance
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 7: | Line 7: | ||
Downloading procedure goes as follows: | Downloading procedure goes as follows: | ||
− | *Connection to a peer is made and it is | + | *Connection to a peer is made and it is deterined what [[chunk]]s the peer has. |
− | *A Data range on the local client is | + | *A Data range on the local client is reserverved for downloading. This a small part of the file. That same datarange will not be requested from other peers. |
− | *That | + | *That same datarage is request from the peer. |
+ | So by requesting less blocks from slower clients we can request more/bigger 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//[[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 in a while (e.g. if you're on a trickle slot). | |
− | + | ||
− | 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 | + | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
== Dazzle's Faster Endgame == | == 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 | + | 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 == | == Morph Approach == | ||
Line 63: | Line 29: | ||
== Official Approach == | == Official Approach == | ||
− | The official client partially adapted Netfinity's feature by introducing | + | 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 | + | * 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". | * block requests are reduced in size to avoid "already requested ranges". | ||