Re: LIFO simulations

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