On Nov 13, 2007, at 9:54 , Tomash Brechko wrote:
On Tue, Nov 13, 2007 at 09:44:40 -0800, Dustin Sallings wrote:
If I ask for [a, b, c, d], and I get back [c, d], then at the point
where I got c, I know I'm not going to get a or b. My client doesn't
currently optimize for that case, but it certainly could if it
mattered. If I designed for an array of pairs, I could just as
easily
do the same thing.
You can do that _comparing_ the keys or key ids, while I propose only
counting the results. Or is it an indirect arguing again? ;)
It's a bit of each.
A given response has a certain probability of being for the next key
in your sequence. And then you check it. If it's not the one, then
you iterate your list until you find the matching value.
Why do you want to trade IO for something so computationally simple?
You'd be free to use get and get explicit NAKs if you wanted to,
though.
But I will use TCP_CORK advantage of getq then. You simply refusing
to see the point.
I see the point, I just don't see anything to justify the criticality
of your tone.
--
Dustin Sallings
