the idea is to push the file less transferred x networktracking requesters chunk/piece composition for a single file using their reasks to etablish if there is any change - all requesters from a ntwork for each file - (if they acquired some data or not - improvement or stall)the file with the longer stall status will get the slot. completing a succesfull upload session is count as an improvement and the file will go bottom queue.downloads/part files will be reverse, last part file involved in any improvement (successfully downloaded part counts) will be the one.give 50% chance to be a part or a complete upload slot and keep chosing randomly the client.in other words... the complete file with the slowest parts transfer among requesters will be the one (any successful upload from our side will put it 0.00),for downloads: still track other requesters reask status changing (if we just had a part it's an improvemt too - 0.00) the file that had just an improvement will be the one.

the goal is to push the less transferred file according the real file speed not to count how many 5000queue client sources it has.

iirc neomule worked pretty much as you just described, the idea was good but it poorly failed in some situation.1. all files with one request were pushed massively. Did they really need that push? i tried to search from a freind home same files and not all of them needed a particular push. 2. whenever you had more requests for the same file, u could often see the requesters were all stuck at the same % with the same parts. this files had no chance to be pushed. the more requesters got stuck at that point the lower the fil prio went.

relying on complete sources count from source Exchange is failing because you know, fine, there are 9 sources + me, but they clearly made poor priority choices. and reverse when there were 2 sources + me... there could be a good sharer.

The point is not just the speed (where the system works in most of cases though, because we have to assume that the majority of the time an higher number of sources has a potential higher speed, exception are really really rare), but the lifetime of the file. With 2 sources only, it may be avaible only at certain times because both clients might be offline for days, or might disappear completely... that's why rare files really need a push, to increase the number of sources (with full file) avaible.

Its pratically impossible to trace "filespeed" accurately enough to make a priority system based on that...

esher wrote:btw the current random queue with default priority is basically a "follow the majority" mode . it's bad, even from your point of view because file rarity is brutally inrelevant.

What do you mean with "follow the majorty" ? That file with more requests usually get more upload slot ? Well, its kinda obvious... to avoid that we should increase the "tickets" for the rare files. But on the other side, we should not make a brutal difference otherwise we won't upload the popular files in that situation.