Extensible command syntax
Dustin Sallings
dustin at spy.net
Tue Nov 13 17:44:40 UTC 2007
On Nov 13, 2007, at 0:23 , Tomash Brechko wrote:
> You are failing to see my point.
I do get your point, but I was just sort of indirectly arguing
against it by use case since I think you're pointing to a limitation
that I don't think affects anybody. But as I'll try to explain below,
I also don't see the limitation here at all.
> Yes, the result is always mapped,
> but such mapping may be a simple array or list of (key, value) pairs.
> Thus if we request keys in the array/list order and get the results in
> the array/list order, we only have to traverse this array/list and
> assign results in order. This would make a simple client, and the
> only cost is NAKs in the wire (and they may be effectively compressed
> even if you want to optimize for "not found" case). You don't need
> this in your Java framework, because you have to have dictionary
> anyway. Still, other clients could benefit from that.
The thing is, this *is* done, including the ``compressed NAK `not
found' optimization'' you mention.
In the text protocol, get results arrive in the same order (although
the protocol documentation does not specifically state the order is
preserved) as they are found in the request. This includes duplicate
requests for the same key. However, only hit responses are included.
The NAKs are *implied*.
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.
In the binary protocol, there is no multi-get, but there's the normal
get, and a getq (no response is sent for a missing key). I'd expect
most people to use getq for batches, and the order must be retained
because they're individual commands in sequence (my client doesn't
maintain a map of outstanding commands, but rather a queue). You'd be
free to use get and get explicit NAKs if you wanted to, though.
--
Dustin Sallings
More information about the memcached
mailing list