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. 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. 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). > What attracts me of > it is that, in principle, is very simple: LIFO+dropping requires no tuning. Well there's still one parameter, queue length, but admittedly LIFO's less sensitive to the queue length than FIFO. Cheers, Michael
