Michael Rogers wrote: > Jano wrote: >> As I see it, if LIFO indeed had better throughput (not proved in any >> case), we could still use it for a low priority global queue (i.e. >> inserts/downloads of big files), where the user has no practical say >> about cancel/request. >> >> I'm also not sure of the degree of unfairness if you maintain queues per >> peer instead of a single global queue, and drop duplicated queries. > > That sounds interesting, but it's not what we're currently simulating.
Yep, just commenting. > My main concern with LIFO is that messages relating to the same > search/transfer can get separated by large amounts of time: one message > that gets pushed to the bottom of a queue somewhere can cause the entire > search/transfer to time out, even if the rest of the messages get through. This is undoubtedly of great concern. I was not realizing that each transfer isn't independent, although now that you mention it, is obvious from the splitting in 32k blocks. > But if you're suggesting we use LIFO to queue new *incoming* searches, > with a separate queue per peer, the above problem wouldn't arise (we'd > either handle the search in its entirety or not at all). I'm not really suggesting something concrete in my latest post, since I'm still a bit overwhelmed by the details I ignore about freenet, so you probably have a better idea of what you think I'm suggesting :) than me. Upon reflection, I think you refer to a queue per requester, not direct peer. It certainly is appealing from a fairness POV, regardless of [FL]IFO.
