..Amazing! I woke up with the same idea, and I told myself 'this I have to post it in the forum'. The next I see is this topic.

Before getting straight to the point, I want to tell that I am impressed beyond words with the actual Limewire, I remember being in Gnutella from the early days of Gnucleus (maybe before); There was Limewire too, I thought for myself 'well,nice... and pretty, but JAVA, you know... plus, it's slow.' Now I returned today to Gnutella after an exile in closed networks (no, not Fasttrack) and I find all those features previously unthinkable for Gnutella implemented here. And I almost don't believe it. Believe me...

Well, as we know, "large" file downloaders often harm unintentionally "small" file downloaders. Then again, what is "small"? What is "large"?

10 MB. Maybe this size is a large file for music (or e-book.. plain ascii anyway)uploaders. Or a small file for a movie uploader. What if the Limewire user does upload music + movies? Harder to say when is small and when is large... Harder still if you consider what is currently being uploaded. Confused? Fear not...

What we need here is that Limewire analizes the size of the files being uploaded versus the files requested at the queue, and consecuently asign a slot : the larger the file being uploaded (in relation of what you have shared) the smaller the file intended to be uploaded next (there is already an uploading range, so no problem). This way when a large file is being uploaded, a small file must go with it, the "medium" files are uploaded together and we clean a little bit the queue; I know this theory sound a little wacky but I do not recommend to set a fixed cipher as asked previously: the result will probably be extinted files.. and I always thought that balance is the key to filesharing. What do you think about this?