aMule Forum
English => aMule Help => Topic started by: Fester Bestertester on February 25, 2016, 09:07:18 PM
-
Queues - endured
No data - likewise.
Queues: Frequently encounter going backwards. Occasionally try manual stop-and-resume or swap to another file (if available) and queue often reduces. This indicates either loss of retry query packet (UDP?) or timeout. Protocol could use a 'reduce retry timer if queue increases' test, or similar. Even just a few percent could help.
Related: queue handling. Frequent observation of '<many>(0)' persisting, then sudden 'connected'. Is there a heuristic somewhere that delivers to 'the most deserving'?
No data: frequent occurrence of remote client advising available data, then when 'connected' timing out without any transfer. UDP working, TCP not? protocol issue between me (local) to my server, or remote to its server, or between servers? Remote seems to have 'claimed' its chunk, blocking any of perhaps several other sources - particularly annoying if last chunk of large file otherwise delivered with good transfer rate from complete source(s).
Related to above: last source(s) giving only 'keep-alive' 0.1-0.2kB/s data where others having same chunk available have been delivering many kB/s.
Worth investigating?
Hopefully ...
-
Queues: First of all, they're handled on the 'other' side. Your queue position might increase because of several reasons, for example others in the queue taking advantage because asking for a high(er) priority shared file. The reask interval should not be decreased because it could cause you being blocked on the other side. There were malicious clients that tried to gain advantage in the queue by frequent reasking, therefore a minimum interval is now enforced.
The drop in the queue position from '<many>' to 'connected' also may be caused by several reasons, neither of which we can make anything about. Just some examples: all the clients in the queue before you were LowID; the other side has changed upload priorities which pushed you to the front of the queue; all the clients before you has been served or expired; or a combination of these; or ...
Your queue position is affected by several values: the time spent in the queue, the credits you have on the other uploader, the upload priority of the file you're currently asking for. The uploader than orders the clients in the queue taking these into account. That is, if you have more credit, you travel faster in the queue. If you ask for a higher priority file, you travel faster in the queue. If you have spent more time in the queue, you'll be closer to the top of the queue.
No data: I have seen such "connections" before, too.
Keep-alive transfer rate: Requesting (and downloading) the same chunk from different sources is at least tricky. I don't say it's not possible, a faster source may override a slower one.
-
Keep-alive transfer rate: Requesting (and downloading) the same chunk from different sources is at least tricky. I don't say it's not possible, a faster source may override a slower one.
If I understand correctly at the very least it would make sense for the last chunk. Just request concurrently from all other sources with the chunk. Once actually satisfied by any client drop the other requests. Sense it is the last chunk there is no opportunity cost. If we are trying to download other files from any of these other sources besides this file (with the 1 chunk remaining) then maybe we wouldn't do this (since we can only queue for one file at a time with a from source/client).
I guess doing something which would work in other situations would be far trickier and probably involve some kind of scoring algorithm but the above situation at least to me seems like a no brainer. If it is currently blocking the other sources for the last chunk when a request is already out from a different source then that would be a bad thing given the realities of the network and how sometimes it could take forever to get through the queues to get that last chunk from a given source.