Re: LIFO simulations

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.